あなたが尋ねた通りです。
私は法律のアドバイスを与えていません。私は、Capacitor アプリを安全に配信するチームで広く使用されている実践的な方法を共有しています。
重要な区別は、このことです。
- ネイティブの提出 __CAPGO_KEEP_0__は新しいネイティブの動作と主要な機能が必要です。
- リアルタイム更新 はJavaScript/Webの修正とアプリの既存範囲内での調整用です。
このモデルは両方のiOSとAndroidが使用できますが、ポリシー安全のワークフローとして扱う必要があります。 簡単に言うと、AppleとGoogleは同じ境界を共有しています。__CAPGO_KEEP_0__は埋め込まれたWeb層（HTML/CSS/JS）で解釈されることができますが、再提出する必要はありません。
アプリの目的を変更する主要な機能追加はこのチャネルで使用しないでください。
セキュリティや配布制御を単独でJSで変更しないでください。
- You can deliver code interpreted by the embedded web layer (HTML/CSS/JS) without resubmitting.
- iOSとAndroidの両方が使用できますが、ポリシー安全のワークフローとして扱う必要があります。
- AppleとGoogleは同じ境界を共有しています。
__CAPGO_KEEP_0__は埋め込まれたWeb層（HTML/CSS/JS）で解釈されることができますが、再提出する必要はありません。
何がCapgoでできるか
Capgoは次の用途で使用します:
- ウェブのバグの修正
- UIの安全なコピー/スタイル/フローの修正
- 既存のページの論理的な小さな修正
- 内部のQAのための高速な実験
Capgoは次の用途で使用しないでください:
- 新しいネイティブ機能の追加
- レビューを通過する必要がある新しいコア機能の配信
- 署名、暗号化、パッケージのIDの動作の変更
推奨されるリリース戦略
2つのトラックで考えてください:
Track 1: 本機トラック (ストアレビュー)
通常の Capacitor リリースプロセスを使用してください:
- 新しいプラグインの更新
- アプリシェルまたはマニフェストの変更
- パーミッションの更新
- プラットフォーム固有の機能の変更
これらは必要です:
bun run build
bunx cap sync
# then App Store / Google Play submission flowTrack 2: JS トラック (Capgo)
安全で小さな実行環境の変更の場合:
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel productionこれにより、バイナリ自体を安定させながら、迅速な反復を実現することができます。
「本番で「native リリースが必要だった」」の回避方法
各 Capgo ロールアウト前に、この簡単なゲートを実行してください:
- 変更は新しいネイティブ依存関係または許可が必要ですか?
- アプリの宣伝される機能は変更されますか?
- 認証/セキュリティの境界は変更されますか?
- それを非破壊のJavaScript修正として説明できますか?
(1)～(3)の質問に「はい」と答えた場合、ネイティブリリースを提出してください。 (4)に「はい」と答えた場合のみ、Capgoを送信してください。
これはコンプライアンスチームにとっての意味
- アプリレビューの帯域幅を保管して、意味のある変更に使用します。
- ロールバックの制御と高速パッチングを維持します。
- アップデートをチャンネルでテストすることで、生産リスクを削減します。
これは、生産環境で大規模なCapacitorプログラムで使用されている同じアプローチです: JavaScriptのみの修正用の高速アップデート、実際のバイナリ用のネイティブレビューのみ。
詳しく知りたい場合は、チャンネルに基づいて厳格な環境戦略を組み合わせて、QAが生産ミスを受け取るのを防ぎましょう。そうすることで、ステージング、ベータ、生産をクリーンに保つことができます。そのはCapgo-ネイティブの方法です。
