Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by vlovich123 on Friday August 28, 2026 @07:57PM
(#49485594)
If you’re talking about the simulator, no. That doesn’t virtualize - it literally just runs it locally on your machine. Less RAM overhead and CPU since it uses your normal instruction set and doesn’t run a separate kernel and userspace.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by valleyer on Friday August 28, 2026 @08:08PM
(#49485650)
At least historically, it actually did run its own entire userspace, including daemons (all the way to launchd, IIRC), etc. All compiled for Intel, back in the day. Shared the kernel though.
Many of the nominally shared system pieces between Mac and iPhone (like Foundation) actually had many subtle compile-time differences.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by busymom0 on Friday August 28, 2026 @07:40PM
(#49485502)
Private cloud compute I think. I learnt about it today too from this reddit post which mentions how:
> At WWDC, Apple announced that starting in the 27.x versions of iOS, macOS, etc., devs would be able to call Private Cloud Compute directly from Swift with no additional API configuration. Presently, the only way to get free cloud inference is by joining the App Store Small Business Program.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by chews on Friday August 28, 2026 @08:40PM
(#49485802)
What a release! Congrats to the builder, lots of great work done here and in IOS profiling in general has been done here recently. Corellium went research only and I lost the ability to actually profile my applications the way I'd like. I've got a fun thing over coffee in the morning!
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by benoau on Friday August 28, 2026 @09:35PM
(#49486130)
It will be to prevent access to third-party app stores as both the EU and Japan legislated they must be allowed.
> In a support document about alternative app marketplaces in the EU, Apple explained that “device eligibility for alternative app marketplaces is determined using on-device processing with only an indicator of eligibility sent to Apple.” In practice, iOS users in the EU who want to install alternative marketplaces will need to set the country or region of their Apple ID to an eligible country or region. Moreover, they will also need to be physically located in supported EU countries.
> In the case iOS users in the EU leave eligible regions, Apple will offer a “grace period” until apps downloaded from alternative app stores can no longer be updated. “If you’re gone for too long, you’ll lose access to some features, including installing new alternative app marketplaces. Apps you installed from alternative app marketplaces will continue to function, but they can’t be updated by the marketplace you downloaded it from,” the company explained.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by xkgt on Friday August 28, 2026 @11:36PM
(#49486663)
It is wild that Apple finds it cheaper to build and maintain different App store behaviors than to simplify and make alt app stores available in all markets. Other governments/markets don't care?
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by benoau on Saturday August 29, 2026 @12:01AM
(#49486752)
It's a very slow process, first there is investigations, then legislation, then enactment, then enforcement which is separately a very slow process. It requires a lot of willpower to get and keep the ball rolling and in fact nobody has even achieved the full extent of what they require yet! The EU may still be years away from meaningful compliance, Japan has only taken baby steps forming a new bureau just to enforce compliance of two companies widely accused of malicious compliance.
And then there is additional discouragement and pressure in the form of sanction and trade deal threats for regulating American tech platforms.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by unrented7977 on Saturday August 29, 2026 @02:14PM
(#49492011)
It's vastly more profitable to maintain their monopoly on iOS apps and the 30% cut than to allow users to stop paying apple a cut of their transactions.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by roblabla on Saturday August 29, 2026 @07:21AM
(#49488984)
As someone using AltStore PAL to install some third-party apps that would never be allowed on the App Store (such as emulators and manga readers), I heavily disagree.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by port11 on Saturday August 29, 2026 @05:06PM
(#49493335)
Everything that didn’t turn out exactly like some people wanted is useless or the Worst Thing Ever — which is a boring and cringe rule of the internet.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by audunw on Sunday August 30, 2026 @09:29AM
(#49498487)
I don’t think the cookie banner is useless. It’s annoying the hell out of everyone which is creating political demand for another round of legislation that should solve the issue properly.
It was a relatively easy fix which didn’t fully solve the issue but made the very real issue of pervasive tracking visible to everyone.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by WhyNotHugo on Tuesday September 08, 2026 @02:53PM
(#49614975)
The requirements for the third party app-stores are completely ridiculous and unreachable by 99% of the individuals and organisations out there. In practice, only vetted partners with huge resources can operate one.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by astafrig on Friday August 28, 2026 @10:41PM
(#49486401)
In addition to the third-party installation capability mentioned by siblings, Japan also has a regional capability for reassigning the side button to a third-party voice assistant (`com.apple.developer.side-button-access.allow`).
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by TalkingCodeMonk on Saturday August 29, 2026 @04:46AM
(#49488131)
This is a strong indicator that Apple's privacy claims are little more than a virtue signal. Network sandboxing an app is arguably the strongest privacy protection measure possible.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by tancop on Saturday August 29, 2026 @07:08AM
(#49488910)
Xiaomi phones support it in all regions. Think about it, a company famous for putting ads in system apps has the feature but "privacy conscious" Apple literally put in extra work to disable it everywhere it's not legally required.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by close04 on Saturday August 29, 2026 @11:26AM
(#49490700)
That iOS toggle isn’t about privacy but about mobile data usage. Users with data caps can limit the usage for non-essential or high data volume apps (streaming or cloud storage apps come to mind).
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by koito17 on Friday August 28, 2026 @11:26PM
(#49486623)
That would surprise me. I don't recall having to change my iPhone's region after moving to Japan. Transport IC cards in Apple Pay have "just worked".
I am vaguely aware that some phone manufacturers silently remove certain NFC hardware (or disable some driver) in order to avoid paying Sony patent fees. Apple doesn't seem to do that, though.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by close04 on Saturday August 29, 2026 @11:32AM
(#49490748)
Companies have never been “democracies”. Most companies are more like dictatorships internally (for employees) and past a certain size also externally (for customers). Everything is dictated by a small group of leaders and shareholders not chosen by either employees or customers.
If you really want to imagine them like democracies, you are voting with your wallet. Maybe you’re just in the minority.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by amelius on Saturday August 29, 2026 @01:30PM
(#49491656)
Nobody said companies _are_ democracies ... you're reading something that is not there.
The point is that Apple thinks it can somehow bend the rules of the EU that were established democratically. As if users are better off with Apple's rules.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by qwytw on Sunday August 30, 2026 @01:45AM
(#49496025)
> bend the rules of the EU that were established democratically
EU might occasionally get some things right but saying it's rules are "established democratically" is a slight stretch. It's a sort of a third degree democracy (that parliament is mostly imitative, has no real power and is easily manipulated) with all implementation details and most decision making being done by unelected bureaucrats.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by amelius on Sunday August 30, 2026 @06:59AM
(#49497584)
Yes it is not perfect, but a company telling us where democracy is functioning or not is not a solution and if a company suggests it, that is arrogant and dumb.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by restes on Friday August 28, 2026 @09:07PM
(#49485970)
The iOS Simulator consists of (some of) the userspace components of iOS compiled to run on macOS. This would be a full iPhone image running as-is via virtualization.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by whynotmaybe on Friday August 28, 2026 @10:19PM
(#49486308)
The simulator doesn't have a camera. The android emulator allows to configure the camera and use a picture, it's very handy to test your qr/barcode reader without needing to use a physical device. Maybe this also allows to use an image as camera?
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by afavour on Saturday August 29, 2026 @05:55AM
(#49488432)
It’s been years but I ran into a problem with a notification extension years ago. Worked fine on simulator, not on device. Turned out it was because I was using a HEIF image and (I think) the on-device extension was trying to use hardware decoding and didn’t have access to it. Meanwhile the simulator had no such sandboxing restrictions.
The difference doesn’t matter until it does, and then it’s infuriating to work out what’s going on.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by trollbridge on Friday August 28, 2026 @09:57PM
(#49486212)
It would also make testing far easier. I got bit with something that failed on real life iPhones with language set to es_US that worked fine on the simulator.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by kridsdale1 on Friday August 28, 2026 @10:18PM
(#49486302)
Incorrect. The iOS simulator is and always has been, simply iOS frameworks running fully natively on
macOS. It’s best to think of it as an alternative window managers but the apps are native Mac processes. They can be seen and debugged via the terminal using top and ps and lldb alongside all other processes. They just present gui via the Simulator Mac app container.
They do not live in a VM and are certainly not emulated at an instruction set level. They are Mac apps.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by ChrisMarshallNY on Friday August 28, 2026 @10:23PM
(#49486338)
Ah. That makes sense.
I would think that "Mac apps," means that they are, actually, a different OS (I actually already knew that, which was why I said what I said. The Intel thing was a spitball).
But one of the few joys geeks get, these days, is telling other geeks they are wrong, so I feel as if I’ve done my bit to make this a happier place.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by dagmx on Saturday August 29, 2026 @01:10AM
(#49487059)
The simulator is a different SDK target than iOS itself.
You have to compile completely independently for it, and depending on your dependencies they may not compile for the simulator.
Additionally the simulator runs a really ancient and feature restricted version of Metal. That means you can’t test a lot of graphical things that the hardware actually supports. I’m not sure if this supports GPU passthrough but the macOS VMs do, so that alone would be a huge improvement if possible.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by dagmx on Sunday August 30, 2026 @04:32AM
(#49496823)
Sure, you can also have iOS binaries forward relevant iOS SDK symbols to macOS. That doesn’t mean they’re not different SDKs with different limitations, and not everything that is on the store can be patched to run in the simulator because there are legitimately symbols missing or with stubbed functionality.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by fredoliveira on Saturday August 29, 2026 @05:28AM
(#49488332)
This is virtualization, so localhost will just be the virtual iphone itself. But you should have some command of how hosts are resolved, so you can always point the browser to the device hosting what you want to test, no?
Even easier, of course, is just using the iOS simulator included with xcode, which runs on your host computer. There, localhost resolves to your host computer.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by m132 on Saturday August 29, 2026 @05:07AM
(#49488233)
Note that, unlike Corellium, this isn't about emulating an iPhone. Apple is providing an iOS kernel for Virtualization.framework in PCC/cloudOS images and this project pairs it with the iOS user-space and patches to make everything run. Applications can very easily tell it apart from the real thing.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by thenewwazoo on Saturday August 29, 2026 @12:01PM
(#49490989)
Even if this person is South Korean and didn’t just adopt a pseudonym as a fig leaf, that’s not an affirmative defense against being a white supremacist.
The evidence is prima facie, it’s right there in the name. “14” is a famous-enough racist dog whistle it’s got a Wikipedia page, and when paired with “white forever” it ceases to be a dog whistle.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by ripbozo on Saturday August 29, 2026 @12:27PM
(#49491207)
You are expecting everyone to be as aware of these issues as you are. I don't think white supremacy has as large of a share of the mindspace in south korea as you think - not every issue (even if it has a wikipedia page!) is burned into everyone's mind across the globe. But I am happy to hear that every time you pick a username, you make sure it is free of dog whistles in all cultures and that the letters and numbers cannot be picked out or rearranged in a way that hints at one.
Re:Boot a Virtual iPhone via Apple's Virtualization.framework
by imshaikot on Sunday August 30, 2026 @08:08AM
(#49497968)
Can you use real Apple Wallet and ApplyPay (web) in the virtual device ?
I've been struggling apple-pay test automation and simulators can't do the real apple-pay integration.
Many of the nominally shared system pieces between Mac and iPhone (like Foundation) actually had many subtle compile-time differences.
> At WWDC, Apple announced that starting in the 27.x versions of iOS, macOS, etc., devs would be able to call Private Cloud Compute directly from Swift with no additional API configuration. Presently, the only way to get free cloud inference is by joining the App Store Small Business Program.
https://www.reddit.com/r/appledevelopers/comments/1vztibh/re...
https://github.com/wh1te4ever/super-tart-vphone-writeup
I'm curious what are these checks
> In a support document about alternative app marketplaces in the EU, Apple explained that “device eligibility for alternative app marketplaces is determined using on-device processing with only an indicator of eligibility sent to Apple.” In practice, iOS users in the EU who want to install alternative marketplaces will need to set the country or region of their Apple ID to an eligible country or region. Moreover, they will also need to be physically located in supported EU countries.
> In the case iOS users in the EU leave eligible regions, Apple will offer a “grace period” until apps downloaded from alternative app stores can no longer be updated. “If you’re gone for too long, you’ll lose access to some features, including installing new alternative app marketplaces. Apps you installed from alternative app marketplaces will continue to function, but they can’t be updated by the marketplace you downloaded it from,” the company explained.
https://www.thurrott.com/apple/298862/apple-adds-some-condit...
And then there is additional discouragement and pressure in the form of sanction and trade deal threats for regulating American tech platforms.
What people don't realise is that local companies aren't just competing with each other, they're competing against the US military.
its the least of their problems
https://altstore.io
It was a relatively easy fix which didn’t fully solve the issue but made the very real issue of pervasive tracking visible to everyone.
They've approved - at the very least - AltStore, Epic Games Store, Aptoide, Onside, and Setapp Mobile.
All other versions only allow denying mobile data to an app, not Wifi.
I really wish there was a way to enable this feature.
> I also found out the Chinese version has the ability to block an app for accessing both mobile data and Wifi/WLAN data.
Yet Apple is choosing not to enable it for everyone. It seems like it would be an easy and obvious privacy win, no?
I am vaguely aware that some phone manufacturers silently remove certain NFC hardware (or disable some driver) in order to avoid paying Sony patent fees. Apple doesn't seem to do that, though.
If you really want to imagine them like democracies, you are voting with your wallet. Maybe you’re just in the minority.
The point is that Apple thinks it can somehow bend the rules of the EU that were established democratically. As if users are better off with Apple's rules.
EU might occasionally get some things right but saying it's rules are "established democratically" is a slight stretch. It's a sort of a third degree democracy (that parliament is mostly imitative, has no real power and is easily manipulated) with all implementation details and most decision making being done by unelected bureaucrats.
That really matters, sometimes.
But not the vast majority of the time.
(source: been coding iOS since pre-SDK iPhone OS 1.0)
The difference doesn’t matter until it does, and then it’s infuriating to work out what’s going on.
I love this quote, reminds me how annoying it can be when something isn’t reproducible locally… only in production…
https://www.youtube.com/watch?v=T43b5ywnYpo
[0] https://github.com/Lakr233/vphone-cli/discussions/175
Edit: ah now I see, in the main readme under heading Firmware Variants. https://github.com/Lakr233/vphone-cli#firmware-variants
As others pointed out it's also useful for e.g. click/spam farms which need a "real" iPhone.
I always figured that Apple never set up a true emulator (like what Android does), because they didn't want people exploring their OS with a debugger.
They do not live in a VM and are certainly not emulated at an instruction set level. They are Mac apps.
I would think that "Mac apps," means that they are, actually, a different OS (I actually already knew that, which was why I said what I said. The Intel thing was a spitball).
But one of the few joys geeks get, these days, is telling other geeks they are wrong, so I feel as if I’ve done my bit to make this a happier place.
You have to compile completely independently for it, and depending on your dependencies they may not compile for the simulator.
Additionally the simulator runs a really ancient and feature restricted version of Metal. That means you can’t test a lot of graphical things that the hardware actually supports. I’m not sure if this supports GPU passthrough but the macOS VMs do, so that alone would be a huge improvement if possible.
This isn't true. You can easily patch App Store apps to run in the simulator.
It’s literally a different toolchain and SDK.
GarageBand is an excellent app.
Even easier, of course, is just using the iOS simulator included with xcode, which runs on your host computer. There, localhost resolves to your host computer.
More details here: https://github.com/wh1te4ever/super-tart-vphone-writeup
[1] “CVE-2025-43347: JZ, Seo Hyun-gyu (@wh1te4ever)”
https://support.apple.com/en-us/125115?utm_source=chatgpt.co...
The evidence is prima facie, it’s right there in the name. “14” is a famous-enough racist dog whistle it’s got a Wikipedia page, and when paired with “white forever” it ceases to be a dog whistle.
He doesn't need one. This is ridiculous, and you're being ridiculous.
There are some binaries in scripts/resources that you need to run as root. No idea what's inside them.