For the local workflow in this series, start with a Mac that can run your selected Xcode, a compatible simulator runtime and enough storage for build products. Add a coding client only after a normal app build works. This separates environment failures from generated-code failures.
Separate three kinds of access
Apple tools, an Apple developer account and an AI subscription are different things. Buying access to one does not configure the others. Running a simulator build is also different from signing an app for a physical phone or distributing it through TestFlight.
Apple explains the distinction between a free developer account and program membership in its account overview. Check the current membership requirements when you reach distribution; this lesson does not ask you to purchase anything.
- 1Mac + selected Xcode
- 2Available iOS runtime
- 3Known project + scheme
- 4Baseline before agent
Inspect the installed toolchain
Open Terminal and run these read-only checks:
xcodebuild -version
xcode-select -p
xcrun simctl list devices available
The first identifies Xcode, the second identifies the selected developer directory, and the third lists usable simulator devices. Keep their meanings separate. An installed Xcode application does not necessarily mean a command-line session has selected it; a simulator application does not necessarily mean the runtime you need is installed.
For this series preparation, the local check reported Xcode 26.6, build 17F113. Available devices used an iOS 26.5 runtime, and none was initially booted. These are facts about the test Mac, not minimum system requirements for your machine.
Readiness checklist
| Check | Passing evidence | If it fails |
|---|---|---|
| Xcode selection | Version and developer directory are available | Open Xcode and finish its setup; inspect the selected tools |
| Simulator runtime | An available device is listed | Install a compatible runtime through Xcode settings |
| Project | A project/workspace and scheme are known | Open the project and inspect its schemes |
| Build | The selected scheme compiles | Diagnose the first meaningful build error |
| Agent connection | Expected tools are discoverable | Check the client configuration and executable path |
Do not paste account passwords, signing credentials or authentication tokens into a debugging conversation. Most environment diagnosis needs a version, a command and a redacted error, not account access.
Add the agent last
The repository's local npm tools require Node.js 20 or later. That dependency belongs to the MCP server, not to Swift itself. You can learn Xcode and run a Swift project before installing it. When you add the server, use the setup instructions for your actual client rather than copying another client's configuration.
Keep a short environment record in the project: Xcode version, deployment target, simulator runtime, scheme and the build command you used. This gives later failures a baseline. If the baseline changes after an update, investigate that change before rewriting the app.
Completion checkpoint
You are ready for the next lesson when you can name the selected Xcode version and find an available simulator. A successful account login is not the completion criterion here. Apple's run-destination guide explains the next step from available device to running app.
Related reading
- Choose an AI client for your iOS workflow
Understand the difference between a skill, a local MCP connection and ChatGPT web setup.
- Five checks for an AI-built SwiftUI app
Use persistence, search and accessible states to make “it works” a testable claim.