[HN Gopher] Emulating an iPhone in QEMU
___________________________________________________________________
Emulating an iPhone in QEMU
Author : walterbell
Score : 171 points
Date : 2025-04-05 10:57 UTC (12 hours ago)
(HTM) web link (eshard.com)
(TXT) w3m dump (eshard.com)
| internetter wrote:
| Hugged to death?
| fb03 wrote:
| I believe so, tried to access but wasn't able
| urbandw311er wrote:
| Somebody posted an archive version in the comments
| znpy wrote:
| Archived version: https://archive.ph/l1CwO
| russianGuy83829 wrote:
| Is there a repository to reproduce this?
| markostamcar wrote:
| 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.
| valunord wrote:
| Would be truly amazing to use those old awesome apps and play
| some of the early games that have no equivalent today.
| shit_stabber wrote:
| 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?
| dmitrygr wrote:
| iOS supports usb Ethernet.
| LorenDB wrote:
| 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.
| nullpoint420 wrote:
| Kinda like paravirtualization? That sounds like a fun project!
| jchw wrote:
| 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...
| 1231231231e wrote:
| 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.
| jchw wrote:
| 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.
| vinceguidry wrote:
| > it's your best shot at a flagship experience.
|
| Is the Librem 5 really that far behind still?
| jchw wrote:
| 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.
| naitgacem wrote:
| 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.
| mikae1 wrote:
| _> 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 (!).
| jeroenhd wrote:
| 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.
| saidinesh5 wrote:
| 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
| jchw wrote:
| 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.
| saagarjha wrote:
| 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.
| exitnode wrote:
| Edit: Removed. I made a stupid joke about a serious topic
| candiddevmike wrote:
| What would it take for Apple to embrace multiplatform iOS
| development?
| loungin wrote:
| 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.
| gessha wrote:
| 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.
| 486sx33 wrote:
| I actually later like Apple hardware, especially since
| their model brought Apple-arm development that is
| completely awesome!
| bigyabai wrote:
| 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.
| walterbell wrote:
| 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
|
| _> Asahi is on the ropes right now_
|
| Or on a path to long term sustainability?
|
| https://asahilinux.org/2025/03/progress-report-6-14/
| 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!
| cosmic_cheese wrote:
| 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.
| saagarjha wrote:
| Nah, they'd just need to clear up the license and the other
| megacorps would do the rest.
| aaronbrethorst wrote:
| A total shift of corporate culture
| jchw wrote:
| Why would Apple do that?
| finnjohnsen2 wrote:
| Death treats and torture I think
| bigyabai wrote:
| Internet Explorer levels of dissolution threat.
| dehrmann wrote:
| 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.
| sneak wrote:
| Apple is a hardware company. Why would they want to support
| anything on hardware they don't sell?
| Zathu wrote:
| Do we think this is similar to the approach used by Corellium?
| skrauqs wrote:
| It's QEMU based i think that corellium are using their
| proprietary hypervisor
| saagarjha wrote:
| Yes, Corellium does not use QEMU.
| boricj wrote:
| 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
___________________________________________________________________
(page generated 2025-04-05 23:00 UTC)