SwiftUIの構想から数週間でApp Store公開へ

iOSプロジェクトでは、ある種の遅延が起こります。「数週間で」公開するはずだった機能が、開発範囲の拡大や想定以上に多かった申請手順のため、3か月後も開発中というものです。SwiftUIアプリを短期間で公開する鍵は開発速度ではありません。アプリに実装しないことを早く決め、もう一つ機能を追加したくなっても、その決定を覆さないことです。

当社は複数のSwiftUIアプリを短期間で公開してきました。このプロセスは再現できますが、開発範囲を守る規律、Appleへの申請手順の明確な理解、そして全機能がそろっていなくても品質のよい製品を公開する姿勢が必要です。実際の進め方を紹介します。

開発範囲は最初のコミット前に決める

iOSアプリを短期間でリリースするうえで最も重要な作業は、コードを書く前にあります。問うべきは「このアプリに何をさせるか」ではなく、「最初のバージョンで、利用者のどの一つの問題を解決するか」です。その問題に直接結び付かない機能は、バージョン2に回します。

これは思った以上に難しい判断です。ゼロから設計すると、ほぼすべてが必要に思えるからです。通知も、ソーシャル機能も、詳細な分析ダッシュボードも重要に見えます。しかし利用者は、アプリの中核機能を使って価値を感じるまでは、こうした機能を評価できません。一つのことをうまくこなし4週間で公開するアプリのほうが、六つのことをまずまずこなし4か月で公開するアプリよりも、有用なフィードバックを得られます。

実務で役立つのは、開発開始前に作る2列のリストです。MVPに含めるものと、明確に後回しにするものを並べます。後回しのリストは単なるバックログではなく、判断を徹底するための仕組みです。開発途中で追加される機能はすべて、現在のスプリントに入れるべきか、後回しのリストに入れるべきかを検討します。大半は後回しにすべきです。

最初の2週間：中核となる画面に集中する

目的が一つに絞られたSwiftUIアプリは、通常3〜5画面で動作します。初期設定の案内、1〜2画面の主要操作画面、設定またはアカウント画面です。最初の2週間で、これらの画面を機能面で完成させます。実際のデータを使い、正しい順序で必要な処理を実行できる状態です。見た目を磨き上げる必要はありません。アニメーションや文字のスタイルはシステム標準を使い、エラー表示は簡単なテキストのアラートで構いません。

この段階で重要なのは、後から変更しにくいアーキテクチャ上の判断です。ナビゲーション方式（NavigationStack、TabView、独自のコーディネーター）、状態管理（Observationフレームワークの@Observableを使うか、ObservableObjectを使い続けるか）、データの永続化（SwiftData、Core Data、単純な状態ならUserDefaults）を決めます。成り行きで決まるのを待たず、早い段階で明示的に判断することで、3週目にアプリの半分ずつで異なるナビゲーション方式が使われる事態を防げます。

Supabaseをバックエンドとして使うアプリでは、この段階で認証フローに特に注意が必要です。AppleのApp Reviewガイドラインでは、これらを別々の要件として定めています。アカウント作成に対応するアプリは、アプリ内でアカウントを削除できるようにする必要があります（ガイドライン5.1.1(v)）。また、主要なアカウントにGoogle Sign-Inなどのサードパーティ製ログインやソーシャルログインを使うアプリは、プライバシーを重視した同等のログイン方法も提供する必要があり、実際には通常「Appleでサインイン」が使われます（ガイドライン4.8）。Supabaseによる独自のメールアドレスとパスワードの認証だけを使う場合、「Appleでサインイン」は必須ではありませんが、アカウント削除フローはMVPに含める必要があります。公開初日から利用されるからではなく、なければApp Reviewで却下されるからです。ソーシャルログインを追加する場合は、同等のログイン方法も同時に計画してください。

3〜4週目：仕上げとTestFlight

3週目には、アプリが製品らしくなってきます。この段階で、読み込み中の表示（単にスピナーを表示するだけでなく、待ち時間を納得できる表示にすること）、データがない状態の表示、ネットワーク通信が失敗したときのエラー表示に対応します。これらは単なる見た目の仕上げではありません。データがまだなく、時にはネットワークの問題も起こる新規利用者にとって、アプリの使い心地そのものです。

TestFlightでの配布は4週目ではなく3週目に始めます。初めてアップロードするビルドでは、想定外の問題が見つかるからです。App Store Connectはテスト配布前にバイナリを検証し、権限設定の不足、プロビジョニングプロファイルの組み合わせの誤り、必須のInfo.plistキーの欠落など、Xcodeでのローカルビルドでは表面化しない問題を検出します。3週目に見つかれば本申請までに修正できます。公開前夜に見つかっても、その余裕はありません。

この段階のTestFlightのフィードバックは、機能の要望を集めるより、画面移動で迷う箇所や操作方法が伝わらない箇所を見つけるために役立ちます。「どんな機能が欲しいですか？」ではなく、「やろうとしたのに、操作方法が分からなかったことはありましたか？」と尋ねます。前者では、開発期間を何か月も延ばす要望リストが生まれます。

App Storeへの申請手順

App Storeへの申請には、初めて申請する人が想像する以上に多くの手順があり、どの段階でもリリースが止まる可能性があります。コードが完成してから着手するのではなく、事前に進めておくことで、最終週に慌てずに済みます。

申請前にはスクリーンショットが必要で、画面サイズごとに認められているピクセル寸法のいずれかに合わせなければなりません。2026年10月時点で、App Store Connectは6.9インチの画面区分（例：iPhone 16 Pro Max）のiPhoneスクリーンショット、または6.9インチのものを提供しない場合は6.5インチの画面区分（例：iPhone 14 Plus）のスクリーンショットを求めています。アプリがiPadで動作する場合は、13インチのiPadスクリーンショット（例：iPad Pro（M4）や12.9インチiPad Pro（第6世代））も必要です。Simulatorでの作成自体は簡単ですが、最終日まで残すと時間がかかります。簡単なFastlane snapshotの設定で自動化できます。

App Store Connectの「Appのプライバシー」では、収集するすべてのデータの種類、利用目的、利用者の身元との関連付けの有無を申告する必要があります。任意のメタデータではなく、不完全なら申請できません。Supabaseの認証を使う場合、少なくともメールアドレスとユーザー識別子を収集するため、両方の開示が必要です。外部SDKや分析ツールを使えば、申告項目は増えます。申請前にデータ収集の実態を正確に整理すれば、公開後に申告内容を更新する手間を避けられます。

Appleによると、通常、申請の50%は24時間未満、90%は48時間未満で審査されます。重大なバグの修正やイベントに合わせた公開など、特別な事情がある場合は迅速審査を申請できます。審査では、人がAppleのガイドラインに照らしてアプリを確認します。初回申請でよくある却下理由は、アカウント関連機能の不足（アプリ内でのアカウント削除、またはソーシャルログインに加えて提供する同等のログイン方法）、ログインが必要なアプリでのデモアカウント情報の未提供、テスターが遭遇しなかった例外的な状況でのクラッシュです。

何を削り、どう削るか

短期間のリリースで最も難しいのは、機能を削った結果が、間に合わせではなく意図的な設計に見えるようにすることです。利用者は、意図的にシンプルなアプリと未完成のアプリを見分けます。その違いを生むのは画面数よりも、存在する機能の完成度です。用意する画面は、すべて完成させる必要があります。

初回リリースで削っても影響が少ないのは、プッシュ通知（正しく設定するのが複雑で、利用者が通知を歓迎するにはアプリへの信頼が必要）、ソーシャル機能（フォロー、共有、ランキングは利用者が増えれば有用ですが、公開時には焦点をぼかします）、高度なカスタマイズ設定（大半の利用者は初期設定を変えません）、MVPでは必要のない大規模なバックエンド基盤を要する機能です。

初回リリースでも削るべきでないのは、エラー処理（ネットワークのタイムアウトでクラッシュすると、利用者に長く不満が残ります）、読み込み中の表示（反応を示さず固まると、壊れているように見えます）、基本的なアカウント管理（MVPでもパスワードの再設定とアカウント削除が必要）です。

公開後：最初の2週間が最も重要

公開後の最初の2週間は、App Storeの評価が最も不安定な時期です。テストで見つからなかったクラッシュにより、早い段階で星1つのレビューが相次ぐと、長期的な評価に大きな悪影響が出ます。最初の1週間はInstrumentsとXcodeのクラッシュ管理画面を毎日確認します。重大なクラッシュを発見したら24時間以内に修正版を申請します。App Reviewにはクラッシュ修正向けの迅速審査があります。

公開直後に後回しの機能を追加したくなっても、少なくとも2週間は控える価値があります。複雑さを増やす前に、利用者が中核機能を実際にどう使うかを理解するほうが、開発の勢いを示すより有益です。バージョン2に回した機能は、公開準備と並行して作るよりも、実際の利用状況を2週間観察した後のほうが適切に設計できます。

App Storeのアイコン却下への対処 — 申請の最終段階で問題になるsRGB、アルファチャンネル、TrueColorの要件。
数千問を扱う試験対策アプリの構築 — MVPを多機能な製品へ発展させる際のアーキテクチャ。
Swift 6の並行処理：実践的な移行ガイド — 短期間のリリース開発で、Swift 6の並行処理に関する警告に対応する時期と、後回しにする判断。