シミュレーターでは動くのに、先生や友人へ渡せるファイルを作れず止まっています。
最短解決は、先にプロジェクトを確認し、Product > Archive でアーカイブを作成し、提出目的に合う形式で書き出すことです。Macが手元にない場合は、コードを別の端末で準備してから、互換性のある実機またはリモートMacで最終ビルドを行います。
このページは、初めてSwiftUIの課題を完成させた学生向けです。シミュレーターで動かせるものの、Debug、Archive、書き出しファイル、TestFlightの違いが分からない人や、Windows・ChromebookからXcode作業を続けたい人を対象にしています。
交付先を先に決める
「パッケージ化」と言っても、必要な結果は同じではありません。授業で画面を見せるだけならRun、先生へ成果物を渡すならArchiveと書き出し、友人の端末で試してもらうなら署名や配布方法の確認が必要です。
| 目的 | まず行う操作 | 受け取るもの | 初心者が避けること |
|---|---|---|---|
| 授業中に動作を見せる | Schemeを選んでRun | シミュレーターまたは接続端末上の実行結果 | いきなり配布設定を始める |
| ソースコードを提出する | プロジェクトを保存・共有 | プロジェクト一式と説明 | 実行結果だけを完成品と思う |
| 先生へビルド成果物を渡す | Archive後に書き出し | 配布用ファイルなど | 署名条件を確認せず渡す |
| 友人に試してもらう | 配布方法と端末条件を確認 | 登録端末向けのテスト版、またはTestFlight用の準備 | 自分のシミュレーター結果をインストール可能と説明する |
Runは、いわば授業中の「黒板に書いた草稿」をその場で動かす操作です。Archiveは、プロジェクトを配布や保存に向けた「提出用のまとまった記録」として保存する操作で、Appleの分散準備でもアーカイブ作成後にArchives organizerから書き出しや配布を進めます。詳細はAppleのアプリ配布準備で確認してください。
Xcode 27でiOS Appをパッケージ化する方法：事前確認
最初に、プロジェクトを開いた直後に配布設定へ進まないでください。シミュレーターで正常に動くこと、必要な画像やSwift Packageが読み込まれること、保存したコードへ戻れることを順番に確かめます。
Schemeは「どのアプリを、どの設定で動かすか」をまとめた実行メニューです。複数のターゲットがある課題では、別のSchemeを選ぶと、意図しないアプリをArchiveすることがあります。Schemeの調整方法は[AppleのBuild Scheme説明](https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project)に従ってください。
Bundle Identifierはアプリを識別する住所のようなものです。署名は、誰が作ったアプリかを確認するための電子的な証明で、コードの文法エラーとは別の問題です。次の表で、止まった場所を分けてください。
| 画面に出る状態 | まず見る場所 | 判断 |
|---|---|---|
| 赤いコンパイルエラー | 該当ファイルと最初のエラー | コードを直してから再実行 |
| 画像や色が見つからない | Assetsとファイル参照 | リソースをプロジェクトへ戻す |
| Identifierや署名の警告 | Signing設定とアカウント | 配布条件を確認し、推測で証明書を作らない |
| Archiveが作成されない | Report navigatorとビルドログ | 最初の失敗原因を読む |
| シミュレーターだけ動く | 実機・配布向け設定 | 「動いた」と「渡せる」を分ける |
学生が授業の課題を提出する場合、最初に必要な作業は何ですか。
コードを保存し、プロジェクトが開くことを確認し、選択したSchemeでシミュレーターを動かします。先生がソースコードだけを求めているなら、そこで止めても構いません。インストール可能な成果物を求められている場合だけ、次のArchiveへ進みます。
DebugからArchiveへ進む
プロジェクトが実行できたら、画面上部のScheme、対象デバイス、ビルド設定を見直します。課題用アプリのターゲットを選び、シミュレーター専用の選択になっていないか確認してください。
そのうえで、現在のXcode 27環境に表示されるメニューを確認し、通常の流れとしてProduct > Archiveを実行します。Appleのアーカイブ問題の公式トラブルシューティングでも、アーカイブ時の設定やログを確認する考え方が示されています。Xcode 27の画面名が手元の環境と異なる場合は、表示された公式ヘルプを優先してください。
完了するとArchives organizerに記録が現れます。ここで成功と判断する条件は、単に処理が終わったことではなく、該当するアプリ、正しいバージョン、現在のソースコードに対応するArchiveが表示されることです。
Archiveに失敗したときは、同じボタンを繰り返し押さないでください。最初の赤いエラーを読み、コード、リソース、Scheme、署名のどこで止まったかを分けます。Appleの公式説明でも、アーカイブ問題は設定や依存関係を切り分けて確認する流れになっています。
Archives organizerから書き出す
Archiveは、そのまま友人の端末へ渡す単一の完成ファイルとは限りません。Archives organizerでDistribute Appを選ぶと、登録端末向けの書き出し、App Store Connectへのアップロードなど、目的に応じた次の処理へ進めます。
| 学習目的 | 選ぶ方向 | 追加で確認する条件 |
|---|---|---|
| 先生へ記録を渡す | Archiveとプロジェクトを保存 | バージョン番号、対象アプリ、説明文 |
| 登録済み端末で試す | 登録端末向けに書き出す | 端末登録、署名、インストール方法 |
| TestFlightで配布する | App Store Connectへアップロード | アプリ記録、アカウント権限、審査・テスト条件 |
| まだ提出方法が不明 | Archiveを保管して先生へ確認 | 先に不要な公開手続きを進めない |
TestFlightは、App Storeへ一般公開する操作ではなく、ベータ版をテスターへ配る仕組みです。利用にはApp Store Connect側のアプリ記録などが関係するため、課題提出だけなら必須とは限りません。TestFlightの公式概要と、アプリ記録の作成手順を確認してから進めてください。
SwiftUIプロジェクトを先生が試せる形にするにはどうすればよいですか。
先生がソースコードを確認するなら、プロジェクト一式とビルド手順を渡します。実際の端末で試すなら、Archive後に利用できる配布方法、署名、登録端末の条件を先に確認し、書き出したファイルの種類とインストール方法を説明書へ書きます。
Macがない場合の接続手順
MacがなくてもiOS Appのパッケージ化はできますか。
コード作成、Gitへの保存、説明書の作成はWindowsやChromebookでも進められます。ただし、Xcodeを使う最終的なiOSビルドとArchiveは、互換性のあるmacOS環境が必要です。XcodeとmacOSの対応条件は、作業前に公式システム要件で照合してください。
作業は次のように分けると、環境の役割を間違えません。
- 手元の端末：コード編集、コミット、画像や説明書の整理
- リモートMac：Xcodeでプロジェクトを開く、コンパイル、Archive、書き出し
- 受け渡し場所：ソースコード、Archiveの記録、書き出しファイルを安全に保管
まずプロジェクトをリモートMacへコピーし、開けるか、依存関係が解決するか、シミュレーターで動くかを確認します。次にArchiveを一度だけ試し、成功したら書き出しへ進みます。接続が不安定な状態で何度も署名設定を変更するより、最小限の確認で環境の問題とプロジェクトの問題を分ける方が安全です。
必要なら、MACGPUのMacレンタル案内で、遠隔のMacを使う流れと安全確認を先に確認してください。利用地域や作業時間を比較したい場合は、MACGPUのMac利用プランを見て、短期の課題作業に合うかを自分の締切と照合します。
提出前の受け渡し確認
最後に、画面上で動いたことと、相手が使えることを分けて確認します。次のチェック項目は、先生へ提出する前に一つずつ実行してください。
- [ ] 最新のコードを保存し、コミットまたはバックアップを作成した
- [ ] 正しいSchemeとアプリのターゲットを選んだ
- [ ] シミュレーターで主要画面を確認した
- [ ]
Product > Archiveで対象プロジェクトのArchiveを作成した - [ ] Archiveに表示されるアプリ名とバージョン番号を確認した
- [ ] 提出目的に合う形式で書き出した
- [ ] ソースコード、書き出しファイル、操作説明を別々に確認した
- [ ] 先生や友人が必要とするインストール方法を記載した
- [ ] 自分の端末だけで動いたのか、相手の端末でも試せるのかを明記した
| 確認できた結果 | 何を意味するか | 提出時の書き方 |
|---|---|---|
| 自分のMacで実行できた | 開発中の動作確認ができた | 「ローカルで確認済み」 |
| シミュレーターで実行できた | シミュレーター上の動作確認ができた | 実機インストール済みとは書かない |
| Archiveが成功した | 配布準備に進める記録ができた | Archiveの対象と日時を記載 |
| 友人の端末で使えた | その条件で配布・インストールを確認できた | 端末条件と方法を記載 |
| TestFlightでテストできた | ベータ配布の経路を確認できた | 一般公開とは区別する |
自分のWindowsやChromebookでコードを準備し続ける方法は、編集費用を抑えられる一方、Xcodeの画面確認、macOS依存のビルド、Archive、署名エラーの調査をその端末だけでは完結できません。仮想環境は動作条件や速度、USB接続、ライセンス確認が別途必要になり、課題の締切前に新しい問題を増やすことがあります。
「プロジェクトを開く、コンパイルする、Archiveを作る」だけを短期間で済ませたいなら、リモートMacを使う方が手順を分離しやすい場合があります。常に重い開発を続ける人、物理iPhoneやUSB機器を頻繁に使う人には自分のMacが向きますが、授業の提出や一時的な検証なら、MACGPUの利用方法を確認してからレンタルする方が、購入前の判断を誤りにくいです。
まずはコードのバックアップを作り、手元のプロジェクトが開くことを確認してください。その後、互換性のあるMac環境でArchiveまで成功させ、必要な場合だけ書き出しやTestFlightへ進む、という順番なら、初めてでも作業の戻りを少なくできます。