iOS development on Windows: the complete 2026 guide
What Windows can do for native iOS development, what still requires macOS, and a practical workflow for coding, cloud builds, TestFlight, and the App Store.
· 10 min read
You can develop and publish a native iOS app from Windows in 2026, but Windows cannot run Xcode or Apple's iOS Simulator. Use Windows for the repository, editor, Swift logic, Git, and AI coding agent. Use a remote Mac for the Xcode build and code signing. Use TestFlight on an iPhone for real-device testing.
This is a normal distributed workflow, not an Xcode emulator. It works because source code is portable while Apple's SDK and distribution tools remain on macOS.
The practical answer: write on Windows, compile on a cloud Mac, and test on an iPhone. If a tutorial claims to install current Xcode or the real iOS Simulator directly on Windows, it is not describing Apple's supported toolchain.
What works on Windows?
| Task | Windows support | Best tool |
|---|---|---|
| Edit Swift and project files | Yes | Cursor, VS Code, or another editor |
| Compile portable Swift packages | Yes | Official Swift toolchain |
| Compile SwiftUI for iPhone | No local Apple SDK | Remote Xcode build |
| Run the iOS Simulator | No | Remote Mac or real iPhone |
| Sign and upload an App Store build | Not with Windows alone | Managed cloud Mac |
| Test the beta | Control from Windows | TestFlight on iPhone |
Swift itself does run on Windows. Swift.org publishes an official Windows toolchain and documents command-line projects, package tests, and VS Code support. That does not include Apple's SwiftUI, UIKit, iOS SDK, Simulator, or Xcode. Swift the language is cross-platform; the iPhone application frameworks are Apple-platform frameworks.
Choose your Windows workspace
Option 1: Cursor on Windows
This is a strong choice for an AI-led native project. Cursor edits the repository and calls a cloud build through MCP. Follow the complete Cursor iOS development guide for its configuration and prompt pattern.
Option 2: VS Code with native Windows Swift
Install the official Swift toolchain and Swift extension. This gives completion, navigation, Swift Package Manager, testing, and debugging for code supported on Windows. Keep portable business logic in Swift packages; compile the iOS target remotely.
Option 3: VS Code connected to WSL
WSL gives you a Linux shell, package tools, and a predictable home for terminal coding agents. It is especially useful when the rest of your stack already runs on Linux. It still does not provide Xcode. See the VS Code and WSL setup guide.
Option 4: a browser-based cloud workspace
GitHub Codespaces keeps the repository in a Linux development container accessible from a browser. It is useful on managed Windows computers and Chromebooks, but it also needs a separate macOS release build. The Codespaces iOS guide covers that split.
Pick the right app technology
| Project type | What Windows can run | iOS release route |
|---|---|---|
| Native SwiftUI | Editor, agent, portable Swift tests | Cloud Xcode + TestFlight |
| React Native with Expo | JavaScript app and Expo development tools | EAS is usually simplest |
| Bare React Native | JavaScript, Android, most shared logic | Build checked-in ios/ on macOS |
| Flutter | Dart app, Windows/Android/web targets | Build complete Flutter iOS project on macOS |
Do not choose a cross-platform framework only to avoid one build machine. Choose it when shared Android and iOS code is valuable. Native SwiftUI is often simpler for an iPhone-only product; Expo can be simpler for a React Native product; Flutter is reasonable when Dart and its widget system fit the team.
Set up the cloud build connection
Create the app record and connect an App Store Connect API key in NoMac. In PowerShell, WSL, or the terminal where the project lives, authenticate:
npx @nomac/cli login
Connect npx @nomac/cli mcp to the coding agent. Claude Code and Codex can be added directly:
claude mcp add nomac -- npx @nomac/cli mcp codex mcp add nomac -- npx @nomac/cli mcp
The MCP process must run in the environment that can read the repository. If the code is inside WSL, install and run the agent and NoMac inside WSL rather than pointing a Windows process at an inconsistent mounted path.
The Windows-to-iPhone loop
1. Keep a complete project in Git
A folder of Swift files is not enough. Commit the Xcode project or workspace, shared scheme, assets, configuration files, dependency locks, and privacy manifest. Never commit Apple private keys, signing certificates, or local environment files.
2. Run local tests that are truly portable
Test pure Swift logic with the Windows Swift toolchain when the package supports Windows. JavaScript and Dart projects can run their shared tests locally too. Do not assume a passing Windows test means SwiftUI, UIKit, native plugins, or the iOS target compiled.
3. Run a remote smoke build
Call push_project, then build with workflow=smoke. Poll status and retrieve get_failure when necessary. This is the authoritative compile check for the iOS target.
4. Create a TestFlight release
After the smoke build passes, run workflow=release. The managed Mac archives, signs, and uploads the app. Apple processes the binary, then TestFlight installs it on your iPhone. Test the complete user flow and return screenshots and reproduction steps to the Windows agent.
How to test without the Windows iOS simulator
- ·Move validation, parsing, sorting, and storage rules into testable units.
- ·Use smoke builds frequently enough to catch compiler errors while changes are small.
- ·Create TestFlight builds for complete features, not every padding adjustment.
- ·Test keyboard behavior, permissions, accessibility, backgrounding, and offline use on the phone.
- ·Record the build number with every bug report so the agent debugs the right source.
Apple itself recommends physical-device testing because simulators do not reproduce every hardware feature or performance characteristic. Read how to test an iOS app without a Mac for a reusable test matrix.
What not to waste time on
- ·Downloading an unofficial Xcode installer. Apple distributes and supports Xcode for macOS.
- ·Using an Android emulator as iOS proof. It can test shared logic and product ideas, not the iOS interface or binary.
- ·Making a macOS virtual machine your release foundation. It adds licensing, update, signing, performance, and reliability questions that a managed build avoids.
- ·Copying certificates onto Windows. Let the signing environment manage them and keep account credentials away from the source tree.
Publishing from Windows
Run review_lint, prepare accurate metadata and screenshots, test the selected build, and require human confirmation before submission. The complete easiest App Store publishing guide for 2026 covers the release in order.
Windows is not the obstacle it once was. The correct boundary is simply visible: Windows is the development workstation, the cloud Mac is the Apple build worker, and the iPhone is the real test environment.