効果的なアプリ更新通知の戦略

金曜日にホットフィックスをリリースしました。しかし月曜になっても、サポートには「更新が届いていない」というユーザーの声が届き、ベータテスターは古いbundleのまま動けず、あるエンタープライズクライアントからは「現場のチームが正確にどのバージョンを使っているか教えてほしい」と問い合わせが来ます。その瞬間、次のことが明確になります。 アプリ更新通知 は、単なるモーダルではありません。リリース制御のためのオペレーティングシステムなのです。

Capacitor や Electron プロジェクトにおいて、難しいのは更新の検知ではありません。その周辺のすべてが難しいのです。誰に、いつ見せるべきか、無視された場合にどうするか、CI/CDを通じてどのように更新を流すか、そしてロールアウト後のテレメトリから何を読み取るか。更新プロンプトを単なるUIの飾りとして扱うと、ノイズの多い通知、脆弱なリリースロジック、そして混乱したユーザーを招きます。製品ライフサイクルの一部として扱うことで、より安全なロールアウトと、はるかに落ち着いたサポート対応が可能になります。

アプリ更新戦略が重要な理由
- アップデートは保守だけでなく、継続率にも影響する
- ストア更新とLive Updateは解決する課題が異なる
Capgo によるアップデート検知の実装
効果的な通知パターンの設計
アップデートフローの自動化とユーザーの選択肢
ChannelとTelemetryを活用した高度なロールアウト
通知に関するよくあるトラブルシューティング

アプリのアップデート戦略が重要な理由

アップデートは単なる保守ではなく、継続率に直結する

多くのチームは、アップデートを単なる「保守作業」と捉えがちです。バグを直し、ユーザーに促し、次へ進む。しかし、その考え方ではプロダクトへの影響を見落としてしまいます。

プッシュ通知は、インストール後にユーザーをアプリへ呼び戻すことができる数少ないライフサイクルチャネルの一つです。以下にデータをまとめました。 Invespのモバイルプッシュ通知に関する研究では、プッシュ通知によってアプリのエンゲージメントを 最大88%向上させることができ、通知を許可したユーザーの継続率は、 許可していないユーザーの 約2倍に達します。アップデート戦略においてこれが重要なのは、古いクライアントを使い続けているユーザーは、あなたがリリースした新機能や修正、コンプライアンス対応を二度と目にしない可能性があるからです。

不十分なアップデートフローは、通常、以下の3つの問題を同時に引き起こします：

プロダクトのラグ 新機能のリリースが不均一になり、PMが分析データから誤ったシグナルを受け取ることになります。
ドラッグによるサポート エージェントが問題を再現する前に、スクリーンショットやバージョン、デバイスの詳細をユーザーに依頼しなければならない場合に発生します。
セキュリティリスクの増大 古いクライアントが、すでに仕様変更されたAPIにアクセスし続けることでリスクが高まります。

実践ルール: アップデートの配信を、スプリントの最後に出す単なる通知ではなく、リリース管理の一環として捉えてください。

ストア更新とLive Updateは解決する問題が異なります

App StoreやPlay Storeのアップデートは依然として重要です。Native Buildの依存関係の変更、ポリシーに基づくリリース、権限の変更、バイナリレベルの修正などはこれに該当します。しかし、ストア経由のアップデートはシステムの一層に過ぎず、審査やユーザーの更新率が直接コントロールできないため、設計上スピードが遅くなります。

CapacitorやElectronアプリにおいて、Live Updateは異なるカテゴリの作業をカバーします。JavaScript、CSS、文言、アセット、フィーチャーフラグなど、新しいバイナリを必要としないWeb bundleの変更に適しています。実務上、これにより2つのリリース判断を切り離すことができます。

リリースの判断基準	最適
この変更には新しいネイティブバイナリが必要ですか？	ストアでのリリース
この変更は、Web bundleとして安全に配信できますか？	Live update
続行する前にユーザーに知らせる必要がありますか？	アプリ内通知の判断基準
一部のユーザーだけに今すぐ適用する必要がありますか？	チャンネルベースのロールアウト

この違いがあるからこそ、クライアントアプリを開発する制作会社は、単一の「アップデートがあります」というポップアップを前提とした設計をやめるべきです。プロフェッショナルなチームには、ソフトなプロンプト、サイレントな適用パス、ロールバックルール、チャンネル指定、そして後でサポートが調査できるログが必要です。

信頼性の観点も重要です。ユーザーはアップデートそのものよりも、予期せぬ中断を嫌います。アプリがスムーズに更新され、大きな変更を明確に説明し、重大な不具合やセキュリティリスクがある場合にのみ利用を制限するなら、ユーザーはそれを「信頼できるアプリ」だと判断します。

Capgo を使ったアップデート検知の実装

最初のステップはシンプルです。ユーザーがどのバージョンを使用しているか、どのチャンネルに属しているかを知り、取得すべきデータがあるかを判断することです。自作のアップデートシステムが複雑になりがちなのは、これらの判断を混同しているからです。これらは明確に分けて管理しましょう。

まずはバージョンの把握から

信頼できるアップデーターには、実行時に以下の3つの値が必要です：

インストール済みのアプリバージョン
割り当てられたリリースチャネル
現在のアップデート状態, 例：idle、checking、available、downloading、ready、failed

この状態モデルを省略すると、すぐに通知バグが発生します。チェックが頻繁に走りすぎたり、起動のたびに同じプロンプトが表示されたり、バックグラウンドでのダウンロードが完了しているのにUIが「checking」のままだったりといった問題です。

ここでマネージドサービスを選択すべき理由はただ一つです。運用負荷が code のスニペットで示唆されているよりもはるかに重いためです。署名済みbundle、チャネルルール、ロールバック対応、バージョン履歴、デバイスレベルのlogs、そして配信インフラが必要になります。 Capgo Capgo は、アップデータープラグインとホスト型の配信ワークフローを通じて、Capacitor および Electron アプリ向けにこれらを提供します。そのため、多くのクライアントチームにとって、スタックを自前で再構築するよりも Capgo を利用する方が賢明です。

アップデーターをアプリの起動時に組み込む

アプリの起動時、シェルが準備できた後に軽量なチェックを実行します。アップデートなしではアプリが続行できない場合を除き、ファーストペイントをブロックしないでください。

Capacitor アプリでよくあるパターンは次のとおりです：

import { App } from '@capacitor/app'
// import your updater SDK here

type UpdateDecision =
  | { kind: 'none' }
  | { kind: 'soft'; version: string }
  | { kind: 'hard'; version: string }
  | { kind: 'silent'; version: string }

async function checkForUpdate(): Promise<UpdateDecision> {
  try {
    // Replace with your updater SDK call
    const result = await updater.check()

    if (!result || !result.available) {
      return { kind: 'none' }
    }

    if (result.metadata?.mandatory === true) {
      return { kind: 'hard', version: result.version }
    }

    if (result.metadata?.silent === true) {
      return { kind: 'silent', version: result.version }
    }

    return { kind: 'soft', version: result.version }
  } catch {
    return { kind: 'none' }
  }
}

App.addListener('appStateChange', async ({ isActive }) => {
  if (!isActive) return
  const decision = await checkForUpdate()
  handleUpdateDecision(decision)
})

ポイントは、 check() 「より新しいものがあるか」ではなく、「より新しいものがあるか、それはこのユーザーがこの channel で利用できるか、そしてアプリはそれにどう反応すべきか」です。

適切な実装では、最後にチェックが成功した時刻と最後にプロンプトを出したバージョンも保存します。これでアプリのアップデート通知ロジックがしつこくならず、冪等（idempotent）になります。

結果を読み取って早めに分岐

分岐はチェック結果になるべく近い場所で行いましょう。アップデートのルールを各画面に散らさないでください。

私が実際に使っている実践的な分け方は次のとおりです：

アップデートなし 何もしないで、通常のチェック結果をログに記録します。
ソフトアップデート バナー、設定画面のバッジ、または軽量なインアプリプロンプトをキューに追加します。
サイレントアップデート バックグラウンドでダウンロードし、次回のアプリ起動時に適用します。
強制アップデート アプリを制御されたブロッキングフローに切り替えます。

実装の後半では、この決定を中央のストアに公開し、React、Vue、または Ionic UI から一貫して利用できるようにしたいと考えています。

このチュートリアルは、Capacitor アプリ全体の広範なセットアップを確認したい場合に役立ちます。

検知レイヤーはシンプルに保ちましょう。賢明さは起動時の code ではなく、ロールアウトポリシーに持たせるべきです。

効果的な通知パターンの設計

ほとんどのアップデートプロンプトが失敗するのは、チームが1つのパターンを選んで何にでも使い回してしまうからです。その結果、文言の微修正にブロッキングモーダルを表示したり、重要なマイグレーションを誰も気づかないトーストの裏に隠してしまったりすることになります。

アプリを取り巻く環境は、すでに飽和状態にあります。 Business of AppsによるAirshipのベンチマーク概要では、米国のスマートフォンユーザーの平均的な受信数は、 1日あたり46件のプッシュ通知に達しており、一方で、プッシュ通知への反応率やクリック率（CTR）は、 iOSでは3.4%、 と Androidでは4.6%と、依然として低い水準に留まっています。アプリのアップデート通知は、ユーザーを疲れさせることなく、いかに注目を集めるかが重要です。

効果的なモバイルアプリのアップデート通知パターン3選（バナー、モーダルダイアログ、インアプリメッセージ）を示すインフォグラフィック。

効果を維持しつつ、ユーザーへの妨げが最も少ないパターンを選びましょう。

優れたアップデートUIは、割り込みによるコストを考慮します。ユーザーが決済情報を入力中、患者の記録を入力中、あるいは在庫スキャン中の場合、モーダル表示は修正しようとしているバグよりも厄介な問題になり得ます。

私は普段、次のようにパターンを割り当てています：

画面上部または下部のバナー 軽微な修正、緊急度の低い改善、サイレントアップデートの確認用。
トースト通知 「次回起動時にアップデート準備完了」といったバックグラウンドの状態表示用。重要な判断には向きません。
設定やプロフィール画面への導線 自分でコントロールしたい、または変更履歴を確認したいユーザー用。
ブロッキングモーダル 旧バージョンのまま安全に続行できない場合にのみ使用します。

控えめなバナーの方が、大げさなモーダルより効果的なことが多いです。ユーザーにUIとの格闘を強いないからです。

主要なパターンの比較

パターン	メリット	主なリスク	実装のヒント
バナー	任意更新、低優先度の通知	無視されやすい	バージョンごとに非表示状態を保持
トースト通知	バックグラウンドでの状態変化	消えるのが早すぎる	設定値として永続化させる
インアプリメッセージ	コンテキストに応じた機能リリース	すぐに気づかれない可能性がある	関連する画面に紐付ける
モーダル	必須のアクション	ユーザーのフラストレーション	強制的なゲートにのみ使用する

最も重要な実装の詳細は 状態の永続化です。ユーザーが「後で」をタップした場合は、その提供バージョンに対して状態を保存してください。バナーを閉じた場合、ルートが変わるたびに再表示してはいけません。これを怠ると、アップデーターが正常に動作していても、ユーザーにはアプリが壊れているように感じられてしまいます。

ライフサイクルスタックの一部として既にプッシュ通知を利用しているチームは、アプリ更新のUXを既存のメッセージング設定と比較検討する価値があります。Capgoによる IonicとCapacitorのFirebaseを使用したプッシュ通知ガイドここで役立つのは、トランスポートの関心事と、ユーザーにアクションを促すアプリ内UIを切り離せるからです。

Push通知だけでは不十分です

よくある間違いは、OSレベルのアップデートバッジやストアの通知だけで十分だと考えてしまうことです。実際には、デバイスの設定、バッジの権限、自動更新の挙動、あるいは省電力モードなどの影響で、ユーザーはそれらの通知を見逃しがちです。だからこそ、ストアのエコシステムが正常に機能していても、アプリ内メッセージングが重要になります。

Electronの場合は、これがより顕著です。デスクトップユーザーは、モーダルによる割り込みではなく、控えめなステータス表示を求める傾向があります。ワークフローの途中でフォーカスを奪うシステムダイアログよりも、シェル内に表示される小さな「Update ready」チップの方が、プロフェッショナルな印象を与えます。

最適なパターンは、アップデートのリスクとユーザーが今取り組んでいるタスクに合うものです。それ以外は単なる見せかけです。

アップデートフローの自動化とユーザーの選択肢

検知とUXパターンが整ったら、核となるのはワークフローです。その中でチームは、自動化しすぎてコントロールを失うか、自動化が不足してサポート負債を抱えるかのどちらかに陥りがちです。

アプリの自動アップデートワークフロー3種類（サイレント、ユーザー選択、強制）を示す図。

Coderioのアプリメンテナンスガイドラインでは実用的なリリースリズムとして 2〜4週間ごとのマイナーアップデートを推奨しています。 と 3〜6ヶ月ごとのメジャーリリース、強制アップデートは次の場合に限定： 重大なセキュリティや安定性の問題。これが正しい考え方です。判断は開発者の不安ではなく、リリースの種類に基づくべきです。

低リスクな変更向けのサイレントアップデート

サイレントアップデートは、Capacitor アプリで最も活用されていない手法です。スタイリング、文言、フィーチャーフラグの設定、非破壊的なJavaScriptのバグ修正であれば、ユーザーの操作を中断させる必要は通常ありません。

フローはシンプルです：

アプリが新しいbundleを確認します。
バックグラウンド適用が安全とマークされていれば、バックグラウンドでダウンロードされます。
次回の起動時にアプリが新しいbundleを有効化します。
再起動後に「アップデートが完了しました」という短い通知が表示されることもあれば、何も表示されないこともあります。

最後の選択は変更内容次第です。アップデートでユーザーに見えるワークフローが変わる場合は、次回起動時に小さな「新機能」カードを表示すると、ユーザーが状況を把握しやすくなります。変わらない場合は、何も表示しなくて問題ありません。

シンプルな状態管理の例は以下の通りです：

async function handleUpdateDecision(decision: UpdateDecision) {
  if (decision.kind === 'silent') {
    await updater.download()
    await updater.setNextBundle()
    localStorage.setItem('pendingUpdateVersion', decision.version)
    return
  }

  if (decision.kind === 'soft') {
    showBanner(decision.version)
    return
  }

  if (decision.kind === 'hard') {
    showForcedUpdateScreen(decision.version)
  }
}

製品の変更をユーザーに選択させるフロー

アップデートによって挙動が大きく変わり、ユーザーに中断を承諾してもらう必要がある場合は、ユーザー選択フローが適しています。新しいナビゲーション、オンボーディングの刷新、承認フローの変更、あるいはダッシュボードの大幅なリデザインなどがこれに該当します。

プロンプトは簡潔に保つべきです：

何が変わったのか
なぜ重要なのか
今アップデートした場合の影響
後回しにした場合の影響

ダイアログにリリースノートのような長文を書かないでください。明確な1文と2つのボタンの方が、大量のテキストを表示するよりも効果的です。

私はこのパターンを推奨しています：

新しいバージョンが利用可能です。レポートワークフローの更新とエクスポートの修正が含まれています。今すぐアップデートするか、後でインストールするために続行します。

「後で」の扱いは慎重に行ってください。旧クライアントが引き続き有効な場合は、そのまま続行できるようにします。もし API の移行によって旧クライアントが動作しなくなる場合は、選択肢であるかのように見せないでください。

アプリの配信だけでなく、ガバナンスまで考慮するチームにとって、セキュリティ運用も同様のロジックが当てはまります。優れた自動化は、ルーチンワークとなる変更を静かに処理し、リスクが正当化される場合にのみエスカレーションを行います。そのため、以下の SOCチーム向けセキュリティ自動化の概要は非常に有用です。ここでは、イベントを分類し、安全なパスを自動化し、人間による介入を意図的なものにするという、より広範な設計原則を示しています。

また、ユーザー属性に基づいたロジックでこれを強化することも可能です。Capgoによるアプリアップデートの利用頻度セグメンテーションに関する記事は、実用的なリファレンスになります。頻繁に利用するユーザーとたまに利用するユーザーでは、アップデートのタイミングやpromptのスタイルを必ずしも同じにする必要はないからです。

限定的なクリティカルケースにおける強制アップデート

強制アップデートは正当な手段ですが、悪用されやすい側面もあります。

以下のいずれかに該当する場合は、ハードゲート（強制的な遮断）を使用してください：

条件	強制アップデート
脆弱性が判明しているセキュリティパッチ	はい
深刻な不具合を引き起こす安定性の問題	はい
バックエンドの契約違反	はい
軽微なUIの調整	いいえ
オプション機能のロールアウト	いいえ

実装は明示的に行うべきです。起動時にインストール済みのバージョンを確認し、サポート対象の最小バージョンと比較してください。その閾値を下回っている場合にのみ、ユーザーをブロック状態にします。「新しいバージョンが存在する」から「強制アップデートが必要」と推測してはいけません。

強制アップデート画面には3つのプロパティが必要です：

行き止まりを作らないこと. ユーザーに明確なリトライ手段を提供してください。
分かりやすい説明. なぜアップデートが必要なのかを伝えます。
オフライン時の対応. ネットワークが利用できない場合も、その旨を説明してください。

不安定なモバイル通信環境下で、何の表示もなく「Update」ボタン一つだけのモーダルが失敗する場合、それは最悪の体験です。アプリがブロックされた場合、そのリカバリパスは通常時よりも洗練されている必要があります。

Channelsとテレメトリによる高度なロールアウト

アップデートに関するトラブルの多くは、検知の失敗ではなく、実際の挙動を確認する前に広範囲へリリースしてしまうことが原因で起こります。

Channelsによる影響範囲（blast radius）の抑制

Channelsベースのロールアウトは、クライアントアプリでLive Updateを配信する最も安全な方法です。全員に一つのbundleを公開するのではなく、internal、QA、beta、staging、production、あるいは特定の顧客向けといったオーディエンスごとに配信します。

これにより、単なる「リリースか否か」という二択ではなく、運用コントロールに近いリリース形態が可能になります。一つのbuildを複数のオーディエンスに順次展開し、各段階で確信を得てから次のグループへ進むことができます。

アップデートのワークフローを中心としたプラン構成など、このロールアウトモデルの商用側面を示すスクリーンショットを以下に掲載します。

これは通知戦略においても重要です。 Adaptyのプッシュ通知ベストプラクティスによると、報告では、 送信時間を最適化することで反応率が40%向上し、 と 高度なターゲティングにより反応率が3倍になる可能性があります。アップデートシステムにおいては、全ユーザーへの一律なプロンプトではなく、チャンネルを意識したロールアウトやバージョンごとのメッセージングがこれに該当します。

テレメトリによって、ユーザーが実際に移行したかどうかが分かります。

プロフェッショナルなアップデートシステムは、エンジニアがアドホックなログを掘り返さなくても、以下の疑問に答えられるべきです：

各デバイスはどのbundleバージョンを使用しているか？
アップデートのダウンロードは成功したか？
次回の起動時に正常に適用されましたか？
ロールアウト後に起動失敗が増加していませんか？
どのユーザーが古いバージョンで止まっていますか？

テレメトリがあれば、アップデートは単なる「リリース作業」から「運用プロセス」へと変わります。これがないと、何を配信したかしか分かりません。これがあれば、ユーザーが実際に何を採用したかが分かります。

サポートチームがアップデートの状態を把握できなければ、本来はロールアウトの問題であるはずの事象を、製品自体の不具合としてエスカレーションしてしまいます。

私は集計データだけのダッシュボードよりも、デバイスごとのタイムラインを重視します。全体の採用曲線も有用ですが、「なぜあるエンタープライズ顧客が、1週間経っても古いbundleでアプリを開き続けているのか」という理由は説明できません。デバイスレベルのログなら、その理由が分かります。

特定のコホートを分離できるようになると、バージョン指定のパブリッシングもより実用的になります。こちらのガイドにある特定のバージョンをユーザーに配信する方法は、複数の顧客環境をサポートするエンタープライズチームが、最終的に必要とするコントロールの好例です。

CI/CDは単にbuildするだけでなく、publishしてobserveすべきである

モダンなパイプラインは「build succeeded」で終わるべきではありません。以下のステップが必要です：

bundleをbuildする
署名して適切なチャンネルへ公開する
リリース用メタデータを付与する
適用状況と失敗をモニタリングする
状態が悪化したらロールバックする

ロールバック機能の有無が、デモ用のアップデートツールと本番用のツールの分かれ目です。もしbundleが原因でアプリの起動クラッシュや起動時のデッドロックが発生した場合、チームは被害範囲を迅速に食い止める手段を必要とします。多くの開発エージェンシーにおいて、自作よりもマネージドツールが優れている最大の理由の一つがここにあります。デリバリー、ガードレール、オブザーバビリティ、そしてロールバックは、単なる付加機能ではありません。それ自体がシステムなのです。

CI/CDの統合自体は複雑である必要はありません。重要なのは、公開プロセスが決定論的（deterministic）で、追跡可能であることです。リリースは、コミット、環境、実行者、そしてチャンネルに紐付けられるべきです。これら4つの要素に即座に答えられない場合、インシデント対応は困難を極めます。

通知に関する一般的なトラブルシューティング

Capacitor や Electron のアップデート実装において、以下のような問題が繰り返し発生します。その多くはネットワークの問題ではなく、状態のドリフト（state drift）に起因しています。

起動するたびにプロンプトが表示される

症状: ユーザーがアプリのアップデート通知を閉じたにもかかわらず、アプリを起動するたびに通知が再表示される。

考えられる原因: チェック自体は成功していますが、提供されたバージョンごとのプロンプト状態が保持されていません。

解決策: ユーザーが拒否または延期したバージョンを保存し、UIを再表示する前にそれと比較してください。

function shouldPrompt(version: string): boolean {
  const dismissed = localStorage.getItem('dismissedUpdateVersion')
  return dismissed !== version
}

function dismissPrompt(version: string) {
  localStorage.setItem('dismissedUpdateVersion', version)
}

また、多くのチームが「利用可能」と「割り込みが必要」を混同しています。これらは別々の判断基準です。

サイレントアップデートがダウンロードされるが、適用されない

症状: ログではbundleの取得が確認できますが、古いUIが読み込まれ続けます。

考えられる原因: アプリがアップデートをダウンロードしたものの、次回起動時の適用設定が行われていないか、起動パスが依然として最後に有効だったbundleを指しています。

解決策: 適用を明示的に行い、起動時に検証してください。codeや分析において、「ダウンロード済み」と「有効」は別の状態として扱ってください。

ライフサイクルを以下のようにモデル化すると、多くのバグが解消されます。 available -> downloading -> ready -> active 単一のbooleanではなく。

開発環境と本番環境で挙動が異なる

症状: リリースビルドではアップデートが検知されるが、ローカル開発環境では検知されない（またはその逆）。

考えられる原因: 環境固有の設定。チャンネル名の違い、デバッグ時のプラグイン無効化、あるいは起動時の code が誤ったガード条件でラップされているなど。

解決策: 環境の挙動を可視化すること。起動時にチャンネル、アプリバージョン、ビルドモードをログに出力してください。記憶に頼ってはいけません。

開発用ビルド 通常は live update のチェックをスキップするか、専用のテスト用チャンネルを参照するようにします。
ステージング用ビルド 本番環境と同様の挙動をさせつつ、隔離されたロールアウトストリームに対して実行するようにします。
本番用ビルドは 社内のQAトラフィックとチャンネルを共有すべきではありません。

チェック中にユーザーがオフラインの場合

症状: 接続がない状態でアプリを開くと、アップデートが失敗したような表示になります。

考えられる原因: チェックのパスがネットワークの成功を前提としており、失敗時に中立的な状態ではなくエラーUIにマッピングされています。

修正方法: Graceful degradation（段階的な機能縮小）を実装します。現在のバージョンをそのまま動作させ、失敗したチェックを記録し、アプリが再度アクティブになった時にリトライします。

オフラインは例外的な事象ではなく、実行時の正常な状態です。

強制アップデートの場合、オフライン時の処理には細心の注意が必要です。サポート対象の最小バージョンが既に無効な場合、アプリをブロックしたままにする必要があるかもしれません。その場合は理由を明確に説明し、接続が復旧した際にリトライのアクションを提示してください。アップデートが任意の場合は、一時的なネットワーク断絶でユーザーに不利益を与えないようにしましょう。

これらすべてのケースに共通する原則はシンプルです。分離することです。検知, ポリシー, UI、および 有効化. これらの懸念事項が単一のフックや画面コンポーネントに集約されてしまうと、デバッグは推測の域を出なくなります。

もしチームが Capacitor や Electron アプリをリリースしており、チャンネル管理、署名済み bundle の配信、ロールバック保護、デバイスレベルのオブザーバビリティを備えた制御可能なアップデートシステムを必要としているなら、 Capgo 検討する価値があります。Live Update を、手作りしたサイドプロジェクトではなく、正式なリリースインフラとして運用したいチームに最適です。

「効果的なアプリアップデート通知戦略」の続きを読む

以下を使用している場合： 効果的なアプリアップデート通知戦略 CI/CD 自動化を計画するには、次と接続します： Capgo による CI/CD Capgo CI/CD のプロダクトワークフロー向けに、 Capgo Native Build Capgo Native Builds のプロダクトワークフロー向けに、 Capgo 連携一覧 Capgo Integrations のプロダクトワークフロー向けに、 CI/CD 連携 CI/CD Integration の実装詳細向け、および GitHub Actions 連携 GitHub Actions Integration の実装詳細については。