Skip to content

SwiftUI Project Setup ​

Create a new Xcode project optimized for AI-assisted development. SwiftUI is all code — no Storyboards or XIBs — so Claude Code can read and write every part of the UI. A single SwiftUI codebase can target iPhone, iPad, Mac, Apple Watch, and Apple TV.

When to use ​

Use when starting a new app with Claude Code for any Apple platform, or when deciding between SwiftUI and UIKit for a new project.

The pattern ​

Creating the project ​

Create the Xcode project using Xcode's GUI (File → New → Project). For a universal app, choose the Multiplatform → App template. For a single platform, choose the platform-specific App template. In both cases:

  • Interface: SwiftUI
  • Language: Swift
  • Storage: SwiftData (if you need persistence)

The multiplatform template generates a single codebase with platform-specific targets. SwiftUI handles most layout differences automatically — a NavigationSplitView renders as a sidebar on iPad and Mac, a stack on iPhone.

Don't try to create the project from the command line or have Claude Code generate the .xcodeproj — Xcode owns that file.

Why SwiftUI exclusively ​

Use SwiftUI for all new projects. It's declarative, all code, runs on every Apple platform, and is where Apple is investing. UIKit and AppKit are platform-specific and involve Storyboard/XIB files that Xcode is territorial about. If you're coming from Vue.js, the mental model translates well: reactive state, composable components, declarative rendering.

Platform-adaptive patterns ​

SwiftUI provides platform-aware views that adapt automatically:

  • NavigationSplitView — sidebar on iPad/Mac, stack on iPhone
  • TabView — tabs on iPhone, sidebar on iPad (iPadOS 18+)
  • .toolbar — adapts placement per platform
  • #if os(watchOS) / #if os(macOS) — conditional compilation for platform-specific code

Start with the shared code and only branch when a platform genuinely needs different behavior.

Dependencies ​

Use Swift Package Manager (SPM) for third-party dependencies. It's built into Xcode and is the direction Apple is going. Avoid CocoaPods. For app projects, SPM dependencies are tracked in the .xcodeproj — add or update them through Xcode (File → Add Package Dependencies) or XcodeBuildMCP's project tools rather than editing files directly. Package.swift only exists for standalone Swift packages, not app projects.

What Claude Code should and shouldn't edit ​

Safe to edit: All .swift source files, asset catalog contents, .xcodebuildmcp/config.yaml, Info.plist (with care).

Let Xcode manage: .xcodeproj / .pbxproj, Storyboards / XIBs, provisioning profiles, code signing settings, build settings.

Project structure ​

A typical multiplatform app layout:

MyApp/
├── .xcodebuildmcp/
│   └── config.yaml
├── MyApp.xcodeproj/          ← Xcode manages this
├── MyApp/
│   ├── MyAppApp.swift        ← App entry point (shared)
│   ├── ContentView.swift     ← Root view (shared)
│   ├── Models/               ← SwiftData models (shared)
│   ├── Views/                ← SwiftUI views (shared)
│   ├── ViewModels/           ← Observable state (shared)
│   └── Assets.xcassets/      ← Images, colors (shared)

Platform-specific code lives alongside shared code using conditional compilation rather than separate directories.

Trade-offs ​

  • You must use Xcode's GUI to create the initial project
  • SwiftUI previews require Xcode — Claude Code can't render them directly, but XcodeBuildMCP can screenshot the simulator
  • Not every SwiftUI API is available on every platform — watchOS and tvOS have smaller API surfaces. Claude Code can check availability with #available
  • Some views behave differently across platforms — always test on the target simulator, not just iPhone