iOS simulator on Windows: what actually works

You cannot run an iOS simulator on Windows locally, because Xcode and Simulator are not distributed for Windows. Apple sells Xcode through the Mac App Store, where the listing requires macOS 26.2 or later and a Mac with Apple M1 chip or later, and Apple’s own Simulator guide describes the simulator as an app running on a Mac with access to the computer’s CPU, memory and network connection.

What you can do is put the Mac somewhere else. Three approaches work, in ascending order of how much they cost you: a hosted device streamed to your browser, a rented Mac in the cloud, or a macOS runner in CI. The rest of this page is which one fits which problem.

Who this is for: Windows and Linux developers building or testing an iOS app, and teams whose non-Mac colleagues need to see one. Who it is not for: anyone wanting to run iPhone games on a PC — that is a different thing entirely, and none of this helps.

Why Xcode for Windows does not exist

The short version: Apple distributes Xcode through the Mac App Store, where the listing requires macOS 26.2 or later and a Mac with Apple M1 chip or later. Simulator ships inside that toolchain as a Mac app that runs iOS builds using the Mac’s own processor and memory.

That last detail is why the usual workarounds disappoint. Apple’s Simulator guide notes that because the simulator is an app running on a Mac, it has access to the computer’s CPU, memory and network connection, and that those resources are likely to be faster than a mobile device’s. It is not emulating iPhone silicon — it is running your app natively on the host. There is nothing to port to Windows, because the thing doing the work is macOS.

So every real option for Xcode on Windows is a variation on the same move: get access to a Mac, and decide how much of your workflow lives there.

The three options, and what each costs

A hosted device, streamed to your browser. Someone else runs the Mac; you get the simulator in a tab. This is the cheapest and fastest to start, and the right answer when your job is to run and test a build rather than compile one. It is also the only option a non-developer can use, which matters more than teams expect.

A rented Mac in the cloud. A whole macOS desktop over remote access. Maximum flexibility — it is a Mac, so Xcode, the simulator and the full toolchain are all there. It is also the slowest to work in, priced per hour or per month, and you are doing iOS development on Windows only in the sense that your keyboard is on Windows.

A macOS runner in CI. The build machine is a Mac, triggered by a commit. This is the one most teams end up with regardless, because signing and store submission need macOS anyway. It solves building, not interactive testing — a CI runner gives you an artifact, not a screen to tap.

Most teams that succeed at this use two of these: CI produces the build, and a hosted device makes it usable by people without Macs.

The honest constraint nobody mentions

Something running macOS still has to compile your app. No option above removes that. A hosted device runs an iOS build; it does not create one. If you are a solo developer on Windows with no Mac and no CI, you cannot get to a signed iOS binary at all, and any page implying otherwise is selling you something.

What changes is where that Mac sits and how often you touch it. When a macOS CI runner produces the build on every commit, the Mac becomes infrastructure — nobody logs into it, and a Windows developer works against its output all day.

The second constraint is the simulator itself, and it applies wherever it runs. Apple’s Simulator guide lists audio and video input — camera and microphone — along with motion support such as the accelerometer and gyroscope, the proximity sensor, the barometer and the ambient light sensor among unsupported hardware. Apple also says Simulator is not an accurate test of performance, memory usage or networking speed. Plan a pass on a physical iPhone before you ship, on Windows or otherwise.

For the Android half of a cross-platform product, none of this applies — the Android emulator runs locally on Windows. Google recommends at least 16 GB RAM and 16 GB disk space for it. Below those specs, Google says the emulator might still run but not smoothly, and suggests you consider testing on a physical device instead.

Where VibeView fits, and where it does not

VibeView is the first option: it runs real iOS simulators on Macs we operate and streams them to your browser, so a Windows or Linux machine gets a working iPhone or iPad without a Mac on the desk.

Be clear about the boundary, because it is the same one above. We do not compile your app. You upload a build your pipeline already produces — a compressed .app bundle for iOS — which means a macOS build step still exists somewhere, usually your CI. A signed device .ipa is not the artifact to bring here.

Past that upload, the loop is short. You pick the device model and OS version, and for a React Native project the CLI connects a streamed simulator to the bundler running on your own machine, so a JavaScript or asset change lands on the cloud device about a second after you save — no rebuild, no re-upload. Adding or changing a native dependency is the case that needs a fresh build.

The simulator limits above are ours too — no camera, no Bluetooth, no true performance numbers — and a physical-device pass still belongs in your release plan.

If the missing piece is a running iPhone on a Windows desk, the free tier answers it without a card: two concurrent sessions and 30 streaming minutes a month, in sessions that end after five minutes each. Enough to put your current build on an iPhone screen this afternoon and find out whether the loop works for you.

Frequently asked questions

Can you install Xcode on Windows? No. Xcode is distributed only for macOS, and Apple’s Simulator is part of that toolchain — Apple’s own Simulator guide describes it as an app running on a Mac, with access to the computer’s CPU, memory and network connection. There is no supported Windows build, and the workarounds people try are covered below with what each one actually costs.

Do I need a Mac at all to ship an iOS app? Somewhere in your pipeline, yes — something running macOS has to compile and sign the build. That machine does not have to be on your desk. A macOS CI runner can produce the build, after which a Windows or Linux developer can install it, run it and test it. The Mac becomes infrastructure rather than a workstation.

Is a hosted iOS simulator the same as the one in Xcode? It is the same simulator, running somewhere else. Apple’s Simulator is a Mac app, so a hosted service runs it on a Mac and streams the screen to your browser. That is why the behaviour matches, and also why the hardware limits match: Apple lists camera and microphone input, motion sensors, the proximity sensor, the barometer and the ambient light sensor as unsupported.

What can I not test without a physical iPhone? Anything depending on real hardware. Apple’s Simulator guide lists audio and video input, motion support such as the accelerometer and gyroscope, the proximity sensor, the barometer and the ambient light sensor among unsupported features, and says Simulator is not an accurate test of performance, memory usage or networking speed. Budget a device pass before release.

Can I use an Android emulator on Windows instead? For Android work, yes, and it runs locally — Google recommends at least 16 GB RAM and 16 GB disk space for the Android Emulator. But it tests Android, not iOS. If your product ships on both, the Android side is the easy half on Windows and the iOS side is the one needing one of the options above.

Published 30 July 2026 · Platform documentation checked 30 July 2026