チャネル

Live Update チャンネルは、デバイスがそのチャンネルに接続されている場合に、共有されるアプリの特定のJSバンドルビルドを指します。Live Updatesを__CAPGO_KEEP_0__に__CAPGO_KEEP_1__をインストールすると、起動時にアプリがチェックする更新が存在するかどうかを確認するために、チャンネルに接続されているネイティブバイナリが常に更新をチェックします。チャンネルが指すビルドをいつでも変更でき、必要に応じて前のビルドに戻すこともできます。 install the Capgo Live Updates SDK チャンネルは更新の有効性を制御するが、バンドルの秘密性を制御するものではない。チャンネルがプライベートである場合や、自身への割り当てが無効になっている場合でも、__CAPGO_KEEP_0__にアップロードされた未暗号化のバンドルは依然として、クライアントに配信されるパブリックアセットとして扱う必要があります。エンコードは配信パスの保護と更新の有効性の保護を提供しますが、配布されたアプリから十分な努力が払われた場合、パブリックキーがクライアントに含まれているため、配布されたバンドルは逆エンジニアリングされます。詳細は「Live Update encryption」を参照してください。

デバイスがチャンネルを選択する方法 (優先順位)

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 チャンネルは、デバイスがそのチャンネルに接続されている場合に、共有されるアプリの特定のJSバンドルビルドを指します。Live Updatesを__CAPGO_KEEP_0__に__CAPGO_KEEP_1__をインストールすると、起動時にアプリがチェックする更新が存在するかどうかを確認するために、チャンネルに接続されているネイティブバイナリが常に更新をチェックします。チャンネルが指すビルドをいつでも変更でき、必要に応じて前のビルドに戻すこともできます。 チャンネルは機密性を提供しない

チャンネルは更新の有効性を制御するが、バンドルの秘密性を制御するものではない。チャンネルがプライベートである場合や、自身への割り当てが無効になっている場合でも、__CAPGO_KEEP_0__にアップロードされた未暗号化のバンドルは依然として、クライアントに配信されるパブリックアセットとして扱う必要があります。エンコードは配信パスの保護と更新の有効性の保護を提供しますが、配布されたアプリから十分な努力が払われた場合、パブリックキーがクライアントに含まれているため、配布されたバンドルは逆エンジニアリングされます。詳細は「Live Update encryption」を参照してください。

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

1. Forced device mapping (Dashboard) – 1つの実際のユーザーと単一のデバイス IDを特定のチャネルに固定するために使用します。緊急のデバッグまたは制御されたテストのために。
2. Cloud override (per‑device) via Dashboard or API Cloud override (per‑device) via Dashboard or API

Instant Channel Switching with setChannel()

Instant Channel Switching with setChannel() プラグインバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 から始めています ( setChannel() 依存するメジャーバージョンに応じて) 、 バックエンドに連絡して、チャネルが許可されているかどうかを検証し (チャネルが自分自身の割り当てを許可しているかどうかを確認)、チャネルを保存します __CAPGO_KEEP_0__ as defaultChannel. この新しいチャネルが有効になることは 即時 次の更新チェック以降は、リプリカの待ち時間なしです。

これまで setChannel() APIにチャネルオーバーライドを保存し、バックエンドデータベース (ダッシュボードやAPIの変更など) に保存し、デバイスは最大 2 分間リプリカの待ち時間を経て新しいチャネルが認識されるまで待ちました。新しい動作は、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャネル切り替えは即時です。

注意: ローカルに設定されたチャネルが許可されなくなっても、バックエンドは更新チェック中にチャネルを検証するため、セキュリティは維持されます。

重要: ダッシュボードまたはAPIからチャネル変更が行われた場合でも、エッジサーバー全体が変更を反映するまでの最大 2 分間のリプリカの待ち時間が残ります。即時チャネル切り替えには setChannel() アプリ内からcodeを使用してください。バックエンドと検証し、ローカルにチャネルを設定して即時効果を得ます。

3. Capacitor 設定 defaultChannel (テストビルドのデフォルト) – 以下の条件が満たされ、強制/オーバーライドが存在しない場合、このチャネルでアプリが起動します (例: ). capacitor.config.* テストフライト / 内部ビルド用に設計されています。生産ビルドでは、この値を未設定にします。 beta, qa, pr-123Cloud Default チャネル (主なパス ~99% のユーザー)
4. – ダッシュボードでデフォルトチャネルをマークすると、通常のエンドユーザー (強制、オーバーライド、設定のデフォルトチャネルなし) すべてに接続されます。変更すると、即座にロールアウトまたはロールバックできます。新しいバイナリなし。プラットフォーム固有のデフォルト (例、iOSのみ、Androidのみ、Electronのみ) が存在する場合、各デバイスは対応するプラットフォームのデフォルトに接続されます。Cloud Default を未設定にすると、デバイスはステップ 1–3 に一致する場合にのみ更新を受け取ります。 ベストプラクティス:

ステップ 1–3 を例外 / テストレイヤーとして扱い、Cloud Default を設定すると、実ユーザーはそれに流れ込むようにします。Cloud Default を設定しない場合は、ユーザーがどのように接続するか (通常は設定またはデバイスごとのオーバーライドを介して) に意識してください。

• この設定は defaultChannel テスターに明示的に配布するバイナリのみで構成します。Cloud Default を未設定にすると、生産ロジックはダッシュボードに集中します。
• – If present in defaultChannel and no force/override exists, the app starts on this channel (e.g. ). Intended for TestFlight / internal builds so testers land on a pre-release channel automatically. Production builds typically leave this unset.
• sparingly in production—mainly for QA or targeted diagnostics. setChannel() プラットフォーム (iOS/Android/Electron) の設定が有効になっていない場合、選択プロセスはそのチャンネルをスキップし、リストの次のチャンネルに進みます。

Summary: Force > Override > Config

> Cloud Default. defaultChannel デフォルトチャンネル動作

「デフォルトチャンネル動作」セクション

単一のデフォルト (最も一般的な) defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• プラットフォーム固有のデフォルト デフォルトをマークする場合、次のパターンを考慮してください:
• デフォルトをマークする場合、次のパターンを考慮してください: – プラットフォームごとにチャンネルを分割する場合 (例えば、 ios-production iOS のみ有効にしている場合、 android-production Android のみ有効にしている場合、 electron-production Electron のみ有効にしている場合、

それぞれのプラットフォームのデフォルトとしてそれぞれをマークします。 iOS デバイスは iOS のデフォルトに、 Android デバイスは Android のデフォルトに、 Electron アプリは Electron のデフォルトに移動します。 defaultChannel クラウドのデフォルトと「両方」は同じ決定レイヤーを占めます。クラウドのデフォルトを設定すると、__CAPGO_KEEP_0__ の構成に値を複製する必要がなくなります—生産用ビルドの場合、空白にします。テスターまたは QA に意図的にビンナリを配布する場合に、クラウドのデフォルトが異なる場合でも、非生産用チャンネルで始まるようにします。 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__

オンボード中に最初のチャネルを作成します（多くのチームはそれを「Production」と呼びますが）、しかし、ロックはありません—あなたはチャネルをいつでも名前を変更したり削除したりできます。追加のチャネルを追加するには：

1. Capgo ダッシュボードの「チャネル」セクションに移動
2. 「新しいチャネル」ボタンをクリック
3. チャネル名を入力し、「作成」をクリック

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

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

チャネルをアプリに設定する

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

Open your capacitor.config.ts (または capacitor.config.json)ファイル。 "Cloudflare" の設定セクションの下で、オプションで "test builds" (内部 / QA) を設定します。生産用のビルドの場合、デフォルトの "Cloudflare" を使用するようにデバイスに指示するには、明示的にオーバーライドする必要があります。 plugins クリップボードにコピー defaultChannel 次に、Web アプリをビルドし、 更新された設定ファイルを iOS、Android、Electron プロジェクトにコピーするには、 この同期ステップをスキップすると、以前の設定されたチャンネルを引き続き使用することになります。

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.
    },
  },
};

__CAPGO_KEEP_0__ npx cap sync __CAPGO_KEEP_0__

注意

チャネル選択順序：Force > Override (setChannel / ダッシュボード) > Config defaultChannel > Cloud Default.

使用 defaultChannel テスト/内部ビルドでのみ使用してください。生産用には削除してください。ユーザーはCloud Default（設定済みの場合）に従うのではなく、ネイティブの構成でルーティングを複製するのを避けるようにします。

デバイスを強制（固定）するか、Overrideを適用することができます。 これらは、構成値を即座に上書きします。

チャネル名は大文字小文字区別です。

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

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

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

自動アップデート戦略の無効化

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

• major: メジャーバージョン間のアップデートをブロック (0.0.0 → 1.0.0). マイナーバージョンとパッチアップデートは許可。
• minor: メジャーバージョンとマイナーバージョン間のアップデートをブロック (例: 1.1.0 → 1.2.0)。パッチアップデートは許可。注: 0.1.0 → 1.1.0 はブロックされない。
• patch: 非常に厳格。同じメジャーとマイナーバージョン内でパッチバージョンを増やすのみ許可。例: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌。
• metadata: 各パッケージに最低限のアップデートバージョンメタデータを要求する。CLI を使用して設定します。 --min-update-version none: Semver互換性に従ってすべてのアップデートを許可。 --auto-min-update-versionLearn more details and examples in Disable updates strategy at /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy。
• Example (__CAPGO_KEEP_0__):

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

Example (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()の動作 (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

このメソッドが呼び出されるのはいつですか? setChannel() __CAPGO_KEEP_0__

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

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

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

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

__CAPGO_KEEP_1__	__CAPGO_KEEP_2__	__CAPGO_KEEP_3__	__CAPGO_KEEP_4__
setChannel() __CAPGO_KEEP_5__	プラグインから	即時	デバイスのみ (ローカル)
アプリ内でユーザーがトリガーしたチャネル切り替え	デバイスのオーバーライド	最大 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 の場合でも同じ機能を含みます)。 プラグインのインストール

チャンネルにバンドルを割り当てる

ライブアップデートを展開するには、JS バンドルビルドをアップロードし、チャンネルに割り当てる必要があります。CapgoとCLIを使用して、1 つのステップで実行できます。

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

アップロードされたウェブアセットと、チャンネルで有効なビルドとしての新しいバンドルを設定します。このチャンネルに設定されているアプリは、更新を検索するたびに更新を受け取ることになります。 Development チャンネルにビルドを割り当てることもできます。__CAPGO_KEEP_0__の「バンドル」セクションに移動し、メニューのアイコンをクリックし、「チャンネルに割り当てる」を選択して、ビルドに割り当てるチャンネルを選択してください。

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

「バンドルバージョニングとチャンネル」のセクション

It’s important to note that bundles in Capgo are global to your app, not specific to individual channels. The same bundle can be assigned to multiple channels.

ライブアップデートを展開するには、JS バンドルビルドをアップロードし、チャンネルに割り当てる必要があります。__CAPGO_KEEP_0__と__CAPGO_KEEP_1__を使用して、1 つのステップで実行できます。 semver __CAPGO_KEEP_0__ 1.2.3-beta.1.

このアプローチにはいくつかのメリットがあります:

• ビルド間の関係を明確に伝えることができます。 1.2.3-beta.1 __CAPGO_KEEP_0__は明らかに 1.2.3.
• チャンネル間でバージョン番号を再利用することができ、混乱を減らすことができます。
• 明確なロールバックパスを提供します。ロールバックが必要な場合、 1.2.3は前の安定版です。 1.2.2 チャンネル:

など

• Development __CAPGO_KEEP_0__ 1.2.3-dev.1, 1.2.3-dev.2__CAPGO_KEEP_0__
• 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など

pre-release識別子を使用したsemverは推奨アプローチですが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを見つけることです。

ライブアップデートのロールバック

バグや修正が必要なライブアップデートをデプロイした場合、簡単に前のビルドにロールバックできます。ダッシュボードの「チャンネル」セクションから:

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

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

自動デプロイ

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

自動化の詳細については、 CI/CD統合 docs to learn more about automating Capgo live updates.

デバイスへのデプロイ

チャンネルの理解ができたので、実際のデバイスにライブアップデートをデプロイする準備ができました。基本的なプロセスは:

1. アプリにCapgo SDKをインストールする
2. アプリを使用するチャンネルに設定する
3. ビルドをアップロードし、そのチャンネルに割り当てる
4. アプリを起動し、更新を待つ!

詳細なガイドについては、 ライブ更新のデプロイ を参照してください。更新を楽しみにしてください。

高度なチャンネル使用方法：ユーザー分割

チャンネルは開発段階のみに使用するのではなく、ユーザー分割の強力なツールとして使用できます。

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

これらの高度な用途を実装する方法を学ぶには、以下のガイドを参照してください: 機能フラグとA/Bテストのためのプランとチャンネルに基づいてユーザーを分割する方法.