Cursor iOS development on Windows

Use Cursor on Windows to create a native SwiftUI project, send release builds to a cloud Mac, and install each version on a real iPhone through TestFlight.

September 9, 2026 · 9 min read

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 that local build step with a remote one. Keep Cursor and the repository on Windows, let NoMac compile and sign the project on macOS, then install the result on your iPhone through TestFlight. You are not turning Windows into a Mac; you are giving Cursor a build service it can call.

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 accept the project, build it on a cloud Mac, and deliver it 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.
• ·Join the Apple Developer Program and create the app in App Store Connect.
• ·Connect an App Store Connect API key to NoMac.
• ·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.

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

Check the NoMac connection. Inspect this iOS project and tell me the scheme,
bundle identifier, deployment target, and any missing files. Do not build 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: smoke builds for compiler feedback

Ask Cursor to call push_project, then build with workflow=smoke. It should poll status, read the failure if there is one, make the smallest justified fix, and push again. This loop catches source, dependency, and project errors without producing a signed beta every time.

Loop two: release builds for your iPhone

When the smoke build is clean, run workflow=release. The resulting archive is signed and uploaded to App Store Connect. Apple processes it 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.”

How to make remote iteration feel fast

• ·Build coherent slices. Finish one flow—such as adding an item—before asking for a release 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, trigger a build, 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 finalpublish 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.