Claude CodeとXcodeでSwiftUI iOSアプリを開発する手順
Claude CodeをXcodeと組み合わせてSwiftUIのiOSアプリを作る手順です。役割分担、ビルド許可、XcodeとのMCP連携による画面確認まで扱います。
Claude CodeとXcodeは併用できます。編集はターミナルのClaude Code、ビルドと実行はXcodeが担い、Xcode 26.3以降はMCP経由でXcode PreviewsをCLIから取得できます。この記事では、プロジェクトの用意からビルド・実行コマンドの許可範囲、画面確認までを順に進めます。
Claude CodeとXcodeの役割分担
Claude Codeが担うのはSwiftファイルの編集とターミナルコマンドの実行で、コンパイルとシミュレーター・実機での実行はXcode側が担います。SwiftUIはStoryboardを使わずコードだけでUIを組む仕組みなので、Claude Codeによるファイル編集との相性がよく、GUIエディタとの往復が発生しません。
Xcode自体にAIコーディング支援を組み込みたい場合は、Xcode 26の「Intelligence」設定からログインするClaude for Xcodeという別の入り口もあります。こちらはXcode本体に統合された機能です。本記事で扱うのは、すでにClaude Code CLIを使っている、またはターミナル中心のワークフローでSwiftUI開発を進めたい場合の手順です。
XcodeとClaude Codeをつなぐ3つの方法
XcodeとClaude Codeの連携は、使う入り口によって3通りに分かれます。
- ターミナルで併用する: Claude Codeでコードを編集し、Xcodeでビルド・実行する。追加設定は不要で、この記事のステップ1〜3がそのまま使えます
- MCPでXcodeにつなぐ: Xcode 26.3以降で、Claude CodeからXcode Previewsの画面を取得できます。画面の確認方法はステップ4、接続の設定はClaude for Xcodeの使い方にあります
- Xcodeの中でClaudeを使う: Xcode 26.3にはClaude Agent SDKの統合があり、Claude Codeと同じ基盤をXcode内から使えます。設定はClaude for Xcodeの使い方にあります
前提条件
必要なのは次の3点です。
- MacとXcode(iOSシミュレーターランタイムを含む)
- インストール済みのClaude Code CLI(手順はClaude Code installガイドを参照)
- SwiftUI Appテンプレートで作成したXcodeプロジェクト、または既存のSwiftUIプロジェクト
Claude Codeの公式ドキュメントは、CLIについて「どのターミナルでも動く」と説明しています。Xcodeの統合ターミナルでも、別ウィンドウのターミナルでも、動作に違いはありません。インストール後のバージョンは次のコマンドで確認できます。
claude --version筆者の環境(v2.1.287)では 2.1.287 (Claude Code) と表示されました。以降の設定や操作は、このバージョンで確認した範囲に基づきます。
ステップ1: プロジェクトを用意してClaude Codeを起動する
Xcodeで新規プロジェクトを作る場合は、テンプレート選択で「App」を選び、インターフェースに「SwiftUI」を指定します。プロジェクトフォルダーができたら、そのディレクトリでClaude Codeを起動します。
cd ~/dev/MyLandmarksApp
claude起動後はいつも通り自然言語で依頼できます。「ContentViewにNavigationStackを追加して、リスト画面と詳細画面を作って」のように、実装したい画面を具体的に伝えるところから始めます。既存のSwiftUIプロジェクトに追加機能を実装させる場合も、対象ディレクトリでClaude Codeを起動するだけです。App Store提出前の確認は、Privacy Manifestの宣言漏れを洗い出す手順にまとめています。
ステップ2: Apple公式チュートリアルの構成を下敷きに依頼を分ける
Appleは長年「Introducing SwiftUI」というチュートリアル(Landmarksアプリを題材にした所要時間4時間25分のコース)を公開してきました。このページ自体が「現在のSwiftUIやXcodeの実践方法をもう反映していない」と明記しており、後継として「Develop in Swift Tutorials」への案内が出ています。
現行のDevelop in Swift Tutorialsは、プロジェクト作成、画面設計、SwiftUI(ビュー階層・状態管理)、SwiftDataによるデータ永続化の順に進みます。その後に、アプリ開発全体の統合、機械学習とAI、visionOS、配信準備が続きます。前半の並びが、Claude Codeへの依頼を分ける目安になります。
依頼を1段階ずつ進める
- 1
ビュー構造だけを作らせる
「NavigationStackで一覧画面と詳細画面を作って。モデルはダミーデータでいい」と依頼します。Xcodeで動きを確認してから次へ進みます。
- 2
状態管理を足す
ボタンや入力欄を追加し、状態がどの画面に流れるかを確かめます。
- 3
永続化に置き換える
「ダミーデータをSwiftDataに置き換えて」と依頼します。動いていた画面を壊していないか、ここでもう一度確認します。
- 4
テストを同じ流れで足す
Apple公式の学習パスにも「Add functionality with Swift Testing」というチュートリアルがあり、モデルの実装とテストをセットで扱っています。「Swift Testingでユニットテストも書いて」と続けると、実装とテストがずれにくくなります。
一度に頼む範囲を絞ると、Claude Codeが変更するファイル数が抑えられ、差分を読み切れる量に収まります。
CLAUDE.mdに毎回の前提を書く
依頼のたびに同じ前提を説明し直さずに済むよう、プロジェクトルートにCLAUDE.mdを置いておくと効果的です。CLAUDE.mdはセッションの開始時に毎回読み込まれる永続的な指示ファイルで、ビルドコマンドやコーディング規約、プロジェクト構成のような「毎回説明し直すこと」を書く場所だと公式ドキュメントは位置づけています。
# MyLandmarksApp
- 対象: iOS 18以降、SwiftUI Appライフサイクル
- アーキテクチャ: MVVMを基本にする
- ビルド確認: 変更後は次のコマンドでビルドが通るか確認する
xcodebuild -scheme MyLandmarksApp -destination 'platform=iOS Simulator,name=iPhone 16' build
- UIコンポーネントは Views/ 配下、データモデルは Models/ 配下に置くビルドコマンドはスキーム名とシミュレーター名まで具体的に書いておくと、次のステップで許可ルールを絞りやすくなります。シミュレーター名は手元に入っているものに合わせてください。公式ドキュメントはCLAUDE.mdを1ファイル200行未満に収める目安を示しており、長くなると指示が守られにくくなるとしています。/init を実行するとClaude Codeがコードベースを調べて雛形を作り、すでにファイルがある場合は上書きせずに改善案を出します。ビルドが失敗したときのログが長い場合は、xcodebuildのエラーを絞る手順が使えます。
ステップ3: ビルドとシミュレーター操作の許可範囲を決める
Claude Codeはxcodebuildやxcrun simctlのようなコマンドもBashツール経由で実行できます。初期設定では、読み取り専用の一部コマンドを除き、コマンドを実行するたびに確認を求められます。許可ルールを書くと、一致するコマンドは確認なしで実行されます。
公式ドキュメントが示す書式は Bash(コマンド *) です。* は空白を含む任意の文字列に一致し、末尾の * の前に空白を置いた場合は引数なしのコマンドにも一致します。Bash(xcodebuild *) 1本で、xcodebuild build も xcodebuild test も対象になります。テスト用に Bash(xcodebuild test *) を別に足す必要はありません。
ここで決めるのは、許可を広く取るか狭く取るかです。
許可ルールの広さ
広く取る
Bash(xcodebuild *) と Bash(xcrun simctl *) の2本です。xcodebuildは archive や clean、-exportArchive による書き出しなど、ビルド以外の操作も許可されます。simctlにはシミュレーターのデータを消す erase も含まれます。
狭く取る
CLAUDE.mdに書いたスキームまで固定します。Bash(xcodebuild -scheme MyLandmarksApp *) のように先頭を決めます。固定されるのはスキームまでで、同じスキームの archive や clean も許可に含まれます。simctlも boot・install・launch に分けます。想定外のコマンドには確認が出ます。
Claude Codeはコマンドを && や ; などの区切りで分けて、それぞれが許可ルールに一致するかを個別に判定します。そのため xcodebuild ... build && open ... のようにつなぐと、open 側のルールがなければそこで確認が出ます。
{
"permissions": {
"allow": [
"Bash(xcodebuild -scheme MyLandmarksApp *)",
"Bash(xcrun simctl boot *)",
"Bash(xcrun simctl install *)",
"Bash(xcrun simctl launch *)"
]
}
}置き場所は2つあります。プロジェクトの .claude/settings.json に置くと、リポジトリを共有する全員に同じルールが効きます。~/.claude/settings.json に置くと、すべてのプロジェクトのxcodebuildに許可が及びます。個人の好みで試すだけなら .claude/settings.local.json も使えます。確認ダイアログで「Yes, and don't ask again」を選んだBashコマンドは、リポジトリ直下の .claude/settings.local.json に保存されます。登録済みのルールとその出どころは、セッション中に /permissions で一覧できます。
ルールを入れるのは、挙動が読めるようになってからが安全です。許可した範囲では、Claude Codeがあなたの承認なしにビルドや実行を進めます。ファイル編集の確認だけを減らしたいときは、Shift+Tabで切り替えられる acceptEdits モードがあります。これはファイル編集と mkdir・mv・rm などの基本的なファイル操作を自動承認するもので、対象は作業ディレクトリ内のパスに限られます。xcodebuildのようなBashコマンドの確認は別に残ります。
コマンドラインから確認できること
許可ルールや権限モードは、起動時の引数でも渡せます。筆者の環境のv2.1.287では、claude --help に次のオプションが載っていました。
--allowedTools, --allowed-tools <tools...>: 許可するツールを指定--disallowedTools, --disallowed-tools <tools...>: 拒否するツールを指定--permission-mode <mode>: 権限モードを指定--add-dir <directories...>: ツールに追加でアクセスを許すディレクトリ
たとえば --allowedTools にルール文字列を渡せば、設定ファイルに書かずに1回のセッションだけビルドを許可できます。
ステップ4: 画面の見た目を確認する方法を選ぶ
SwiftUIは書いたコードと実際の見た目が一致しているかの確認が要になります。確認の入り口は使っているClaude Codeの種類によって変わります。
| 入り口 | 前提 | 特徴 |
|---|---|---|
| Claude Code Desktop | 前提macOS版DesktopアプリのCodeタブ | 特徴アプリをシミュレーターで動かすとiOS Simulatorペインが自動で開く。Accessibility権限は不要 |
| Claude Code CLI + Xcode MCP | 前提Xcode 26.3以降 | 特徴Model Context Protocol経由でXcodeと接続し、Xcode PreviewsをCLIから離れずキャプチャできる |
| Desktop Computer Use | 前提macOS版Desktopアプリ | 特徴画面全体を操作できる代わりにAccessibility・Screen Recording権限が必要 |
Xcode 26.3で追加された連携は、Claude Agent SDKによるXcode統合の一部として提供されています。Anthropicの発表では、Claudeが作っているUIをXcode Previewsとして取得し、問題を見つけて直す流れが挙げられています。CLI環境のままXcode Previewsを見ながら実装を反復したい場合に向いています。設定手順や自律実行の詳細はClaude for Xcodeの使い方にまとめています。
CLIにMCPサーバーを足すときの書式は claude mcp add のヘルプで確認できます。v2.1.287では次の形が例として載っています。
claude mcp add [options] <name> <commandOrUrl> [args...]
claude mcp add my-server -e API_KEY=xxx -- npx my-mcp-server-s, --scope <scope> でlocal・user・projectのどこに登録するかを選べ、既定はlocalです。ステップ3の許可ルールと同じく、チームで共有するならprojectを選びます。
SwiftUIの実装にApple Foundation Modelsのようなオンデバイスの機能を組み合わせたい場合は、Apple Foundation ModelsでClaudeを使い分けるも参考になります。画像ボタンのラベル抜けや固定フォントの洗い出しはSwiftUIのアクセシビリティ抜けを洗う手順で扱います。
よくあるつまずき
古いチュートリアルのサンプルコードをそのまま参照してしまう
「Introducing SwiftUI」のLandmarksサンプルは、Apple自身が現行の実践方法を反映していないと明記しています。Claude Codeに実装方針を尋ねるときは、古いチュートリアルの構文をそのまま踏襲していないか、生成されたコードを確認します。
許可ルールを入れたのにビルドの確認が出る
ルールが一致していない原因は、主に3つ考えられます。1つ目は、&& でつないだコマンドの片側にルールがないこと。2つ目は、先頭の部分が違うこと(Bash(xcodebuild -scheme A *) を入れて別のスキームを実行した場合など)。3つ目は、* の前の空白の有無で、Bash(ls *) は lsof に一致しませんが Bash(ls*) は一致します。何が登録されているかは /permissions で確認できます。
Xcode PreviewsのMCP連携が動かない
Xcode PreviewsのキャプチャはXcode 26.3で追加された機能です。26.0〜26.2系では利用できないため、Xcodeのバージョンを先に確認します。
実機のiPhoneでの確認ができない
Desktop版のiOS Simulatorペインも、Computer Useによる画面操作も、対象はシミュレーターまたはMac自身の画面です。物理的なiPhone・iPadでの動作確認は、Xcodeから自分で実機ビルドして目視するか、スクリーンショットを会話に添付して伝えます。
生成されたSwiftUIコードが古いAPIを使っている
Claude Codeが提案するコードが、非推奨になったモディファイアや古いナビゲーションAPI(NavigationViewなど)を使っていることがあります。CLAUDE.mdに対象OSのバージョンを明記しておくと、この種のずれは起きにくくなります。気づいた場合は「NavigationStackに書き換えて」のように対象APIを名指しして直します。既存コードのSwift 6対応はSwift 6のstrict concurrencyを段階的に直す手順を参照してください。リリース後のクラッシュは、クラッシュログ(.ips)のシンボリケート手順で原因の行まで辿れます。
まとめ
Apple公式の学習パスの並びは、Claude Codeへの依頼を小さく区切る目安になります。許可ルールは、CLAUDE.mdに書いたビルドコマンドと同じ粒度で書くと、広すぎず狭すぎない範囲に収まります。Xcode本体でのAIコーディング支援が目的なら、CLIではなくClaude for Xcodeを使う選択肢もあります。TestFlightやApp Storeへ送る工程は、Fastlaneのリリース自動化で確認を挟む形にできます。多言語対応はxcstringsの未翻訳と要レビューを埋める手順にまとめています。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。
- developer.apple.com/tutorials/swiftui
- developer.apple.com/tutorials/develop-in-swift
- code.claude.com/docs/en/ide-integrations
- code.claude.com/docs/en/settings
- code.claude.com/docs/en/claude-md
- anthropic.com/news/apple-xcode-claude-agent-sdk
- code.claude.com/docs/en/permissions
- code.claude.com/docs/en/memory
- code.claude.com/docs/en/permission-modes