A practical guide to configuring Trae as your Swift editor — installing SourceKit-LSP support, opening your project, and pairing it with Xcode the right way.
This guide assumes you are on a Mac, which is a hard requirement for any real iOS work regardless of which editor you use.
You need three things installed: Trae itself, Xcode from the Mac App Store, and the Xcode Command Line Tools. Xcode brings the Swift toolchain and SourceKit-LSP along with it.
Confirm the toolchain is active by running `xcode-select -p` in Terminal. It should point at your Xcode, and if it does not, run `sudo xcode-select -s /Applications/Xcode.app` to fix it.
Also run `xcrun --find sourcekit-lsp` to verify the language server binary is present. It ships inside the Xcode toolchain, so this confirms your foundation is healthy.
With those in place, you have everything needed to make Trae a productive Swift editor that hands off cleanly to Xcode for building and running.
Download Trae from the official site and install it like any other macOS app. Because it is VS Code-style, first launch will feel familiar.
On first run, sign in if you want the AI features, and take a moment to set your theme and keybindings. If you are coming from VS Code, look for a keymap option so your muscle memory carries over.
Open the command palette and get comfortable with it. Most configuration and agent actions are reachable from there, which keeps your hands on the keyboard.
Do not open your project yet. It is cleaner to add Swift language support first so that the moment you open your code, intelligence is available.
Finally, open the integrated terminal inside Trae and confirm `swift --version` prints your toolchain. This proves Trae sees the same environment your shell does.
Swift intelligence in a VS Code-style editor comes from a Swift extension that drives SourceKit-LSP. Open the extensions panel in Trae and search for the Swift language extension.
Install it, then reload the editor if prompted. This wires up completion, diagnostics, hover documentation, and go-to-definition backed by the same engine Xcode uses.
If the extension exposes a setting for the language server path, leave it on the default so it uses `xcrun sourcekit-lsp` from your active Xcode. Overriding it is only necessary for custom toolchains.
Some marketplaces and editors expose extensions differently, so if you cannot find a first-party Swift extension, check Trae's documentation for the recommended way to enable Swift and language servers.
Once installed, the plumbing is ready. The next step is opening a project in a way the language server can understand.
Open the root folder of your project in Trae — the directory containing your `.xcodeproj`, `.xcworkspace`, or `Package.swift`.
For a Swift Package (a `Package.swift` project), SourceKit-LSP works almost out of the box. It understands the package structure natively, so completion and diagnostics tend to light up quickly.
For an app target defined by an `.xcodeproj` or `.xcworkspace`, the language server needs a hint about how each file is compiled. This is where a compile database helps, covered in the next step.
Give the indexer a minute after opening. On a large project the first index pass takes time, and premature testing will make it look broken when it is only warming up.
Open a Swift file and hover over a symbol. If you see type information and documentation, the core setup is working.
For app targets, SourceKit-LSP gets the best results when it can read a `compile_commands.json` describing the build flags for each file.
You can generate one using an `xcodebuild`-based approach. A common route is to run `xcodebuild` and pipe it through a tool that emits `compile_commands.json`, or to use a dedicated generator that writes the file at the project root.
Place the resulting file where the language server expects it, typically the workspace root. Then reload Trae so the server picks it up.
With the compile database in place, completion for your own types, third-party dependencies, and framework symbols becomes far more reliable.
If you skip this step, expect solid results for Swift Packages but patchier completion for complex app targets. It is the single highest-leverage fix for weak Swift intelligence outside Xcode.
Now establish the two-editor loop that makes this setup productive. Keep Trae and Xcode open on the same folder at the same time.
Write and refactor in Trae, using the AI agent for scaffolding and repetitive edits. When you want to build, run, or debug, switch to Xcode and use its Run button, Simulator, and debugger.
Because both point at the same files on disk, changes you make in Trae appear in Xcode after a save, and vice versa. There is no import or sync step.
Avoid editing the same file in both simultaneously to prevent confusing overwrite prompts. Pick one editor per file at a time.
This division of labor plays to each tool's strength: Trae for fast, AI-assisted authoring; Xcode for the build system, signing, previews, and everything device-related.
Run a quick checklist. Open a Swift file and confirm completion, hover docs, and go-to-definition all respond.
Trigger a deliberate error, such as calling a method that does not exist, and confirm a red diagnostic appears inline. If diagnostics show, the language server is truly live.
Ask the AI agent to add a small function or a SwiftUI view and confirm it edits the file. This validates that the agent has project context.
Switch to Xcode and build the project to make sure nothing you configured broke the actual build. The build must always succeed in Xcode, because that is what ships.
If all of that passes, your setup is complete. From here, the workflow is simply write in Trae, build and run in Xcode, repeat.
A working setup can drift as your tools update, so a little maintenance keeps Swift intelligence reliable.
When you install a new major version of Xcode, re-run `xcode-select -p` and confirm it still points at the Xcode you intend to use. A silent switch here is a common cause of sudden completion failures.
After updating Xcode or the Swift extension, restart Trae fully rather than just reloading the window. Language servers cache their environment at launch, and a full restart guarantees they pick up the new toolchain.
Regenerate your `compile_commands.json` compile database whenever you add targets, change build settings, or pull large branch changes. A stale database is the most common reason completion quietly degrades on app targets.
Finally, keep the responsibilities clear in your head. Trae is the authoring surface and Xcode is the build authority, so when something behaves oddly, ask which of those two layers is actually involved before you start changing settings.
Yes, absolutely. Xcode provides the Swift toolchain, Simulator, code signing, and App Store submission. Trae is only the editor. Even the Swift language server that powers Trae's completion ships inside Xcode.
For app targets, SourceKit-LSP often needs a compile_commands.json compile database to know how each file is built. Swift Packages usually work without it. Generate the compile database and reload Trae.
You can edit Swift on any platform, but building, signing, and running an iOS app requires macOS and Xcode. There is no supported way to ship an iOS app without a Mac.
Core editing and SourceKit-LSP work offline once installed. The AI agent features generally require connectivity because they call cloud models.