I wish the https://github.com/devos50/qemu-ios project would evolve to support iPhone OS 3.x to experience many early iPhone apps for digital preservation's sake!
That reminds me I once emulated a NumWorks N0100 [1] and a HP Prime G1 [2] with QEMU, to the point where the emulators managed to run the official firmware.
Here's a fun way that this project could be applied: Take a phone that has pretty good hardware support for postmarketOS. Install a bare bones pmOS image, plus this version of QEMU, and boot iOS on and Android phone. It probably would be possible to further customize QEMU to forward all the phone hardware (modem, Bluetooth, etc.) into the iOS VM.
> Take a phone that has pretty good hardware support for postmarketOS
The first problem with this is finding a phone with postmarketOS that can both use the camera and take phone calls properly. I'd settle for that without the iOS/Android emulation...
As far as I know, the camera barely works on any device, including snapdragon 845 phones. Now I'm not saying the snapdragon 845 is unusable as a daily driver, but it is getting a bit long in the tooth, especially since the majority of what you run on a phone is browser engines, and web sites and web applications are not getting less demanding over time.
Ah yes. It appears that nothing has changed in the last decade for the Android ROM community. Still the same experience as downloading a custom ROM from "XDA Developers" for your HTC phone in 2016 and then finding out that it can't make phone calls and is bugged beyond comprehension.
Well, to be fair, postmarketOS isn't Android. For Android I've had tons of custom ROMs with no obvious hardware issues, mostly CyanogenMod variants, over the years. postmarketOS, though, tries to run stock Linux. It's a different ballgame.
The alternate approach is actually to utilize the fact that Android is relatively better supported and wrap Android components into a standard Linux userland, using a compatibility layer like libhybris with patched vendor kernels. It's pretty ugly but if you want Linux on phone now it's your best shot at a flagship experience.
Well, I don't have one, so I can't say with great certainty. I did, however, have a Pinephone Pro, and the experience wasn't great for a few different reasons. The Librem 5 is apparently faster, but it seems like it's not that much faster, so even if the experience is better I'd suspect it's not ready for most people. I think that's a real shame because it feels close and the target they're chasing (usable daily driver) isn't really moving as fast as it once was, but compared to a very cheap Android phone, the relatively-expensive Librem 5 is weak in almost every dimension. I considered buying it anyways... but I know damn well I can't daily drive it yet.
Pixels are well-supported in general. It helps that they're essentially Google's reference devices.
As for flashing over USB, any device can do that thanks to WebUSB. All a website needs to know are the device identifiers for ADB mode, recovery mode, and fastboot mode.
I'd say building an image capable of booting on the phone is much harder than altering the GrapheneOS installer to actually flash that image. The process is extremely similar for most devices.
If it’s just for fun, sure. However in practice this would be incredibly inefficient and not a usable device by any means, plus it would be a tremendous amount of work.
No mention of network connectivity - I suppose they aren't emulating the wifi or celluar modem chipsets? Wondering how they might connect this emulated device to the Internet, perhaps ethernet over USB or something like that?
Apple will never consider doing that. Their actions speak to the exact opposite: total control of their devices and ecosystem, non-cooperation with other companies on standards, stringent app store controls. They gain nothing, in their eyes, to allow that development model.
Even if they did it would take a tour de force to make reality. The whole iOS development stack very heavily depends on macOS — Xcode is written in Objective-C/Swift + AppKit for example and the iOS Simulator just runs the iOS userland in a phone frame and lets macOS furnish the Darwin half.
Practically speaking, they’d at minimum have to beef up the internal Yellow Box descendant they’d been previously using to make Safari and iTunes run on Windows (essentially porting large chunks of macOS to Windows) to be able to support Xcode, or following the direction of their more recent iCloud, Music, and TV apps write a WinUI-based version of Xcode for Windows paired with an all new iOS Emulator from scratch.
It’d be a huge investment with returns that are unclear at best.
I'd buy one if I knew I could use it. The old Intel Macs shipped with UEFI and a fairly open architecture, even Apple couldn't control when the chipset was fully depreciated. When MacOS cut off 32-bit support suddenly, hardcore software aficionados could still use Bootcamp to run the software they bought. When Apple "vintage"-ized old iMacs and Macbooks, they could still install other OSes and live on. Apple doesn't have to support their hardware forever... but their lack of a serious depreciation model means that I have to trust MacOS wholeheartedly.
And MacOS isn't worth my trust as a user. Big Sur feels like Mac by way of Windows 8 - it's stepping deeper into a service-integrated product that won't respect my time or money. If Apple published their driver code or at least documented their hardware as a gesture of good faith, I'd trust them a lot more. But Asahi is on the ropes right now (who'da thunk) and Apple isn't stepping in to heroically save anyone. Like the Halloween papers, with teeth this time.
It's all so tiring. I like my Magic Trackpad on GNOME, but I don't think modern Mac hardware is worth locking myself in with Dr. Tim Strangelove and learning to love his software.
Hopefully future Qualcomm SDXE or Mediatek/Nvidia SystemReady Arm PCs will deliver an open-standard Arm platform with upstream Linux support. Until then, we have Apple Silicon Macs with:
- official mechanism to provision non-Apple operating systems
- global retail availability, both physical & online
- best price/perf/watt Arm desktop via Mac Mini base
- NPU and unified memory for LLMs
- upcoming LTE/wifi/BT radios without Qualcomm/Broadcom firmware
When we stood up our OpenCollective, none of us really knew what to expect.. The sheer volume of support and the speed at which it flowed in left us floored and humbled beyond measure. The financial support provided via OpenCollective allows us to continue our work with confidence.. we have the resources we have always wanted to ensure the project’s viability long into the future..
After getting through all the administrative work required to keep the lights on after marcan’s departure, we’ve hit the ground running with upstream patch submission. We held our first board meeting.. we must start reducing the amount of patches we’re carrying downstream. Most of what we’re carrying is stable and has been for years..
We have submitted three new drivers upstream - the Image Signal Processor (ISP) driver, which is necessary for webcam support, and drivers for the Touchbar’s display controller and input digitiser.. both Touchbar drivers have already been accepted! Thanks to chaos_princess for taking on the responsibility of preparing and submitting all three.. Alyssa and Janne have been hard at work tidying up the GPU driver to prepare it for submission.
Rust for Linux abstractions are starting to be merged at a healthy pace.. every time an abstraction used by our driver is merged, we must drop our downstream version and rebase the driver atop the version accepted upstream. This is gruelling, menial, and unpleasant work, and Janne has our deepest gratitude for volunteering his time to get through it.
We have also been working to clean up and upstream.. fixes and changes for drivers already upstreamed such as the NVMe and I2C controllers.. changes to the upstream Texas Instruments TAS2764 and TAS2770 speaker amplifier drivers.. to support the Apple-specific variants found in Apple Silicon Macs.. we found that the ASoC maintainers had already been cherry-picking some commits from our development branches!
Apple uses its software to sell its hardware. That's why iMessage for Android never happened. Apple would need to see the world differently for this to happen. It'd be about as big as when as when Microsoft halfway embraced Linux with WSL and .NET for Linux.
I wish the https://github.com/devos50/qemu-ios project would evolve to support iPhone OS 3.x to experience many early iPhone apps for digital preservation's sake!
https://github.com/touchHLE/touchHLE is also great but needs patches for all but the most basic of apps.
QEMU-emulated iPhone 11 could support iOS 13.x to iOS 18.x, https://github.com/ChefKissInc/QEMUAppleSilicon
We would need QEMU support for iPhone 7, to run 32-bit apps in iOS 10.
Would be truly amazing to use those old awesome apps and play some of the early games that have no equivalent today.
That reminds me I once emulated a NumWorks N0100 [1] and a HP Prime G1 [2] with QEMU, to the point where the emulators managed to run the official firmware.
- [1] https://github.com/boricj/qemu/tree/numworks_calculators
- [2] https://github.com/boricj/qemu/tree/s3c2416-boricj
Here's a fun way that this project could be applied: Take a phone that has pretty good hardware support for postmarketOS. Install a bare bones pmOS image, plus this version of QEMU, and boot iOS on and Android phone. It probably would be possible to further customize QEMU to forward all the phone hardware (modem, Bluetooth, etc.) into the iOS VM.
Very amusing idea, but:
> Take a phone that has pretty good hardware support for postmarketOS
The first problem with this is finding a phone with postmarketOS that can both use the camera and take phone calls properly. I'd settle for that without the iOS/Android emulation...
A lot of snapdragon 845 phones tend to work fairly well no?
I'm not sure what the status of the newer devices is but those older oneplus 6/poco f1 era phones tend to work well with mainline kernel:
https://wiki.postmarketos.org/wiki/Mainlining#Supported_SoCs
As far as I know, the camera barely works on any device, including snapdragon 845 phones. Now I'm not saying the snapdragon 845 is unusable as a daily driver, but it is getting a bit long in the tooth, especially since the majority of what you run on a phone is browser engines, and web sites and web applications are not getting less demanding over time.
Ah yes. It appears that nothing has changed in the last decade for the Android ROM community. Still the same experience as downloading a custom ROM from "XDA Developers" for your HTC phone in 2016 and then finding out that it can't make phone calls and is bugged beyond comprehension.
Well, to be fair, postmarketOS isn't Android. For Android I've had tons of custom ROMs with no obvious hardware issues, mostly CyanogenMod variants, over the years. postmarketOS, though, tries to run stock Linux. It's a different ballgame.
The alternate approach is actually to utilize the fact that Android is relatively better supported and wrap Android components into a standard Linux userland, using a compatibility layer like libhybris with patched vendor kernels. It's pretty ugly but if you want Linux on phone now it's your best shot at a flagship experience.
> it's your best shot at a flagship experience.
Is the Librem 5 really that far behind still?
Well, I don't have one, so I can't say with great certainty. I did, however, have a Pinephone Pro, and the experience wasn't great for a few different reasons. The Librem 5 is apparently faster, but it seems like it's not that much faster, so even if the experience is better I'd suspect it's not ready for most people. I think that's a real shame because it feels close and the target they're chasing (usable daily driver) isn't really moving as fast as it once was, but compared to a very cheap Android phone, the relatively-expensive Librem 5 is weak in almost every dimension. I considered buying it anyways... but I know damn well I can't daily drive it yet.
> It appears that nothing has changed in the last decade for the Android ROM community.
The exception: GrapheneOS. I installed without hassle over USB via my web browser (!).
Pixels are well-supported in general. It helps that they're essentially Google's reference devices.
As for flashing over USB, any device can do that thanks to WebUSB. All a website needs to know are the device identifiers for ADB mode, recovery mode, and fastboot mode.
I'd say building an image capable of booting on the phone is much harder than altering the GrapheneOS installer to actually flash that image. The process is extremely similar for most devices.
AFAIK GrapheneOS flashes everything from fastboot (i.e. no recovery step). Implementing adb sideload protocol shouldn’t be too tricky though.
I'm running a custom ROM on a Galaxy S8 (so without project treble) and I've been pleasantly surprised!
Even something as niche as the swipe on fingerprint sensor to pull notifications drawer down still works!
Everything from phone calls, camera, fingerprint, all the essentials work pretty much flawlessly.
If it’s just for fun, sure. However in practice this would be incredibly inefficient and not a usable device by any means, plus it would be a tremendous amount of work.
Kinda like paravirtualization? That sounds like a fun project!
https://github.com/ChefKissInc/QEMUAppleSilicon
> Apple Silicon devices emulated on QEMU, currently only iPhone 11.
demo video: https://nitter.poast.org/eshard/status/1908162866609311962
Archived version: https://archive.ph/l1CwO
Is there a repository to reproduce this?
No mention of network connectivity - I suppose they aren't emulating the wifi or celluar modem chipsets? Wondering how they might connect this emulated device to the Internet, perhaps ethernet over USB or something like that?
iOS supports usb Ethernet.
What would it take for Apple to embrace multiplatform iOS development?
Apple will never consider doing that. Their actions speak to the exact opposite: total control of their devices and ecosystem, non-cooperation with other companies on standards, stringent app store controls. They gain nothing, in their eyes, to allow that development model.
Even if they did it would take a tour de force to make reality. The whole iOS development stack very heavily depends on macOS — Xcode is written in Objective-C/Swift + AppKit for example and the iOS Simulator just runs the iOS userland in a phone frame and lets macOS furnish the Darwin half.
Practically speaking, they’d at minimum have to beef up the internal Yellow Box descendant they’d been previously using to make Safari and iTunes run on Windows (essentially porting large chunks of macOS to Windows) to be able to support Xcode, or following the direction of their more recent iCloud, Music, and TV apps write a WinUI-based version of Xcode for Windows paired with an all new iOS Emulator from scratch.
It’d be a huge investment with returns that are unclear at best.
Nah, they’d just need to clear up the license and the other megacorps would do the rest.
Which is sad because a lot more people might consider buying their products if one was able to try the products with non-ecosystem devices.
Their devices are well designed and generally last for a long time. They also retain their value in case you want to resell them.
Instead, I’m constantly weighing the lock-in from their walled garden - should I go all in or should remain in control over my devices.
I actually later like Apple hardware, especially since their model brought Apple-arm development that is completely awesome!
I'd buy one if I knew I could use it. The old Intel Macs shipped with UEFI and a fairly open architecture, even Apple couldn't control when the chipset was fully depreciated. When MacOS cut off 32-bit support suddenly, hardcore software aficionados could still use Bootcamp to run the software they bought. When Apple "vintage"-ized old iMacs and Macbooks, they could still install other OSes and live on. Apple doesn't have to support their hardware forever... but their lack of a serious depreciation model means that I have to trust MacOS wholeheartedly.
And MacOS isn't worth my trust as a user. Big Sur feels like Mac by way of Windows 8 - it's stepping deeper into a service-integrated product that won't respect my time or money. If Apple published their driver code or at least documented their hardware as a gesture of good faith, I'd trust them a lot more. But Asahi is on the ropes right now (who'da thunk) and Apple isn't stepping in to heroically save anyone. Like the Halloween papers, with teeth this time.
It's all so tiring. I like my Magic Trackpad on GNOME, but I don't think modern Mac hardware is worth locking myself in with Dr. Tim Strangelove and learning to love his software.
Hopefully future Qualcomm SDXE or Mediatek/Nvidia SystemReady Arm PCs will deliver an open-standard Arm platform with upstream Linux support. Until then, we have Apple Silicon Macs with:
> Asahi is on the ropes right nowOr on a path to long term sustainability?
https://asahilinux.org/2025/03/progress-report-6-14/
Apple uses its software to sell its hardware. That's why iMessage for Android never happened. Apple would need to see the world differently for this to happen. It'd be about as big as when as when Microsoft halfway embraced Linux with WSL and .NET for Linux.
A total shift of corporate culture
Death treats and torture I think
Apple is a hardware company. Why would they want to support anything on hardware they don’t sell?
Internet Explorer levels of dissolution threat.
Why would Apple do that?
Do we think this is similar to the approach used by Corellium?
It's QEMU based i think that corellium are using their proprietary hypervisor
Yes, Corellium does not use QEMU.
Edit: Removed. I made a stupid joke about a serious topic
Hugged to death?
I believe so, tried to access but wasn't able
Somebody posted an archive version in the comments
[flagged]
There is no performance benchmark that I can see.
I think the GP is using an LLM to post. His other comments are very similar and it would explain making up nonexistent benchmarks.
I prefer to provide facts to let others make their own conclusions rather than needing to defend an accusation :)