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.

September 9, 2026 · 10 min read

Need a Mac for this? NoMac gives your agent full macOS with Xcode for $0.80 an hour, billed per minute. Start now →

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.

What works on Windows?

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 drives a cloud Mac 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 Mac for the iOS build. The Codespaces iOS guide covers that split.

Pick the right app technology

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.

Connect the agent to a cloud Mac

Add credit at nomac.app/mac ($0.80 an hour, billed per minute). In PowerShell, WSL, or the terminal where the project lives, install the CLI and log in:

npm install -g @nomac/cli
nomac 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

Run the CLI where the repository lives. 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 terminal workflow needs OpenSSH and rsync, which WSL has.

For signing, connect an App Store Connect team key once at nomac.app/apple. The key stays on NoMac's server; it never reaches the Mac or the chat. Unsigned builds and the Simulator need no Apple account.

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. Compile on a cloud Mac

The agent starts a Mac (start_mac, or nomac start from the terminal), which is ready in about a minute. It puts the project in ~/drive/src, by cloning it there or with nomac sync ., and runs an unsigned Simulator build. This is the authoritative compile check for the iOS target.

nomac start
nomac sync .
nomac exec --wait 600 -- xcodebuild -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' build

The agent reads the compiler errors, fixes the source on Windows, syncs and builds again. The same Mac runs unit tests and the iOS Simulator too.

4. Create a TestFlight build

When the build passes, set_up_signing (nomac sign) registers the bundle ID, makes the App Store profiles and returns the exact archive and export commands. The agent runs them, then send_to_testflight (nomac testflight) sends the .ipa. Apple processes it, usually in 5 to 15 minutes, then TestFlight installs it on your iPhone. Test the complete user flow and return screenshots and reproduction steps to the Windows agent.

Stop the Mac when you are done. Stopping deletes the VM, but the account's 20 GB drive at ~/drive is kept, so the next session's build is incremental.

How to test without the Windows iOS simulator

• ·Move validation, parsing, sorting, and storage rules into testable units.
• ·Build on the Mac often enough to catch compiler errors while changes are small.
• ·Run the iOS Simulator on the cloud Mac for screenshots and quick UI checks.
• ·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.
• ·Running macOS in a virtual machine on your PC. It adds licensing, update, signing, performance, and reliability questions that a Mac on Apple hardware avoids. See macOS in a VM on Windows.
• ·Copying certificates onto Windows. Let set_up_signing install them on the Mac and keep account credentials away from the source tree.

Publishing from Windows

Test the TestFlight build, prepare accurate metadata and screenshots, run review_lint on the App Store record, and stage the version with publish. It submits only after a human confirms. 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.