13.4. That’s the macOS version number that decides whether Apple’s newest M4 Macs can run macOS virtual machines at all, according to Wccftech. Anything older than Ventura 13.4 and the guest simply will not boot on that hardware. One point release, drawn like a line in the sand.
I bring up that number because it tells you something about how virtualization works on Apple silicon. It is not a general-purpose emulator that will run anything you point at it. It is a tightly scoped feature with rules, and those rules move when Apple moves them. Which is exactly the context you need before getting excited about the thing everyone is currently excited about: a virtual iPhone booting on a Mac.
Why a bot builder cares about a fake phone
I write automation. Bots that tap through apps, agents that read screens and decide what to do next, test harnesses that need to run the same flow four hundred times without a human watching. The single most annoying dependency in all of that work is physical hardware.
My device drawer is a graveyard of test units. Each one needs charging, cabling, provisioning, and a babysitter when it inevitably falls off the USB bus at 3am mid-run. Every device I add multiplies the maintenance, not the throughput. A simulator solves some of that, but a simulator is not the operating system a real user runs, and anyone who has debugged a bug that only reproduces on device knows the gap is real.
So when Korben writes up vphone, a virtual iPhone on Mac, my first thought is not “neat demo.” It is “how many of those can I run on one machine, and can I script them.” That is the question that changes how I build things.
What the current facts actually support
Let me be precise about what is established and what is not, because the gap between those two is where bad architecture decisions get made.
- Apple has extended macOS virtualization capabilities and added Rosetta for Linux binaries, per InfoQ. Apple is investing in this surface, not letting it stagnate.
- Running macOS guests on M4 Macs requires a guest on Ventura 13.4 or newer, per Wccftech. Hardware generation constrains what you can virtualize.
- A separate open source project runs macOS on iPad using M1 and M2 chips, but it needs a jailbreak, per Pasquale Pillitteri. Some of the interesting work in this space still lives outside the sanctioned path.
- Windows-on-Mac virtualization is mature enough that Macworld publishes tested picks for it. That is what a settled tooling category looks like.
- vphone exists and runs a virtual iPhone on Mac, per Korben.
What I do not have is throughput numbers, supported iOS versions, or a statement about what is licensed for what use. I am not going to invent them. If you are planning production infrastructure on this, go read the project’s own documentation before you write a single line of orchestration code.
How I would build against it anyway
The pattern I use for anything this new is a driver interface with two implementations. Your bot logic should never know whether it is talking to a physical phone, a simulator, or a virtual machine. It should know how to tap, screenshot, read a view hierarchy, and reset state.
Keep the boundary thin
Define the smallest interface that covers your actual flows. Four or five methods. Resist the urge to expose device-specific capabilities through it, because those are the calls that will break when the underlying tool changes shape.
Assume the guest is disposable
The biggest practical win of a virtual target is not speed, it is state. Snapshot, run, restore, repeat. If your test use currently spends a third of its runtime clearing app data and re-logging-in, that work becomes a file copy. Design your flows so that every run starts from a known snapshot instead of from cleanup logic you have to maintain.
Version-pin everything
That 13.4 detail is your warning. Record the host OS version, the guest version, and the tool version alongside every run result. When a flow starts failing and nothing in your code changed, that metadata is the difference between a ten-minute diagnosis and a lost afternoon.
The part I am genuinely watching
Screen-reading agents need volume. If you are training or evaluating a model that operates a phone interface, you need thousands of episodes across a wide range of app states, and you need them cheaply. Physical devices cap that hard. A virtual target that boots on commodity Mac hardware moves the ceiling somewhere useful.
I am not treating this as solved. Apple controls the framework, the rules shift between hardware generations, and community projects sometimes depend on paths Apple can close. But the direction is clear enough that I am restructuring my use to be device-agnostic now, so that when the tooling matures, I am plugging in a driver rather than rewriting a test suite.
My device drawer is not empty yet. It is looking a little less permanent.
đź•’ Published: