メインコンテンツにジャンプ
チュートリアル

Capacitor JS アプリを繰り返しストアレビューなしで更新する方法

Capacitor JavaScript の iOS と Android のアップデートを、全ての小さな修正に対して毎回フルアプリレビューを提出することなく、実践的でポリシーに従ったプレイブック

マーティン・ドナディュー

マーティン・ドナディュー

コンテンツマーケター

Capacitor JS アプリを繰り返しストアレビューなしで更新する方法

嬉しい質問ですね。

Capacitor アプリを安全に配信するチームで広く使用されている実践的なアプローチを共有しています。法律のアドバイスを提供していません。

重要な区別はこちらです。

  • ネイティブの提出 __CAPGO_KEEP_0__は新しいネイティブ動作と主要な機能のためにまだ必要です。
  • リアルタイム更新 はJavaScript/Webの修正とアプリの既存範囲内での調整のために使用されます。

iOSとAndroid両方がこのモデルを使用できますが、ポリシー安全なワークフローとして扱う必要があります。 簡単に言うとAppleとGoogleは許可するものは同じ境界線を共有しています。AppleとGoogleは同じ境界線を共有していることを簡単に言うと、以下のことができます。

__CAPGO_KEEP_0__は、埋め込まれたWeb層(HTML/CSS/JS)によって解釈されることができますが、再提出する必要はありません。

主な機能の追加がアプリの目的を変更する場合は、そのチャネルを使用しないでください。

  1. You can deliver code interpreted by the embedded web layer (HTML/CSS/JS) without resubmitting.
  2. Appleの公式ガイドラインはWebKit/JavaScriptの更新に関するものであり、このモデルの中核です。Googleは通常、Webベースの更新に対してより制限が少ないですが、同じ原則が適用されます:ネイティブの変更はネイティブのリリースに含める必要があります。
  3. Googleは通常、Webベースの更新に対してより制限が少ないですが、同じ原則が適用されます:ネイティブの変更はネイティブのリリースに含める必要があります。

このモデルは、AppleのWebKit/JavaScriptの更新に関する公式ガイドラインの核心です。Googleは通常、Webベースの更新に対してより制限が少ないですが、同じ原則が適用されます:ネイティブの変更はネイティブのリリースに含める必要があります。

何が Capgo には適しているか

Capgo は次の用途に適しています:

  • ウェブのバグの修正
  • 安全なUIのコピー/スタイル/フローの修正
  • 既存のページの論理的な修正
  • 内部のQAのための高速な実験

Capgo は次の用途に適していません:

  • 新しいネイティブ機能の追加
  • レビューを通過する必要がある新しいコア機能の配信
  • 署名、暗号化、パッケージのアイデンティティの動作の変更

2つのトラックで考える

Track 1: 本来のトラック (ストアレビュー)

通常の Capacitor リリースプロセスを使用してください:

  • 新しいプラグインの更新
  • アプリシェルまたはマニフェストの変更
  • パーミッションの更新
  • プラットフォーム固有の機能の変更

これらは必要です:

bun run build
bunx cap sync
# then App Store / Google Play submission flow

Track 2: JS トラック (Capgo)

安全で小さなランタイムの変更のために:

bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production

これにより、バイナリ自体を安定させながら、迅速な反復を実現することができます。

「oops、ネイティブのリリースが必要だった」 を避ける方法

毎回の Capgo ロールアウト前に、この簡単なゲートを実行してください:

  1. 変更は新しいネイティブ依存関係または許可が必要ですか?
  2. アプリの宣伝される機能が変更されますか?
  3. 認証/セキュリティの境界が変わりますか?
  4. それを非破壊のJavaScript修正として説明できますか?

1)~3)の質問に「はい」と答えた場合、ネイティブリリースを提出してください。 4)に「はい」と答えた場合、Capgoを送信してください。

これは規制チームにとっての意味

  • アプリレビューの帯域幅を意味のある変更に保持します。
  • ロールバックの制御と高速パッチングを維持します。
  • アップデートをチャンネルでテストすることで、実稼動中のリスクを減らします。

これは、実稼動中の大規模なCapacitorプログラムで使用されているアプローチと同じです: JSのみの修正用の高速アップデート、実稼動中のバイナリ用のネイティブレビューのみ。

詳しく知りたい場合は、チャンネルに基づいて厳格な環境戦略を組み合わせてください。そうすると、QAは実稼動ミスを受け取ることがなくなります。そのはCapgo-ネイティブの方法で、ステージング、ベータ、実稼動をクリーンに保ちます。

Live updates for Capacitor apps

ウェブ層のバグが実行中の場合、Capgoを使用して修正を配信するのではなく、アプリストアの承認待ちの日数を待つ必要がなくなる。

スタートする

最新のブログ記事

Capgoは、プロフェッショナルなモバイルアプリを作成するために必要な最良の洞察を提供します。