最も優れたライブ更新は、ユーザーがほとんど気づかないものです。
通常、3 つのことが必要です:
- ダウンロードサイズが小さい
- ロールアウトが制御されている
- 何かが不正に動作した場合に、リカバリが即時である
The same “keep OTA lean” advice that works in React Native land also applies to Capgo. The difference is that Capgo gives Capacitor teams a few extra levers: Capacitor, Capacitor, Capacitor, CapacitorCapacitor Capacitor.
Capacitor
Capacitor
One useful Capgo-specific detail: Capgo MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days.
Capacitor
- Capacitor teams have a few extra levers: Delta updates, channels, automatic rollbacks, version targeting, and optional end-to-end encryption. If you use those together, you get smaller payloads, faster installs, and much less operational mess. Lean matters even when MAU stays the same. One useful __CAPGO_KEEP_0__-specific detail: __CAPGO_KEEP_1__ MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days. So slimming a bundle is not mainly a trick to reduce MAU counting. It matters because it improves the parts users and teams actually feel: Faster downloads on cellular or weak Wi-Fi.
- より良いエクスペリエンス 直接の更新
- 失敗したまたはロールバックされたリリースで浪費された帯域幅が少なくなる
- テストまたはステージングのリリースの場合の影響範囲が小さくなる
Leanの更新は、速さ、安全性、運用の規律についてのことです。
1. デルタ更新をデフォルトとして設定する
あなたが一つだけのことを行うなら、これを行う
Capgoの デルタ更新 バージョン間で変更されたファイルのみを送信するので、フルウェブパッケージを再ダウンロードする必要がなくなる。 それは、定期的なOTAパフォーマンスのための最大の単一の勝ちです。
bun run build
bunx @capgo/cli@latest bundle upload --channel staging --deltaQAパスが完了したとき:
bunx @capgo/cli@latest bundle upload --channel production --deltaCIが厳密に残すことを望む場合は、使用する --delta-only 全てのアップロードがバンドルアップロードに戻るのを避けるために:
bunx @capgo/cli@latest bundle upload --channel production --delta-onlyOnly use --delta-only プロダクション環境のクラスタがDeltaアップデートをサポートしている場合にのみ使用してください。プラグインバージョンが混在している場合、manifestベースのDelta配信をサポートしていない古いデバイスではアップデートをダウンロードできません。
このことは、 directUpdateを使用する場合にさらに重要です。
アップデートが見つかったときからアプリが再読み込みされるまでの時間がユーザーに視覚化されるようになります。
2. アセットをアセットとして扱う
OTA バンドルが静かに膨張するのは、大きなアセットからです。
- いくつかの実用的なルールがあります。
- Keep frequently changing content on your own CDN or API if it does not need to live inside the shipped app bundle.
- 頻繁に変更されるコンテンツは、__CAPGO_KEEP_0__ またはCDNに保管してください。アプリ内に含まれる必要がない場合は、変更されないファイルを含める必要があります。
- マーケティング画像、オンボーディングビデオ、1回限りのキャンペーンアセットは、毎回リリースごとに置き換えられます。安定したアセットは安定させてください。Deltaアップデートでは、変更されていないファイルは再ダウンロードされるのではなく、再利用されます。
この方法は、Capgoをアプリが成長するにつれて最速に保つ最も簡単な方法の1つです。
最悪のパターンは、ユーザーに大量の無関係なメディアをダウンロードさせるために、UIの小さな修正です。
Capgo updates the web layer: HTML, CSS, JavaScript, and assets loaded at runtime.
__CAPGO_KEEP_0__は、HTML、CSS、JavaScript、実行時ロードされたアセットを更新します。
- これは適切なチャネルではありません。
- 新しいネイティブプラグイン
capacitor.config.ts許可の変更- プロジェクトのネイティブ状態を変更する
iOSまたはAndroidのネイティブプロジェクトの状態を変更する
この行はパフォーマンスにも関係しています。OTAのレーンに大きな構造的変更を続けると、更新戦略が重くなりリスクが高くなります。
2つのリリースレーンを意図的に使用する
ネイティブレーン
bun run build
bunx cap sync通常のストアリリースを出荷します。
Capgo レーン
安全なウェブ層の反復については次のとおりです:
bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta最近、長期間の資産を多く追加した場合は、常にネイティブの基準を定期的に更新してください。新しいストアのビルドでは、その新しい基準を埋め込みます。これにより、将来のCapgoの差分が小さくなります。
4. チャンネルを使用してロールアウトのサイズを小さくします。
「軽量」な更新は、単にメガバイトだけではありません。更新が良好であることを知る前に、多くのデバイスが更新を受け取ることにも関係します。
Capgoの チャンネルシステム は、更新を受け取るデバイスの数を制御する最も綺麗な方法です:
stagingQA用beta招待されたテスター用production全員用hotfix緊急復元用
シンプルなフローは次のようになります:
- アップロード
staging. - 実機で検証
- 段階的に展開する。制御チャネルやパーセンテージベースの展開を通じて。
- 健康率が低下した場合、すぐにロールバックする。
あなたのアプリが複数のネイティブ基準を持っている場合、 バージョン対象古いバイナリから不必要な重いパッケージを排除するため、互換性のないパッケージを排除します。
レビューループをさらに絞りたいチームにとって、Capgoもよく機能します。 PRプレビューJSのみの変更をテストするために、製品、QA、ステークホルダーが新しいテストフライトまたはPlayの内部ビルドを待つ必要がなくなるため。
5. 直接更新を有効にすると、起動が速くなります。
更新を適用したい速度が高いほど、起動パスが厳格でなければなりません。
Capgo’s 更新の動作 ドキュメントでは、明示的に推奨されています。 directUpdate Delta更新と組み合わせることが推奨されています。
そののは、正しいデフォルトです。 notifyAppReady().
import { CapacitorUpdater } from '@capgo/capacitor-updater'
CapacitorUpdater.notifyAppReady()2番目のガイドラインは notifyAppReady() アプリが10秒以内に、またはあなたが設定した__CAPGO_KEEP_0__の設定内で、readyを報告しなかった場合、または__CAPGO_KEEP_1__がバンドルを無効にし、前のバージョンに戻すことができます。 appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:
- 起動が汚れていないことを保証するために、起動をきれいに保つことが必要です。
notifyAppReady()Call - 避難路のパス内で遅い起動時間の作業を避ける
- アプリを即座に再読み込みすると、アプリの状態を慎重に保存して復元する
- 広範なロールアウト前に、悪いネットワークと低エンドデバイスのシナリオをテストする
あなたが最近レビューしていない場合、 notifyAppReadyのガイド 再度読む価値がある。
6. 内部のアップデートチャネルを使用する代わりに、不要なネイティブのビルドを避ける
多くのモバイルチームは、明らかにWebのみの変更に対して、明らかにビンナリを構築するのに時間を浪費しています。
変更が:
- コピー
- UIのポリッシュ
- onboardingフロー
- 価格表示画面ロジック
- 分析ツールの設定
- 機能フラグ
- API の回答表示
Capgo のアップデートは、レビューのアーティファクトとしては速いことが多い。
That means fewer native rebuilds, less TestFlight churn, and a tighter feedback loop for the team. It is one of the most underused benefits of Capgo: you can move more review and QA work into the OTA lane without breaking the native/web boundary.
Capacitor の利点の 1 つは、ネイティブ/ウェブの境界を破ることなく、OTA のレーンにレビューと QA の作業を移すことができます。 Capacitor のガイド 1 つのモバイル アプリ ID でステージング
この方法を長期にわたって維持するための実践的な方法について説明しています。
7. リーンなものとシークレットを分ける
小さなパッケージと安全なパッケージは、異なる問題を解決します。
必要な強い配信保証が必要な場合:
- 有効 ライブアップデートの暗号化を有効,
- 使用 カスタムストレージまたはセルフホストされた配信を使用,
- __CAPGO_KEEP_0__
CIまたはセキュアなオペレーターフローのみにプライベートキーを保持する必要があります。
- アップデートサイズは無視できないわけではありません。ただし、両方の次元を最適化する必要があります:
- 速さのために
- 配信制御のために暗号化
- ロールアウト制御のためにチャンネル
A practical “lean Capgo” workflow
簡単なデフォルトの運用モデルが必要な場合は、こちらを使用してください。
- ネイティブとOTAリリースの分離を維持してください。
- JSの変更を
--deltaデフォルトでアップロードしてください。 - を使用して
stagingとチャンネルを使用する前にbetaロールアウト後ではなく、ロールアウト前にのみproduction. - ネイティブビルドが不要な場合、PRをインストール可能なプレビューに変換してください。 可能な限り、大量の頻繁に変更されるメディアをバンドルから除外してください。 ロールアウト後、ロールアウト前にのみ
- ロールアウト後、ロールアウト前にのみ
- ロールアウト後、ロールアウト前にのみ
- 主なアセットの増加やネイティブの変更後、ネイティブの基準を更新してください。
- 「Treat」とは、
notifyAppReady()「and rollback behavior」とは、リリースエンジニアリングの問題であり、セットアップのトリビアではありません。
その組み合わせは、一般的な「変更したものだけをアップロードする」アプローチよりも長く速いままになります。
閉じた考察
Capgo チームにとって、「軽量で速い」は、バンドルサイズの問題だけではありません。
それはリリース設計の問題です。
Delta更新を使用してペイロードサイズ、チャンネルを使用してロールアウトサイズ、ロールバックを使用して失敗サイズを管理します。OTAについて考えるときにそう考えると、更新はアプリ、チーム、ユーザー ベースが大きくなるにつれても速くなります。
