Web サイトベースのアプリを公開するには、ビルドをアップロードするだけでは不十分です。正しい開発者アカウント、安定したモバイル エクスペリエンス、正確なストア アセット、プライバシー開示、テスト、署名された iOS および Android ビルド、および明確なレビューアー アクセスが必要です。
Apple と Google は別のシステムを使用しています。製品とブランドの情報を一度準備したら、各ストアのプラットフォーム固有の手順を完了します。
ストアの掲載情報を作成する前に
Web サイトがアプリのコアのように動作する準備ができていることを確認します。
- すべての画面で HTTPS を使用します
- レイアウトはズームしなくてもスマートフォンの幅で機能します
- ナビゲーション、ログイン、チェックアウト、フォームはタッチ操作で機能します
- すべてのリンクとサポート ページは公開されています
- 読み込み中、空、エラー、オフラインの状態を理解できる
- プライバシー ポリシーにはアプリと Web サイトについて正確に説明されています
- ユーザーはアカウントとデータ管理を見つけることができます
Apple の審査ガイダンスでは、提出物は最終的なものであり、機能的な URL を使用し、プレースホルダー コンテンツは含まれないようにする必要があるとされています。 Google も同様に、アプリが実際に提供するものをリストに記載することを期待しています。
ステップ 1: 適切なエンティティが所有するアカウントを作成する
りんご
個人または組織として Apple Developer Program に参加してください。 Apple は現在、会員料金を年間 99 ドルとしています。組織は法的身元を確認する必要があり、通常は D-U-N-S 番号が必要です。
顧客に販売者として会社名が表示される場合は、請負業者ではなく会社を登録してください。 Apple では、特定の規制対象サービスを提供する法人がそのサービスを提出することを求めています。
Googleプレイ
Play Console デベロッパー アカウントを作成し、適切な個人または組織のアカウント タイプを選択し、該当する登録料を支払い、本人確認を完了します。 Google は現在、公開されているアクセス規約に、完全な配布に対する 1 回限りの 25 ドルの料金を記載しています。
新しい個人アカウントには、運用環境にアクセスする前にテスト要件があります。 2023 年 11 月 13 日以降に作成された Personal Play Console アカウントも、実稼働アクセスを申請する前に、連続 14 日間オプトインした状態を維持する少なくとも 12 人のテスターによるクローズド テストを実行する必要があります。組織アカウントは免除されます。脱落者によって時計がリセットされないように 12 名以上のテスターを募集し、アプリが直接公開リリースに移行できると想定せずにダッシュボードを確認します。
ステップ 2: アプリ ID を予約する
アプリ名、iOS の場合はバンドル ID、Android の場合はパッケージ名を選択します。パッケージ識別子は、次のような技術的で永続的な ID です。 com.yourcompany.yourapp;後で表示されるアプリ名を変更しても、それらは変更されません。
使用する権利のある名前を使用してください。ストアと関連する商標データベースの両方で競合がないか検索します。ストアで禁止されている透明部分のない高解像度の四角いアイコンを用意します。
ステップ 3: 署名付きビルドを生成する
iOS アプリはアーカイブされ、Apple のツールチェーンを通じて App Store Connect にアップロードされます。 Android は、Google Play 用の署名付き Android App Bundle を使用します。どちらのストアでも最小ビルド要件が適用されます。2026 年 4 月 28 日以降、App Store Connect は Xcode 26 および iOS 26 SDK でビルドされていないアップロードを拒否し、Google Play では Android 16 (API レベル 36) をターゲットとする新しいアプリとアップデートが必要になりました。コードなしのコンバーターまたはマネージド サービスはこれらのアーティファクトを生成できますが、ソース コード テンプレートではそれらをビルドする必要があります。
認証情報への署名とアカウントへのアクセスは、ビジネスの管理下で継続します。キーを紛失したり、元請負業者に唯一の管理者アカウントの所有を許可したりすると、今後の更新が困難になる可能性があります。
ステップ 4: 本物のアプリ価値を追加する
これは、Web サイトベースの iOS アプリでは特に重要です。 Apple の最小機能ルールでは、アプリには、再パッケージ化された Web サイトを超える機能、コンテンツ、インターフェイスの価値が含まれるべきであると定められています。
役立つ追加機能には次のものが含まれます。
- モバイルタスクに合わせたネイティブナビゲーション
- ユーザーが明示的に選択するプッシュ通知
- 関連コンテンツへのディープリンク
- ネイティブの共有、アップロード、カメラ、またはダウンロードの動作
- 保存されたコンテンツまたは選択したオフライン アクセス
- 洗練されたスプラッシュ、読み込み、エラー、接続なしのエクスペリエンス
チェックボックスをオンにするためだけに機能を追加しないでください。ネイティブの動作がアプリの実際の目的をサポートする場合、レビュー担当者とユーザーの両方にメリットが得られます。
ステップ 5: 正確なストア アセットを作成する
アプリ名、短い説明と長い説明、サポートされているキーワード、カテゴリ、アイコン、電話のスクリーンショット、連絡先の詳細、サポート URL、プライバシー ポリシーの URL を準備します。
スクリーンショットには実際のアプリが表示されている必要があります。未検証の最高級品、偽の賞、でっち上げられた推薦状、または提出されたビルドに含まれていない機能は避けてください。最初のスクリーンショットを使用して、主要なジョブをわかりやすい言葉で説明します。
Web サイトからアプリへの製品の場合、強力なシーケンスは次のようになります。
- 主要なホーム画面または検出画面
- 主要なトランザクションまたはメンバー エクスペリエンス
- モバイルナビゲーション
- 通知や保存されたコンテンツなどの便利なネイティブ機能
- アカウントまたはサポートの管理
ステップ 6: プライバシーとコンテンツの宣言を完了する
どちらのストアも、アプリが収集するデータ、その使用方法、個人情報に関連付けられているかどうか、第三者がデータを受け取るかどうかを尋ねています。 Web サイト、分析、認証、支払いサービス、通知、広告、および組み込みツールを監査します。
回答では、ネイティブ シェルだけでなく、アプリのエクスペリエンス全体を説明する必要があります。 Web サイトが電子メール アドレスを収集したり、アプリ内に分析 SDK をロードしたりする場合は、開示の際に考慮してください。
また、年齢レーティング、広告、コンテンツの権利、暗号化、財務機能、健康情報、所在地、子供のアクセスに関する質問に答える必要がある場合もあります。
ステップ 7: レビューの前にテストする
iOSのテスト
TestFlight を使用してリリース候補をインストールします。可能であれば、複数の画面サイズでテストしてください。サインイン、Apple が要求するアカウントの動作、許可されている場合の外部支払いフロー、権限、プッシュ通知、リンク、削除制御を確認します。
Androidのテスト
Play Console の内部または非公開のテスト トラックを使用します。内部テストは、ビルドを自分のチームと共有する最も簡単な方法です。個人アカウントが 2023 年 11 月 13 日以降に作成された場合は、本番環境に申請する前に、ステップ 1 で説明したクローズド テストを、少なくとも 12 人のオプトイン テスターを使用して連続 14 日間実行する必要があります。
両方のプラットフォームで、接続の遅さ、新規インストール、期限切れのログイン、拒否されたアクセス許可、システムの戻るジェスチャ、ファイルの選択、別のアプリまたはブラウザを開くパスをテストします。
ステップ 8: レビュー担当者に完全なアクセス権を与える
アプリにログインが必要な場合は、アクティブなデモ アカウントと手順を指定します。レビュー中はそのアカウントを動作させ続けてください。明白ではない機能、特別なハードウェアのニーズ、地域の制限、レビュー担当者がネイティブ機能を見つけられる場所について説明します。
Google は開発者に対し、制限されたコンテンツに対して有効な認証情報を提供することを特に推奨しています。ログインを通過できないレビュアーはアプリを検証できません。
ステップ 9: 各アプリを送信する
App Storeへの申請
App Store Connect で、アップロードされたビルドを選択し、必要なメタデータとコンプライアンスの質問を完了し、レビューメモを追加して、バージョンを送信します。 App Store Connect のメッセージを監視し、Apple が情報を要求した場合に正確に応答します。
Google Playへの申請
Play Console で、アプリのコンテンツとストアの掲載タスクを完了し、アプリ バンドルを正しいトラックにアップロードし、リリース ノートを追加し、ポリシーの警告を解決して、リリースをロールアウトします。 Google Play は Android App Bundle を使用して、デバイスに最適化されたパッケージを作成します。
Googleの リリースドキュメント 現在のコンソール ステップの信頼できる情報源です。
Web サイトアプリが拒否される一般的な理由
アプリは薄いウェブサイトのラッパーのように感じます
ネイティブ ナビゲーションとアプリ固有のユーティリティを改善します。単にフレーム内のデスクトップ ページではなく、コア エクスペリエンスが iOS 上で便利で洗練されたものであることを確認してください。
レビュー担当者がサインインできない
有効な認証情報を提供し、安全な場合にはレビュー アカウントの有効期限切れのワンタイム コードを無効にし、ログイン手順を説明します。
リストが誤解を招く
ビルドと一致しないスクリーンショットまたはクレームを削除します。制限を明確に説明します。
プライバシーに関する回答は不完全です
ネイティブ コードだけでなく、Web トラッカーやサードパーティ サービスも監査します。プライバシー ポリシーを公開かつ具体的にします。
リンク、購入、アップロードがアプリ内で中断される
実際のデバイスですべての外部ハンドオフとリターン パスをテストします。どのリンクをアプリ内に残し、どのリンクをブラウザで開くかを意図的に決定します。
必要なアカウント制御がありません
ユーザーがアカウントを作成できる場合は、両方のストアの現在の削除要件とデータ管理要件を確認し、必要なパスを明確に公開します。
承認後はどうなりますか?
すぐにリリースするか、手動でリリースするか、プラットフォームがサポートしているときに段階的にリリースするかを選択します。クラッシュ、Web リクエストの失敗、ログイン エラー、ユーザー レビュー、サポート チケットを監視します。製品が変更された場合は、ストアの説明とプライバシーの開示を最新の状態に保ちます。
Web サイトのコンテンツは、新しいアプリをビルドしなくても更新できますが、ネイティブ構成、SDK、権限、署名、またはポリシーの変更には新しいリリースが必要な場合があります。 Apple と Google が最小 SDK ターゲットを引き上げるため、少なくとも年に 1 回はストア主導のリビルドが行われることが予想され、誰がそれを作成するかを事前に確認します。
公開チェックリスト
- 開発者アカウントは適切な個人または会社によって所有されています
- Web サイトは応答性が高く、安全で、本番環境に対応しています
- アプリは有意義なモバイル価値を追加します
- どちらの署名付きビルドも実際のデバイスにインストールして実行します
- ストア名、説明、アイコン、スクリーンショットが完成しました
- プライバシーとコンテンツの宣言は Web エクスペリエンスをカバーします
- サポートとプライバシーの URL はログインなしで機能します
- レビュー担当者の資格情報と手順は最新のものです
- 価格と可用性が設定されています
- レビューメッセージを監視するためにチームメンバーが割り当てられます
ビルドをまだ作成していない場合は、ビルドから始めてください。 Web サイトをアプリに変換するためのガイド または SiteTo.App でサイトをプレビューする.
