Expecting Windsurf to run the Simulator, sign, or submit your iOS app leads to confusion. This guide explains what Windsurf genuinely can't do and how to set up the correct Windsurf-plus-Xcode workflow.
Many developers arrive at Windsurf expecting it to do everything: edit, build, run on the Simulator, sign, and submit. It does not, and that is by design.
Windsurf is an AI-native editor. It writes and refactors code, but it does not contain Apple's compiler, the iOS Simulator, code signing, or the App Store pipeline.
This is not a bug to fix. It is the same boundary that applies to Cursor and plain VS Code. Only Xcode and Apple's toolchain can build and ship iOS apps.
Once you accept that boundary, the friction disappears and a clean workflow emerges.
Be precise about the limits so you stop fighting them. Windsurf cannot launch the iOS Simulator or render your app's UI live.
It cannot manage provisioning profiles, certificates, or code signing. It cannot archive your app or upload it to App Store Connect.
It cannot edit storyboards, XIBs, or asset catalogs with the visual tools those require. Those live in Xcode.
Knowing this list saves hours. Anything in it is an Xcode task, full stop, no matter how capable the AI editor feels.
Now the positive side. Windsurf is excellent at writing and refactoring Swift, with SourceKit-LSP providing completion and diagnostics.
Its Cascade agent handles multi-file edits, scaffolding, and test writing across your project.
It is a great home for everything around the app: networking code, models, scripts, fastlane config, CI YAML, and documentation.
Think of it as the authoring environment. Xcode is the build-and-ship environment. Each is strong where the other is not.
The fix for the build limitation is structural: run Windsurf and Xcode side by side on the same project.
Open your project folder in Windsurf for editing, and open the same `.xcodeproj` or `.xcworkspace` in Xcode for building and running.
Both tools operate on the same files on disk, so edits in Windsurf appear in Xcode and vice versa. Save in one, build in the other.
This side-by-side setup is the intended workflow, not a workaround. Embrace it and you get AI editing plus Apple's full toolchain.
If you want a quick compile check without switching to Xcode, use Windsurf's integrated terminal.
For a Swift package, run `swift build` and `swift test`. For an app, run `xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone' build`, picking a simulator name that exists on your machine.
This drives Xcode's build system from the command line, so it still relies on Xcode being installed, but it keeps you in the editor for fast feedback.
For full run-and-debug with breakpoints and the Simulator UI, switch to Xcode. The terminal is for compile checks, not for interactive debugging.
Code signing and devices are pure Xcode territory. Configure your team, bundle identifier, and signing in Xcode's Signing and Capabilities settings.
Run on the Simulator or a connected device from Xcode, where you also get the debugger, view hierarchy inspector, and Instruments.
Do not look for these features in Windsurf. They depend on Apple's private toolchain and frameworks that only Xcode provides.
When something involves a profile, a certificate, or a device, your reflex should be to open Xcode. Shipping to the App Store also requires an active Apple Developer Program membership.
Sometimes the confusion comes from the agent itself, which may suggest steps as if it could build or sign.
When Cascade proposes running the app or submitting it, recognize those as Xcode actions and perform them there.
You can even tell the agent your workflow, that you build and sign in Xcode, so its suggestions focus on code rather than on actions it cannot take.
The agent is a coding partner. Treat its build or submission suggestions as reminders to switch tools, not as things Windsurf will do.
The lasting fix is a mindset. Windsurf authors; Xcode builds, signs, and ships. Keep that division and the tools stop fighting you.
Use Windsurf for the bulk of your coding and for all the non-Swift project work, where its AI is a real productivity boost.
Use Xcode for compiling, the Simulator, debugging, asset catalogs, signing, archiving, and App Store submission.
Developers who internalize this split get the best of both: a fast, AI-assisted editor and Apple's complete, required toolchain underneath it.
It is worth understanding why this limit exists, because it applies to every tool in the category, not just Windsurf. The boundary is not a missing feature someone forgot to add.
Building an iOS app depends on Apple's compiler, SDKs, the Simulator, and the code-signing machinery, all of which are part of Xcode and the wider Apple toolchain. That toolchain runs only on macOS, and Apple does not ship it for general embedding inside other editors.
This is also why AI web builders that promise an app often produce a web or React project rather than a native Swift app. Generating code is one thing; compiling and signing a native binary that the App Store will accept is a separate, Apple-controlled step.
So when any editor appears to fall short here, the realistic fix is never to find a hidden setting. It is to pair the editor with Xcode, a Mac, and an Apple Developer Program membership.
If you hit a wall, run through a short mental checklist before assuming the tool is at fault. It usually points straight at the right tool for the task.
If the problem involves running, debugging, or seeing your UI, that is Xcode or the Simulator, not Windsurf. Open the project in Xcode and use its run and debug controls.
If it involves a certificate, a provisioning profile, an archive, or an upload, that is signing and distribution, which live entirely in Xcode and App Store Connect, backed by your developer account.
If it involves editing a storyboard, a XIB, or an asset catalog visually, that is an Xcode editor. And if it is writing, refactoring, or generating code, that is exactly where Windsurf and Cascade belong. Matching the task to the tool resolves nearly every can't-do-it moment.
Keep both applications open on the same project and the hand-off becomes second nature. You stop expecting either tool to do the other's job, and the workflow stops feeling like a series of dead ends.
That is the real resolution to this whole category of problem. There is nothing to fix in Windsurf itself; there is only a workflow to adopt, and once adopted it is fast, predictable, and durable across project and tool updates alike.
Because Windsurf is an editor, not a build system. It doesn't contain Apple's compiler, the iOS Simulator, code signing, or the App Store pipeline. Only Xcode and Apple's toolchain can build and ship iOS apps.
No. The Simulator, debugger, and view inspector are Xcode features that depend on Apple's frameworks. Open your project in Xcode to run on the Simulator or a device while editing in Windsurf.
Use the integrated terminal with swift build, swift test, or xcodebuild for a quick compile check. This still requires Xcode to be installed. For interactive debugging and the Simulator UI, switch to Xcode.
No. Code signing, provisioning, archiving, and App Store Connect uploads are all done in Xcode, and submission requires an Apple Developer Program membership. Configure signing in Xcode's Signing and Capabilities tab and submit from there.