Cursor iOS development on Windows

Use Cursor on Windows to create a native SwiftUI project, build and sign it on a cloud Mac, and install each version on a real iPhone through TestFlight.

September 9, 2026 · 9 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 use Cursor on Windows to write a real native iOS app. Cursor can understand Swift, edit an Xcode project, add tests, and fix errors. Windows cannot run Xcode, however, so Cursor's normal iOS guide still expects a Mac for building and running the app.

A no-Mac workflow replaces the local Mac with a remote one. Keep Cursor and the repository on Windows, let Cursor's agent start a NoMac cloud Mac to compile, test and sign the project, then install the result on your iPhone through TestFlight. You are not turning Windows into a Mac; you are giving Cursor a Mac it can drive.

Why the usual Cursor iOS tutorial stops at Xcode

Cursor's own Swift and iOS guide separates editing from building: Cursor is the code editor, while Xcode builds and runs the app. Even the guide's more integrated Sweetpad workflow requires Xcode to be installed on a Mac. That is correct: Cursor does not include Apple's SDK.

NoMac changes the second half, not the first. It gives Cursor MCP tools that start a cloud Mac with Xcode, run commands on it, set up signing, and send the build to TestFlight.

Before you connect Cursor

• ·Install Cursor, Git, and a current Node.js release on Windows.
• ·Keep the iOS project inside a Git repository with a useful ignore file.
• ·Add NoMac credit: $10 buys 12.5 hours of Mac time and never expires.
• ·For TestFlight, join the Apple Developer Program and create the app in App Store Connect.
• ·Connect an App Store Connect team key to NoMac once, at nomac.app/apple.
• ·Install TestFlight on the iPhone you will use for feedback.

Start with a small native SwiftUI app. Cross-platform frameworks can also produce iOS apps, but they add a second dependency system and more build configuration. SwiftUI is the clearest path when the goal is an iPhone app rather than shared Android code.

Add NoMac to Cursor

First authenticate the CLI in PowerShell or Cursor's terminal:

npx @nomac/cli login

Cursor reads project-specific MCP servers from .cursor/mcp.json. Add this file to the project:

{
  "mcpServers": {
    "nomac": {
      "command": "npx",
      "args": ["@nomac/cli", "mcp"]
    }
  }
}

Cursor's MCP documentation describes this configuration and the difference between project and global servers. A project file is easier for a team to discover, but never place a private token in the file you commit. The device login keeps the credential outside the repository. Cursor can also use the hosted server at https://mcp.nomac.app/mcp, which signs in with OAuth.

Open Cursor's MCP settings and confirm that NoMac is enabled. In Agent mode, ask:

Check my NoMac credits and Apple connection. Inspect this iOS project and tell
me the scheme, bundle identifier, deployment target, and any missing files.
Do not start a Mac yet.

This first inspection is worth doing. Remote builds are most useful when the agent knows what it is sending and can explain the project settings before a failure occurs.

Create a project Cursor can maintain

If a valid project already exists, ask Cursor to preserve its structure. If you are starting from an empty folder, your prompt should explicitly require a complete iOS project, not only a group of Swift files. Include the product name, bundle identifier, minimum iOS version, and a small first release.

Create a complete native SwiftUI iPhone project named PocketPantry.
Use the bundle identifier com.example.pocketpantry and the deployment target
already supported by this repository. Version one stores pantry items locally,
supports add/edit/delete, and has no login or network calls.

Use standard SwiftUI controls, add tests for the storage model, and keep all
generated output out of Git. Explain every project-level file you create.

Replace the example bundle identifier with the identifier in your Apple account. A mismatch between the source project and App Store Connect is one of the fastest ways to turn a good app into a signing failure.

Use two build loops

Loop one: Simulator builds for compiler feedback

Ask Cursor to call start_mac, clone the repository into ~/drive/src with exec_mac, and run an unsigned xcodebuild build and the tests for the Simulator. It should read the compiler output, make the smallest justified fix, push the commit, pull it on the Mac, and build again. For a private repository, save a GitHub token as a NoMac secret first (request_secret), so the Mac can clone and pull it. This loop catches source, dependency, and project errors without producing a signed beta every time. The Mac can also boot the Simulator, and screenshot_mac lets Cursor see the screen.

Loop two: TestFlight builds for your iPhone

When the build is clean, ask Cursor to call set_up_signing. It makes the App Store profile, installs it with the account's certificate on the Mac, and returns the exact archive and export commands. Cursor runs them, then sends the .ipa with send_to_testflight. Apple processes it, usually in 5 to 15 minutes, before TestFlight shows the new build, so “upload complete” and “ready to install” are separate states.

Test the app on a real phone. Return to Cursor with a screenshot and a narrow description: “On the empty pantry screen, the Add button is hidden below the keyboard after I save the first item.” That produces a much better change than “the UI is broken.”

Have Cursor stop the Mac when it is done. Stopping deletes the VM, while the project and build caches stay on the account's drive for the next session.

How to make remote iteration feel fast

• ·Build coherent slices. Finish one flow, such as adding an item, before asking for a TestFlight build.
• ·Test logic separately. Put validation, sorting, and persistence behind small types with unit tests instead of hiding them inside a view.
• ·Keep dependencies boring. Every package adds another version and platform question to a remote build.
• ·Let the error choose the fix. Compiler, package, signing, and App Store processing failures are different categories. Do not randomly edit source for all four.
• ·Use the iPhone for behavior. Keyboard, permissions, camera, notifications, network changes, and accessibility deserve real-device checks.

Can you use Cursor from the iPhone too?

Cursor released a native iPhone and iPad app in 2026 for starting and tracking agents, reviewing diffs, and receiving notifications. Its mobile app announcement describes that control loop. It can be useful after the Windows project and NoMac connection are already prepared: start a task from the phone, review the result, let the agent build on the Mac, then open TestFlight on the same device.

Do the one-time Apple account setup on a full browser first. A phone is a good control room for a configured system; it is a frustrating place to debug credentials, project generation, or a complicated merge conflict. The phone-first iOS workflow explains that setup in detail.

Prepare the App Store release

Once the beta behaves correctly, ask Cursor to run review_lint and list missing store work. Let it draft metadata and organize screenshots, but verify every statement about privacy and functionality yourself. Require an explicit human confirmation before the final publish call.

Cursor on Windows plus a remote Mac is not a replacement for careful iOS testing. It is a replacement for owning and maintaining the build machine. For the parts of shipping that remain human, read what actually needs a Mac. For a failed release, use the iOS signing error guide before changing code.