A practical guide to combining Zed's fast editing and AI with Xcode's native build, Simulator, and signing tools for a smooth iOS development workflow.
Zed is fast and pleasant for writing code, with built-in AI and low latency. Xcode is the required tool for building, running, and shipping iOS apps.
Instead of choosing one, many developers use both. They edit in Zed and build in Xcode, getting speed where they type and native tooling where it counts.
This works because both tools operate on the same files on disk. A change saved in one is immediately visible to the other.
The key is a clear division of labor. Zed authors code; Xcode compiles, runs the Simulator, signs, and submits.
Open your project folder in Zed and the same project in Xcode. For a full app, open the .xcodeproj or .xcworkspace in Xcode and the containing folder in Zed.
Make sure your Swift toolchain is installed via Xcode so SourceKit-LSP is available to Zed for completions.
Install the Swift extension in Zed so .swift files get language server support. This gives you completions and navigation while you edit.
Confirm both tools see the same files by making a trivial edit in Zed, saving, and watching it appear in Xcode's editor.
Zed's language server experience is smoothest on Swift Package Manager packages because module resolution is manifest-driven.
Where it makes sense, structure feature code into local Swift packages. This modularizes your app and gives Zed cleaner indexing.
You can then develop and test those packages largely in Zed, and integrate them into the app you build in Xcode.
This is not mandatory, but it plays to Zed's strengths. Package-based code tends to complete and navigate more reliably in the editor.
Use Zed for the bulk of writing and refactoring. Its speed, multi-cursor editing, fast search, and AI assistant make authoring quick.
Lean on the AI for boilerplate and explanations, and on SourceKit-LSP for completions and go-to-definition.
Use Zed's integrated terminal to run swift build or swift test for package targets without leaving the editor.
Keep changes small and save often. Frequent saves keep Xcode in sync and make the build step predictable.
When you need to build the app, switch to Xcode and use its build system. Xcode owns compilation, linking, and the app bundle.
Run in the Simulator or on a device from Xcode. There is no Simulator inside Zed, so this always happens in Xcode.
Use Xcode's debugger for breakpoints, the view hierarchy inspector, and step-through debugging. These tools have no Zed equivalent.
For performance work, use Instruments from Xcode. Profiling memory, CPU, and energy is part of Apple's toolchain, not the editor.
SwiftUI previews render in Xcode's canvas, not in Zed. When you iterate on UI, keep Xcode open to see live previews.
A common rhythm is to write view logic in Zed, then flip to Xcode to preview and fine-tune layout visually.
For pure logic like view models, formatters, and networking, you may barely need Xcode until build time.
Match the tool to the task. Visual UI benefits from Xcode's canvas; text-heavy logic benefits from Zed's speed.
Code signing, provisioning profiles, entitlements, and capabilities are configured in Xcode and Apple's developer portal.
Archiving your app and uploading to App Store Connect happens through Xcode. No editor, Zed included, performs this step.
Distribution requires a paid Apple Developer Program membership. Budget for that separately from any editor costs.
Keep these responsibilities firmly in Xcode. Trying to shortcut Apple's signing and submission flow outside Xcode only creates problems.
Switching between Zed and Xcode is smoother when you lean on each tool's navigation. In Zed, fast fuzzy file search and the command palette get you to any file quickly.
Use go-to-definition and symbol search in Zed to move through Swift code without hunting manually, then switch to Xcode only when you need to build or inspect the running app.
In Xcode, keep the same file open so you land in a familiar place after editing in Zed. Both tools read the same files, so your position on disk carries over.
Small navigation habits add up. The less time you spend finding code, the more the Zed-plus-Xcode split feels like one workflow rather than two.
Not everything in an iOS project is Swift. Storyboards, asset catalogs, and Interface Builder files are best edited in Xcode, which understands their formats visually.
Zed can open these files as text, but that is rarely useful for anything beyond a quick look. Treat them as Xcode's territory.
For property list, JSON, and configuration files, Zed is perfectly comfortable, and its speed makes bulk edits pleasant.
The rule of thumb is straightforward. Text-based files are fine in Zed; visual and Apple-specific formats belong in Xcode's dedicated editors.
With responsibilities divided, a comfortable rhythm emerges. Open both tools in the morning on the same project and keep them side by side.
Do the bulk of your writing, refactoring, and AI-assisted work in Zed, saving frequently so Xcode always sees the latest code.
Jump to Xcode to build, run in the Simulator, check SwiftUI previews, and debug whenever you need to see the app actually run.
Commit often with Git so the handoff between tools never risks losing work. Over a few days this loop becomes second nature and you stop thinking about which tool does what.
When a team splits work between Zed and Xcode, small inconsistencies can creep in. Agree on formatting and lint rules so files look the same regardless of the editor.
Share a common settings baseline where practical, so completions, formatting, and behavior are predictable across the team.
Document which tasks belong in which tool. New teammates ramp faster when the Zed-for-editing, Xcode-for-building split is written down.
Consistency is what turns a personal workflow into a team workflow. The tools matter less than everyone agreeing on how to use them.
Because both tools share files, syncing is mostly automatic, but a few habits help. Save in Zed before building in Xcode.
If you add files or change dependencies, let Xcode re-resolve packages and rebuild so its index and Zed's language server stay accurate.
Use Git as the shared source of truth. Commit regularly so switching between tools never loses work.
With this loop, you get the best of both: Zed for fast, AI-assisted authoring and Xcode for full native build, debug, and release.
No. Running in the Simulator or on device happens in Xcode. Zed is for editing; Xcode handles build, run, and debug.
Generally no. They share the same files on disk. Save in Zed before building in Xcode to keep them in sync.
In Xcode's canvas. Zed has no preview canvas, so keep Xcode open when iterating on UI.
Zed's SourceKit-LSP experience is smoothest on Swift Package Manager packages because module resolution is manifest-driven, giving cleaner completions.
Yes. Signing and App Store submission require Xcode and a paid Apple Developer Program membership, regardless of which editor you use.