This seams neat, but I'm not sure I understand the purpose/difference between this and using the iOS simulator.
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…
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.
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.
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.