__CAPGO_KEEP_3__

A Live Update channel points to a specific JS bundle build of your app that will be shared with any devices configured to listen to that channel for updates. When you install the Capgo Live Updates SDK in your app, any native binary configured to that channel will check for available updates whenever the app is launched. You can change the build a channel points to at any time and can also roll back to previous builds if needed.

Channels Do Not Provide Confidentiality

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See Live Update encryption for details.

How a device picks a channel (precedence)

デバイスがアップデートを確認するとき、Capgoはこの順序で (優先順位が高い順) 次のチャンネルを選択します:

1. 強制デバイスマッピング (ダッシュボード) – 急いでデバッグする場合や、1人の実ユーザーと制御されたテストを行う場合に、特定のデバイスIDをチャンネルに固定します。
2. クラウドオーバーライド (デバイスごと) via ダッシュボードまたはAPI – ダッシュボードまたはAPIでデバイスのチャンネルを変更したときに作成されます。QAユーザーが機能/PRチャンネル間で切り替える場合や、ユーザーが発生させた問題を再現する場合に使用します。バイナリを再インストールしてもクリアされませんが、デバイスエントリを削除するとクリアされます。
3. プラグイン setChannel() ローカルチャンネル – アプリが呼び出し、バックエンドがターゲットチャンネルが自己割り当てを許可していることを検証したときに作成されます。選択されたチャンネルは、デバイス上でローカルに保存され、即座に効果を発揮し、デバイスオーバーライドUIに表示されません。 setChannel() setChannel()を使用した即時チャンネル切り替え

setChannel()を使用した即時チャンネル切り替え

バージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 からプラグインを開始すると、 (あなたのメジャーバージョンに応じて)、 setChannel() 異なる動作になります: バックエンドに接続して、 チャンネルの許可を検証し (チャンネルへの自己割り当てが有効かどうかを確認)、 チャンネルを デバイス上でローカルに保存します。 これは、次の更新チェックで新しいチャンネルが即座に有効になることを意味します—待つ必要はありません。 defaultChannel以前は、 バックエンドのデータベース (ダッシュボードや__CAPGO_KEEP_0__ の変更など) にチャンネルオーバーライドを保存し、 デバイスは 2 分間待ってから新しいチャンネルが認識されるまで待ちました。

新しい動作は、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えが即座になります。 setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

なぜなら、ローカル専用なので、__CAPGO_KEEP_0__ ダッシュボードにデバイスオーバーライドエントリを作成しないためです。デバイスオーバーライドUIは、ダッシュボードまたはパブリック__CAPGO_KEEP_1__から作成されたオーバーライドのみを表示します。 setChannel() 注意: チャンネルがローカルに設定された後でも、バックエンドはアップデートチェック中にチャンネルを検証するため、セキュリティは維持されます。 create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

チャンネル変更がダッシュボードまたは__CAPGO_KEEP_0__から行われた場合でも、エッジサーバー全体が変更を反映するまでの最大2分のリプリカシールがあることに注意してください。即時チャンネル切り替えには アプリから__CAPGO_KEEP_0__を使用してください—itはバックエンドと検証し、ローカルにチャンネルを設定して即効性を得ます。

__CAPGO_KEEP_0__設定 When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() from your app code—it validates with the backend, then sets the channel locally for immediate effect.

4. Capacitor defaultChannel __CAPGO_KEEP_1__ __CAPGO_KEEP_0__ capacitor.config.* と強制/オーバーライド/ローカルチャネルが存在しない場合、このチャネルでアプリが起動します (例えば、 beta, qa, pr-123). テストフライト / 内部ビルド用に設計されています。テスターは自動的にプレリリースチャネルにアクセスします。生産ビルドは通常、この値を未設定にします。
5. Cloud Default Channel (主なパス ~99% のユーザー) – ダッシュボードでデフォルトチャネルをマークすると、すべての通常のエンドユーザー (強制なし、ダッシュボード/API オーバーライドなし、プラグインローカルチャネルなし、config defaultChannel なし) にアタッチされます。変更すると即座にロールアウトまたはロールバックできます—新しいバイナリなし。プラットフォーム固有のデフォルト (例えば、iOS-のみ、Android-のみ、Electron-のみ) を持つ場合、各デバイスはそのプラットフォームに合ったデフォルトにアタッチされます。Cloud Default を未設定にすると許可されます。その場合、デバイスはステップ 1–4 にマッチすることでアップデートを受け取ります。

ベストプラクティス:

• ステップ 1–4 を例外 / テストレイヤーとして扱い、Cloud Default を設定した場合、実ユーザーはそれに流れ込むようにします。Cloud Default を設定しない場合は、ユーザーがアタッチする方法については、 defaultChannel config またはデバイスごとのオーバーライドを使用して意図的に行うこと。
• Only configure defaultChannel テスターに明示的に配布するバイナリのみで設定します。Cloud Default を未設定にすると、生産ロジックはダッシュボードに集中します。
• Use setChannel() 生産環境ではsparingly—QAまたはターゲットされた診断用に主に使用します。

チャネルがプラットフォーム (iOS/Android/Electron) で無効になっている場合 (トグル)、選択プロセスはそれをスキップし、リストの次のものに進みます。

概要: Force > Dashboard/API Override > プラグイン setChannel() ローカル チャネル > 設定 defaultChannel > Cloud Default.

デフォルト チャネル ビハビアー

クラウド デフォルトを設定することは任意ですが、通常は新しいデバイスのキャッチオール パスとして機能します。 1 つがなければ、強制マッピング、オーバーライド、または「__CAPGO_KEEP_0__」設定に一致するデバイス以外のデバイスは更新を受け取りません。 クラウド デフォルトを選択する場合、次のパターンを考慮してください: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• – iOS、Android、および Electron が有効になっているチャネルが 1 つだけの場合、デフォルトになります。 オーバーライドなしのデバイスはすべてここに接続されます。 プラットフォーム固有のデフォルト
• – プラットフォームを分割する (例えば、iOS のみが有効になっている場合、 iOS のみが有効になっている場合、 ios-production iOS のみが有効になっている場合、 android-production Androidのみ有効にし、 electron-production Electronのみ有効にした場合にそれぞれのプラットフォームのデフォルトとしてマークします。 iOSデバイスはiOSのデフォルトに、AndroidデバイスはAndroidのデフォルトに、ElectronアプリはElectronのデフォルトにアクセスします。

クラウドのデフォルトを思い出してくださいが、 defaultChannel 両方は同じ決定層を占めます。クラウドのデフォルトを設定すると、__CAPGO_KEEP_0__の設定に値を複製する必要がなくなります—生産用ビルドの場合に空白のままにします。 capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel デフォルトをいつでもダッシュボードで変更できます。デフォルトを入れ替えると、新しいデバイスはすぐに新しいルーティングに従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。 defaultChannel チャンネルの設定

チャンネルの設定

オンボーディングの際に最初のチャンネルを作成します（多くのチームは「生産」に名前付けますが）、何もロックされていません。チャンネルを任意の時点で変更または削除できます。追加のチャンネルを追加するには:

__CAPGO_KEEP_0__

1. Capgo
2. 「新チャネル」ボタンをクリックしてください
3. __CAPGO_KEEP_0__を入力し、「作成」ボタンをクリックしてください

チャンネル名はあなたが好きなように自由に決められます。一般的な戦略は、チャンネルを開発段階にマッチさせることです。

• Development - ローカルデバイスまたはエミュレータでライブ更新をテストする
• QA - QA チームが広範なリリース前に更新を検証する
• Staging - プロダクション環境に似た環境で最終テスト
• Production - アプリストアからユーザーが受け取るアプリのバージョン

アプリ内でチャンネルを設定する

チャンネルが作成されたら、アプリを適切なチャンネルに反応するように設定する必要があります。この例では、チャンネル。 Development アプリを開いてください

__CAPGO_KEEP_0__ capacitor.config.ts (または capacitor.config.json)ファイル。セクションの下で、オプションで plugins 設定 defaultChannel テストビルド （内部 / QA）。生産ビルドの場合、デフォルトのCloudを使用するようにデバイスに強制するには、明示的にオーバーライドする必要があります。 クリップボードにコピー

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

更新された構成ファイルをiOS、Android、Electronプロジェクトにコピーするために npx cap sync この同期ステップをスキップすると、以前の設定されたチャンネルを引き続き使用することになります。

注意

チャンネル選択順序：Force > ダッシュボード/API デバイスオーバーライド > プラグイン setChannel() ローカルチャネル > 設定 defaultChannel > Cloud のデフォルト設定。

使用 defaultChannel テスト/内部ビルドでのみ使用してください。生産用には削除してください。ユーザーは Cloud のデフォルト設定 (設定されている場合) に従うのではなく、ネイティブの設定でルーティングを複製するのではなく。

デバイスを強制 (固定) したり、後でオーバーライドを適用したりできます。これらは、設定値を即座に上書きします。

チャネル名は大文字と小文字が区別されます。

チャネルオプションと戦略

チャネルには、更新を受け取ることができるユーザーと、更新を配信する方法を制御するオプションが複数あります。重要なものは以下のとおりです。Web アプリ、CLI、または Public API からこれらのオプションを設定できます。

• デフォルトチャネル: 新しいデバイスが接続するチャネルまたはプラットフォーム固有のチャネルをオプションで指定できます。ルーティングシナリオについては「デフォルトチャネル動作」を参照してください。
• プラットフォームフィルタ: iOS, Android、または Electron デバイスあたりチャンネルあたり。
• ネイティブ: 自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルバージョンよりも新しい場合にアップデートを送信しないようにします (例: デバイスが 1.2.3 である場合、チャンネルが 1.2.2 を持っています)。
• 開発用ビルドを許可する: 開発用ビルドへのアップデートを許可します (テストに便利です)。
• エミュレータデバイスを許可する: エミュレータ/シミュレータへのアップデートを許可します (テストに便利です)。
• デバイスの自己割り当てを許可する: アプリが実行時、このチャンネルに切り替えることができます。 setChannel無効にすると、 setChannel このチャンネルでは機能しなくなります。

Auto Update ストラテジーの無効化

このオプションを使用して、チャンネルが自動で配信するアップデートの種類を制限します。オプション:

• メジャー: 目標バンドルのメジャーバージョンがデバイスのネイティブ基準よりも高くなければならない場合に、ターゲットバンドルをブロックします (version_build例: 1.2.3 -> 2.0.0 はブロックされています; 1.2.3 -> 1.9.0 は許可されています。
• バージョンが異なるターゲットパッケージをブロックします。 version_build例: 1.2.3 -> 1.3.0 はブロックされています; 1.2.3 -> 1.2.4 は許可されています。
• patch: 最も厳密なモードです。メジャー、ミニマム、またはパッチ番号の変更はすべてブロックします。 MAJOR.MINOR.PATCH は許可されます。 1.0.0-beta.1 -> 1.0.0-beta.2 は許可されます。 1.0.0+build.1 -> 1.0.0+build.2 はブロックされています。 1.0.0 -> 1.0.1 メタデータ: 各パッケージに最低限のアップデートバージョンメタデータを要求します。__CAPGO_KEEP_0__を使用して構成します。
• metadata: Require a minimum update version metadata on each bundle. Configure via CLI using --min-update-version または --auto-min-update-version. If missing, the channel is marked misconfigured and updates will be rejected until set.
• none: All updates are allowed according to semver compatibility.

These strategies compare the channel’s target bundle against the native baseline sent as version_build、ではなく、現在ダウンロードしたバンドルとして送信された version_name.

Learn more details and examples in Disable updates strategy at /docs/cli/commands/#disable-updates-strategy.

例（CLI）

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Your AppからsetChannel()を使用する

このメソッドは、実行時でプログラム的にチャンネルを切り替えることを許可します。これは、特に以下のシナリオで便利です: setChannel() QA/デバッグメニューでテスターがチャンネルを切り替える

• ベータプログラムのオプティンフロー
• 機能フラグの実装
• A/Bテストシナリオ
• コピー

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

setChannel()が呼び出される時は:

バックエンド検証 (読み取り専用) setChannel() __CAPGO_KEEP_0__

1. __CAPGO_KEEP_0__: Capgo バックエンドにリクエストが送信され、チャンネルが許可されているかどうか検証されます (自身の割り当ての権限を確認します)
2. ローカル ストレージの更新: 検証が成功した場合、チャンネルはデバイスのローカル ストレージに保存されます defaultChannel
3. 即時効果: 次のアップデート チェックでは、新しいチャンネルが即座に使用されます (リプリカシオンを待つ必要はありません)

なぜこれが重要か: 古いバージョンでは setChannel() チャンネル オーバーライドをバックエンド データベースに保存 (同様に、ダッシュボードまたは API の変更)。デバイスは、チャンネル変更が有効になるまで、最大 2 分間バックエンドのリプリカシオンを待つ必要がありました。現在は setChannel() バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル Switch が即時になりました。

ダッシュボードの可視性: プラグインで設定されたチャンネルは、Capgo UI でデバイス オーバーライドとして表示されません。ダッシュボードまたは Public API から作成されたチャンネル割り当てのみがリストされます。ダッシュボードまたは API を使用する必要がある場合は、管理者が表示できるオーバーライドを必要とします。

セキュリティに関する注意: ローカルに設定されたチャンネルの権限が変更された場合 (例: 自分自身への割り当てが無効化された場合)、バックエンドは更新チェック中にチャンネルを検証し、セキュリティの維持を保証します。

チャンネル変更方法の比較:

方法	効果時間	保存先	デバイス上でオーバーライド可能	使用ケース
setChannel() プラグインから	即時	デバイスのみ (ローカル)	なし	アプリ内でユーザーがチャンネルを切り替える場合
ダッシュボードデバイスオーバーライド	2分以内	バックエンドデータベース	はい	特定のデバイスのための管理者が行う変更
API チャンネル割り当て	2分以内	バックエンドデータベース	はい	自動化されたバックエンド統合

チャンネル切り替えUIを構築する際に最良のユーザー体験を確保するには、常にプラグインの setChannel() メソッドを使用してください。

ローカル専用チャンネル切り替えの最小バージョン: 5.34.0, 6.34.0, 7.34.0, または 8.0.0 (バージョンに応じて)。各マイナーバージョン番号は、すべてのマイナーバージョンで同じ機能セットを表します (例: X.34.0 は、X が 5、6、7、または 8 の場合でも同じ機能を含みます)。 See プラグインのインストール

バージョンタグについて

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

npx @capgo/cli@latest bundle upload --channel=Development

コピー Development これにより、ビルドされたWebアセットをアップロードし、チャンネルに新しいバンドルを設定します。チャンネルに設定されているアプリは、更新を検出するたびにアップデートを受信します。

Capgoの「バンドル」セクションから、ビルドをチャンネルに割り当てることもできます。ビルドの隣にあるメニューのアイコンをクリックし、「チャンネルに割り当てる」を選択して、そのビルドのチャンネルを選択してください。

バンドルバージョニングとチャンネル

Capgoのバンドルはアプリ全体にグローバルで、個々のチャンネルに特有のものではありません。同一のバンドルは複数のチャンネルに割り当てることができます。

__CAPGO_KEEP_0__でバンドルをバージョン化する際には、 シーケンスベージョニングとCapgoのSemver テスターを使用することをお勧めします。また、チャンネル固有のビルド用にプレリリース識別子を使用することもお勧めします。たとえば、ベータ版リリースは このアプローチにはいくつかの利点があります。 1.2.3-beta.1.

ビルド間の関係を明確に伝えることができます。

• 明らかにプレリリースです。 1.2.3-beta.1 チャンネル間でバージョン番号を再利用できるため、混乱を防ぐことができます。 1.2.3.
• 明確なロールバックパスを提供します。ロールバックが必要な場合、
• __CAPGO_KEEP_0__ 1.2.3, ご存知の通り 1.2.2 は、前の安定版リリースです。

ここでは、チャンネル設定の典型的な例として、バンドルバージョンをどのように合わせるかを示します。

• Development チャンネル: 1.2.3-dev.1, 1.2.3-dev.2など
• QA チャンネル: 1.2.3-qa.1, 1.2.3-qa.2など
• Staging チャンネル: 1.2.3-rc.1, 1.2.3-rc.2など
• Production チャンネル: 1.2.3, 1.2.4など

使用 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__

ライブアップデートをロールバックする

ライブアップデートを展開した場合、バグが含まれている場合や元に戻す必要がある場合、簡単に前のビルドに戻ることができます。ダッシュボードの「チャンネル」セクションから:

1. ロールバックしたいチャンネルの名前をクリック
2. ロールバックしたいビルドを探し、王冠アイコンをクリック
3. 確認

選択したビルドはすぐにそのチャンネルで有効なビルドになります。アプリは、更新をチェックするときにロールバックしたバージョンを受け取ります。

自動デプロイ

CI/CDパイプラインで自動化されたライブアップデートのデプロイを実行するには、より高度なワークフローを使用できます。Capgoをビルドプロセスに統合することで、特定のブランチにプッシュしたり、新しいリリースを作成したりするたびに、新しいバンドルを自動的にアップロードし、チャンネルに割り当てることができます。

CI/CD統合 CI/CD統合のドキュメントを参照してください。__CAPGO_KEEP_0__のライブアップデートを自動化する方法について詳しく学びましょう。 docs to learn more about automating Capgo live updates.

デバイスへのデプロイ

アプリを__CAPGO_KEEP_0__で構成し、望ましいチャンネルにリスニングするようにします。

1. Install the Capgo SDK in your app
2. アプリを起動し、更新を待ちます。
3. より詳細なウォークスルーについては、ドキュメントを参照してください。
4. __CAPGO_KEEP_1__は__CAPGO_KEEP_0__の__CAPGO_KEEP_1__です。

__CAPGO_KEEP_0__は__CAPGO_KEEP_1__です。 ライブ更新の展開 ガイド。更新してください！

高度なチャネル使用: ユーザー セグメンテーション

チャネルは開発段階のみに使用されるのではなく、より多くの用途に使用できます。ユーザー セグメンテーションを実現する強力なツールであり、以下のような機能を提供します。

• ユーザー層ごとの機能フラグ
• A/B テスト
• 機能の段階的ロールアウト
• ベータ版テストプログラム

上記の高度な使用例を実装する方法については、ガイドを参照してください。 プランとチャネルを使用して機能フラグとA/B テストのためのユーザーをセグメント化する方法.

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__が使用されている場合 チャンネル チャンネルルーティングとステージドロールアウトの計画に使用する場合、チャンネルと接続する チャンネル チャンネル チャンネル ベータテストソリューション ベータテストソリューションにおける製品ワークフロー バージョン目標ソリューション バージョン目標ソリューションにおける製品ワークフロー Cloudflare Capgo 環境ベストプラクティス: ステージングに 1 つのモバイル アプリ ID Capgo 環境ベストプラクティス: ステージングに 1 つのモバイル アプリ ID のための実用的な文脈