アプリが完成しました。ブラウザで動作し、UI が正しく、コア フローが安定しています。すると、デプロイが現れ、イオニック プロジェクトを 3 つの異なるリリース トラックに変えて、各トラックには独自のツール、署名規則、レビュー プロセス、および更新戦略が含まれます。
そのような場合、重要な時間がしばしば失われます。機能を書くことではなく、ネイティブ ビルド、Web ホスティング、リリース オートメーション、ポスト ランチ フィックスを 1 つのプロセスに組み合わせることです。 イオニック アプリのデプロイ iOS、Android、および PWA の配信を別々のプロジェクトとして扱うのではなく、1 つのリリース システムとして扱うことが、最も効果的です。
目次
- あなたのイオニック アプリは完成しました。次は何?
- プロダクション用にプロジェクトを準備する
- iOS と Android 向けのネイティブ デプロイ
- IonicアプリをPWAとして展開する
- CI/CDパイプラインを使用したビルドの自動化
- Capgoを使用した即時更新の配信
- Ionic アプリの展開に関する一般的な問題とベスト プラクティス
あなたの Ionic アプリは完成しました。なぜなら、開発者は同じポイントにたどり着くことが多いからです。
多くの開発者は同じポイントに到達します。 ionic serve looks great, local API calls work, and the app feels done. It isn’t done. It’s only browser-tested, unsigned, and disconnected from constraints of App Store review, Play signing, and production web hosting.
バンドルが再現可能かどうか ネイティブ プロジェクトが同期されているかどうか環境変数がきれいに分離されているかどうか
そのシフトは、Ionicsがハイブリッドの道を走っていることを意味します。アプリにはWeb層がありますが、ネイティブシェルはインストール、署名、レビュー、更新の方法を決定します。デプロイを後回しに扱うチームは、プラットフォーム間の構成ドリフト、古いネイティブプロジェクト、脆弱な手動リリースステップと結びついています。成功したチームは、すべてのターゲット用に1つのリリースパスを定義し、各プラットフォーム固有のステップを明確にします。
きれいなデプロイサイクルは次のようになります。
- プロジェクトを準備する Capacitor構成、アプリ識別子、アイコン、環境値、プロダクションビルドが一貫しているようにします。
- ネイティブリリースアーティファクトを作成する AndroidとiOSのためにプラットフォームツールを使用して、Ionicコマンドだけではありません。
- PWAビルドを配信する ブラウザへの即時アクセスが必要なユーザー向けに。
- 定期的な部分を自動化する ビルドは開発者がチェックリストを思い出す必要がないようにします。
- リリース後のアップデートを計画する Webアセットの修正は、必要に応じてアプリストアのレビューを待たなくても済みます。
あなたの現在のアプリがまだ「スマホのシェル内で起動するウェブアプリ」に思えている場合、その問題を直すことから始めましょう。 その移行のための参考となるガイドはこちらです。 Capacitorを使用してウェブアプリをモバイルアプリに変える方法.
最初の成功のストアの提出は、知恵ではなく、 discipline から来ることが多い。
プロダクション用にプロジェクトを準備する
ビルドを生成する前に、プロジェクトをリリース候補として扱いましょう。 多くの場合、ローカル開発で無害だった小さな不一致が、プロダクションで高価になるのは、ローカル開発とプロダクションの間の小さな差異です。
環境チェックから始めましょう
基本的なものから始めましょう:
ionic doctor
npm ci
npx cap doctorionic doctor 環境問題や一般的な CLI を検出します。 npm ci リリース用の作業では、より良い選択肢です。 これは、コミットされたロックファイルから正確にインストールされるためです。 npm install プラグインやプラットフォームの不一致を表面化するのに役立ちます。 これは、XcodeやAndroid Studioがそれを読みやすいエラーに変える前に、 npx cap doctor Capgoは、XcodeまたはAndroid Studioがエラーに変換する前にプラグインとプラットフォームの不一致を表面化するのに役立ちます。
リリースビルドをクリーンな状態から使用することはできるだけよくなさい。アプリがローカルパッチ、削除されたフォルダ、または手動で編集されたネイティブファイルの後でしかビルドされない場合、デプロイプロセスはまだ安定していないことを意味する。
毎回行うべきチェックがいくつかある:
- アプリIDを確認する変更
appId遅らせるとストアと署名の混乱を生じる可能性がある。 - プラグインの状態を確認するネイティブプラグインの変更は通常、最新の同期とプラットフォームの再開が必要になる。
- 環境のインジェクションを確認するAPIエンドポイント、キー、機能フラグは環境固有の設定からではなく、インライン定数から来るべきである。
リリースターゲット間で異なるべきであるべき要素の詳細な説明については、この記事 開発とCapacitorアプリの生産環境の違い は実用的な参考資料である。
Capacitorの設定を固定
開く capacitor.config.ts 生産インフラとアプリメタデータのように、確認する
通常のファイルは次のようになります
import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.myapp',
appName: 'My App',
webDir: 'www',
bundledWebRuntime: false,
};
export default config;すぐに気になるのは3つのフィールド
| 設定 | なぜ重要か | よくある間違い |
|---|---|---|
| appId | ストアや署名で使用されるネイティブパッケージ識別子 | スターター プロジェクトからプレースホルダーを残す |
| appName | native shell でのアプリ名 | 開発ラベルを使用し、変更を忘れる |
| webDir | ディレクトリ Capacitor はnativeプロジェクトにコピーされる | Capacitor が期待する出力フォルダとは異なる場所にビルドする |
開発中のローカルサーバーを使用する場合は、生産設定がnativeビルドをそのサーバーに指すことを確認する。単一のミスにより、開発環境で動作するがリリース時は白画面が表示されるという問題が多発する。
実践的なルール: リリースビルドがライブローカルサーバー設定に依存している場合、それはリリースビルドではない。
アセットを一度生成する
アイコンとスプラッシュスクリーンを手動でサイズ変更しない。高品質のソースアセットを1つ使用し、各プラットフォームの出力から生成する。
現在の Capacitor ワークフローでは、多くのチームが CLI エコシステムを通じて公式のアセットツールを使用している。スタックバージョンによってパッケージが異なる場合も、同じ規則を守っている: バージョン管理下で1つの標準的なアイコンと1つの標準的なスプラッシュソースを保管し、出力を生成し、XcodeとAndroid Studioで結果を確認する。
__CAPGO_KEEP_0__ ワークフローでは、PWAアイコンが最新の状態であるが、Androidが古い前景アセットを使用し、iOSが古い起動画像を表示しているという問題が発生することがある。
A production passの重要なステップは
- プロダクションモードでWebアセットをビルドする
- ネイティブプロジェクトを同期する
- 各ネイティブIDEを開いて、アプリ名、アイコン、パーミッション、署名設定を手動で確認する
- 実機でテストする前に、ストアにパッケージするものは何もしないでください
iOSとAndroid向けのネイティブデプロイ
ネイティブデプロイは、Ionicアプリが「ただのWeb」からプラットフォームの規則に応えるようになる場所です。Webバンドルは共有できますが、署名、パッケージング、ストアの要件がプロセスに入ると、AndroidとiOSはすぐに分かれます。
Web層をビルドする
常にネイティブパッケージングに触れる前に、最新のWebアセットを生成する
ionic build
npx cap sync古い慣習から ionic build --prod 現代のプロジェクトでは、フレームワークのツールによってプロダクションの動作は異なりますが、原則は変わりません: 最適化されたリリースビルドを生成し、それをネイティブプラットフォームに同期する
Sync した後、ネイティブ プロジェクトを直接開く:
npx cap open android
npx cap open iosこの時点でもレビューするのはよい機会です。 Android の設定: Capacitor アプリの設定 プロジェクトが不安定なネイティブ設定を持っている場合、まだ修正が必要です。
Android のリリースワークフロー
Android のリリースパスは iOS よりも予測可能ですが、署名設定が適切に設定されていないと破綻します。
アップロード用キーストアを 1 回生成し、安全に保存する:
keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias uploadキーストアファイル、エイリアス、パスワードを安全なシークレットストアに保存してください。コミットしないでください。チームチャットに残してはいけません。誰かが保存したと想定してはいけません。
Then, Gradle に署名のワイヤリングを設定します。チームは、この設定を Gradle に行うか、Capacitor の Live Update に行うかを選択します。 build.gradle Play Store への提出用のリリースアーティファクトは通常、 signingConfigs __CAPGO_KEEP_0__
のアプリケーションを使用して生成されます。 AABAndroid Studioで署名済みバンドルを生成するためのメニューのパスを使用し、リリースバリアントを選択し、アプリバンドルをエクスポートします。コマンドラインビルドを好みます。Gradleは署名設定が完了したらそれも処理できます。
Androidの一般的な落とし穴は、よく知られた方法で現れます。
- 誤ったキーストアパスワード 署名エラーを引き起こし、より劇的なものに見えます。
- デバッグ署名残り物 ローカルにインストールできるビルドを作成しますが、ストアのリリースには有効ではありません。
- プラグインのデシンクロ プラグインのネイティブ依存関係を変更し、スキップした場合に発生します。
npx cap sync. - 異なる識別子でPlayコンソールアプリエントリを作成した場合に問題を引き起こします。 Play Console app のエントリが異なる識別子で作成された場合、問題が発生します。
A pattern that works well is this: commit web code, build the web layer, sync native, build release artifact from the native project, and archive the exact commit hash alongside the generated bundle.
iOS リリース ワークフロー
iOS は厳格で、ほとんどのデプロイメントのトラブルは署名 ID の混乱によるものではなく、code の問題によるものではない。
Xcode でプロジェクトを開き、直接 署名＆キャパシティに移動します。選択したチームが正しいことを確認し、Bundle ID が App Store のレコードとプロビジョニングに一致し、自動署名が期待どおりに機能しているか、または意図的に手動プロビジョニングに置き換えられていることを確認します。
通常、次の動的要素と戦うことになります:
| アイテム | 機能 | 問題のポイント |
|---|---|---|
| Bundle ID | アプリを App Store レコードとプロビジョニングと紐付けします | Apple が期待しているものと一致しません |
| 証明書 | 署名者を識別する | 誤った証明書がインストールされているか、期限切れ |
| プロビジョニング プロファイル | アプリとコンテキストに基づいてビルドを承認する | 特定のアプリとコンテキストに対してビルドを許可する |
プロファイルがアプリIDまたはチームと一致しない Archiveアーカイブ
.アーカイブが完了したら、Organizerウィンドウを使用してApp Store Connectに配布する。
Xcodeが署名が壊れていると言う場合は、正確にbundle ID、チーム、プロファイル名を読み、変更する前に何もしないでください。ランダムに証明書を再生成すると問題が悪化することがよくあります。
このガイドは、最初のアーカイブと提出前に役立つ基本的な理解を提供します。
1 つの重要な教訓: 生成されたネイティブ ファイルを無理に編集しないでください。 必要な場合は、再現可能な構成をプロジェクト設定、プラグイン構成、またはビルドスクリプトに置きます。 手動編集が誰も文書化していない場合、リリースは一度成功しますが、次回の開発者がプロジェクトを同期すると失敗します。
イオニック アプリの PWA への展開
PWA のパスは、ユーザーに最速のルートを提供します。 ストアのレビュー、署名の式、インストールの抵抗はありません。 ブラウザから即座にアクセスできる人にとっては、速度は非常に便利です。
ネイティブ アプリが主なチャネルである場合でも、速度は有用です。 多くのチームは、内部ツール、プレロギン エクスペリエンス、管理パネル、またはストアのインストールが必要な抵抗を加える市場で、PWA を並行配布サーフェイスとして使用しています。
ウェブに意図的に作ります
PWA は、プロダクション ウェブ ビルドから始まります:
ionic build重要なのはコマンド自体ではなく、出力が最適化され、プロダクション サービスに指示され、最終的なアセットとマニフェストを含むことです。
展開する前に、次のファイルを確認してください:
index.htmlアセットの正しいコンパイルを参照していることを確認してください。manifest.webmanifestプロダクション名、アイコン、表示設定が必要なものだけを含んでいます。- サービスワーカー ファイル オフライン キャッシュを使用する場合のみ存在する必要があります。
- 環境出力 ライブエンドポイントを参照するようにしてください。ローカルまたはステージングサービスを参照しないようにしてください。
オフライン機能を有効にするには注意が必要です。
Angularを使用するIonicスタックの場合、Angularサービスワーカーはオフラインサポートとキャッシュの通常のパスです。強力ですが、誤って設定すると簡単です。
データが古くなっていてもユーザーがストックされないように、過度にキャッシュしないでください。キャッシュが少なすぎると、接続が不安定になってもアプリが堅実に感じられないようにしてください。正しい設定はアプリごとに異なります。マーケティング向けシェルではキャッシュを重視できますが、迅速に更新されるオペレーショナルデータを表示するダッシュボードではより保守的な戦略を選択する必要があります。
オフラインサポートを製品の決定として扱いましょう。キャッシュするスクリーンと最新のデータを取得するスクリーンを区別してください。
実際のシナリオをテストするようにしてください。仮想的な仮想環境ではありません。アプリを開き、デバイスを切断し、再起動し、まだ機能しているものを確認してください。次に、再接続してサービスワーカーが古いUIにユーザーを閉じ込めないように更新されることを確認してください。
ホスティングを選択する際にはワークフローを考慮してください。
Ionic PWAの場合、静的ホスティングプラットフォームは通常十分です。チームがよく利用する主なオプションはNetlify、Vercel、Firebase Hostingです。
実際的なトレードオフの視点です。
| プラットフォーム | 最適なフィット | Watch for |
|---|---|---|
| Netlify | 静的ファイルの簡単なデプロイとプレビュー | リダイレクトの動作は明示的な確認が必要 |
| Vercel | Gitベースのワークフローを使用しているフロントエンド重視のチーム | あるいは、ルーティング設定が調整が必要なアプリ |
| Firebase Hosting | Firebaseサービスを使用しているチーム | Firebaseが多すぎるとプロジェクト構造が混雑する |
どのホスティングサービスでも、簡単なデプロイフローは次のようになります: リポジトリの接続、ビルドコマンドの設定、出力ディレクトリの設定、環境変数の追加、クライアントサイドルーティングのリフレッシュ時に破損しないようにリライトルールの確認
ルーターベースのナビゲーションを使用しているIonicアプリの場合、ホスティング設定は未マッチしたパスをアプリのエントリポイントに送信する必要があります。そうしないと、ホームページは正常に動作し、深いリンクは失敗します。そののは、PWAデプロイの最も一般的なミスの一つです。
CI/CD Pipelinesを使用した自動ビルド
手動リリース作業は一度は許容される。次に、それは負担になる。誰かがsyncステップを忘れる、誰かが汚れたブランチからビルドする、誰かが間違った設定で署名するなど、突然生成されたアーティファクトが信頼できなくなる。
CI/CDはそれを修正する。リリースシーケンスをcodeに変える。記憶に頼るのではなく、毎回アプリがどのようにビルド、sync、テスト、パッケージ化されるかを正確に定義する。
pipelineに含めるもの
イオンプロジェクトの場合、有用なpipelineは次の作業を順番に実行する。
- 依存関係をロックファイルからインストールする。
- ウェブアプリをビルドする。
- Capacitor プラットフォームをsyncする。
- テストを実行するか、少なくとも基本的な検証を行う。
- ターゲットプラットフォーム用のネイティブアーティファクトを生成する。
- ビルド出力を保存または公開する。
その流れは、良いインフラストラクチャの習慣も重要です。ビルドランナー、アーティファクトストレージ、またはデプロイメントステップが脆弱な場合、このガイド 小規模企業向けのクラウド最適化の基本 は読む価値があります。同様の運用の規律は、モバイル配信パイプラインにも適用されます。
実践的なGitHubアクション
GitHubアクションは、多くのIonicチームが既にcodeをGitHubにホストしているため、デフォルトの設定です。以下のワークフローは、Androidリリースビルドの全体的な形を示しています。
name: Android Release Build
on:
push:
branches:
- main
jobs:
build-android:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build web assets
run: npm run build
- name: Sync Capacitor
run: npx cap sync android
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Build Android bundle
run: cd android && ./gradlew bundleReleaseこれは、リリースを署名するには、キーストアの材料とGradle署名構成も提供する必要があります。これは意図的に行われました。署名は、パブリックワークフロー ファイルから分離されるべきです。
モバイルに焦点を当てた実装パスを求めている場合は、この__CAPGO_KEEP_0__アプリのCI/CD設定に関する記事 CI/CD設定のためのCapacitorアプリのセットアップ シークレットと署名の衛生
モバイルCI/CDの最難関は、YAMLを書くことではありません。シークレットを扱うことです。将来のインシデントを引き起こすことなく。
リポジトリまたは組織のシークレットを使用して:
__CAPGO_KEEP_0__
- キーストアのパスワード
- キーアリセンス
- エンコードされたキーストアファイル
- リリース中のAPIトークン
- 環境依存のビルド値
Androidの一般的なパターンは、キーストアをbase64でエンコードし、エンコードされた文字列をシークレットに格納し、ワークフロー中の文字列を再構築し、Gradleに再構築されたファイルを指示することです。同様の原則は、署名材料に適用されます: ビルド時に入力し、リポジトリに格納しない。
CI/CDは人間のエラーを排除するのではなく、隠されたtribal知識を集中させるべきではありません。リリースシークレットがどのように組み合わさるかを1人の開発者だけが理解している場合、pipelineは依然として脆弱です。
実用的な推奨事項: バリデーションとリリースを分離する。Pull Requestはインストール、lint、テスト、Webビルドを実行し、保護されたブランチまたは手動の承認ゲートが署名されたプロダクションアーティファクトをトリガーする。そうすると、正常な開発のためにパイプラインを速くし、実際の配布のために制御することができます。
Capgoのインスタント更新をShippingする
リリースストアはネイティブcodeの変更、パーミッションの変更、またはアプリバイナリを変更するものに必要です。テキストの修正、スタイリングの修正、またはJavaScriptのバグがすべてWeb層に存在する場合、良い車両ではありません。
なぜなら OTA更新 イオニクスとCapacitorプロジェクトにおける重要な点です。チームは、インストール済みアプリにアップデートされたウェブアセットを配信できるようになります。ただし、変更は、ネイティブシェルがすでにサポートしている範囲内に収まる限り、ストアのレビューを待つ必要はありません。
OTA更新で取り扱うべきもの
OTA更新を使用するべき変更は次のとおりです。
- JavaScriptロジックの修正 新しいネイティブプラグインが必要ない場合。
- CSSの調整 破損したレイアウトやブランドの更新など。
- コピーの変更 文言、ラベル、法的テキストなど。
- 静的アセットの交換 アプリがすでにロードする方法を知っている場合。
本来はnativeの変更の代用として使わないでください。nativeの依存関係を追加したり、権限を変更したり、storeでレビューされたバイナリに含まれるべきものを変更した場合は、通常のstoreリリースを出します。
その境界は重要です。OTAの全体的な目的は、速度と制御であり、無責任にプラットフォームの規則を回避することではありません。
最初のインシデントが発生する前にチャンネルを設定してください。
最良のOTAワークフローは チャンネルを使用します。生産チャンネルは安定した更新をユーザーに提供します。ステージングまたはベータチャンネルは、内部テスターが実際にインストールされたアプリで更新を検証できるように、更新を先に受け取ります。
そのパターンは、緊急な修正を推し進むことの最悪のOTAの間違いを避けるのに役立ちます。緊急修正はもちろん、ガードレールが必要です。
一般的なセットアップは、プラットフォームのドキュメントに従ってプラグインのインストールとアプリの初期化から始まり、環境によってチャンネルの割り当てに進みます。 アプリストアで安全なOTA更新についての記事 は、境界を正しく設定するための良好な参照点です。
Push small fixes without touching native code
アップデーターが統合された後、実用的ワークフローは単純になります。更新されたウェブアセットをビルドし、目的のチャンネルに公開し、更新ポリシーに従ってアプリが起動したときに更新を取得して適用するだけです。
A実用的な例は、モバイルレイアウトのバグ修正です:
- イオニックアプリのCSSを調整します。
- プロダクションウェブビルドを実行します。
- ステージングチャンネルに生成されたバンドルを公開します。
- インストール済みのビルドでテストします。
- 同じ修正をプロダクションにプッシュまたは公開します。
このアプローチは、インシデント対応を変えます。OTAがなければ、悪いウェブ層のバグは、ストアレビューとユーザーの新しいバイナリへの採用を待つことになります。 OTAがあれば、影響を受けたファイルを修正し、正しいユーザーに配信し、制御された方法でロールアウトを監視できます。
迅速な更新は、安全にターゲットを設定し、必要に応じてロールバックできる場合にのみ有効です。
OTAの利益を受けるチームは、無神経なチームではありません。明確なリリース境界、名前の付いたチャンネル、ウェブ層の修正をネイティブリリースから別のストリームとして扱う習慣を持つ、規律のあるチームです。
一般的なデプロイ問題とベストプラクティス
ほとんどのデプロイ問題は、ユニークではない。チーム間で繰り返されるのは、同じミスが締め切りのプレッシャー下で繰り返されるからです。
繰り返し現れる失敗
Android署名エラーは、通常、間違ったパスワード、間違ったエイリアス、またはリリース設定で使用されている間違ったキーストアファイルの問題です。 その場合、暗号化の回転を無理に続けるのではなく、ファイル、エイリアス、シークレット値を確認してください。
iOSビルドの失敗は、通常、Bundle ID、チームの選択、証明書、およびプロビジョニングプロファイルの間の不一致に帰着します。 Xcodeのエラーメッセージは密集していますが、不一致は通常、Literalです。 そのうちの1つの値は、他の値と一致しません。
インストール後、白い画面がもう１つのクラシックです。 その原因には、次のものがあります。
- 開発用サーバーにアプリが指し示されている バンドルされたアセットではなく
- Webアセットが再構築されていない 前
npx cap sync - context HTML text fragment from a longer Capgo UI string (parent key `create_an_issue_and_discuss_before_working_on_a_new_feature`). Page/area: Capgo marketing website. Role: Long marketing or legal paragraph. Seen in: page contributing.astro. Message key `create_an_issue_and_discuss_before_working_on_a_new_feature` (Create An Issue And Discuss Before Working On A New Feature). | HTML text fragment from a longer Capgo UI string (parent key `mention_issue_before_working`). Page/area: Capgo marketing website. Role: Website copy sentence. Seen in: page contributing.astro. Message key `mention_issue_before_working` (Mention Issue Before Working).
- プラグインの変更がネイティブプロジェクトに同期されていない リリースビルドの実際のプロジェクトに
実行環境の値が欠けている
最も良い実践は面白くないが、それがなぜ効果的であるかは理解している。
環境設定の真実の元となるものを1つに保つ。クリーンなブランチからビルドする。リリースコミットをタグする。リポジトリ外の署名材料を保管する。実機でインストールしたビルドをテストする。シミュレータやブラウザタブだけでは十分ではない。
実行環境の設定を1つに保つ。クリーンなブランチからビルドする。リリースコミットをタグする。リポジトリ外の署名材料を保管する。実機でインストールしたビルドをテストする。シミュレータやブラウザタブだけでは十分ではない。
If your team ships Capacitor apps and wants a safer way to deliver web-layer fixes after launch, Capgo __CAPGO_KEEP_0__
