あなたは現在、2つの状況のいずれかにいるかもしれません。チームはiOSとAndroidにリリースする必要がありますが、2つの別々のネイティブチームを雇う必要はありません、または既にハイブリッドアプリをリリースし、実際の作業が最初のリリース後で始まっていることに気づいています。
That’s where most advice on mobile development hybrid falls short. It focuses on framework selection and ignores the harder questions: how the architecture behaves under load, where performance problems come from, how to test the bridge between web and native code, and how to ship post-launch fixes without turning every small change into a store-review event.
ハイブリッド開発は、適切な戦略的選択となる場合がありますが、単に「ウェブアプリをラップする」というように扱うと、メンテナンスの罠にもなります。
目次
- ハイブリッドモバイル開発のジレンマ
- ハイブリッドアプリの内部構造
- フレームワークの選択 ハイブリッドエコシステム
- ハイブリッドの利点と欠点
- パフォーマンス、セキュリティ、テストのベストプラクティス
- ビルドの外側のCI/CDとライブアップデート
- 企業向けの移行と拡大戦略
ハイブリッドモバイル開発のジレンマ
多くの企業はハイブリッドを選ぶのは流行っているからではない。コストが高く、時間がかかり、人手が足りないiOSとAndroidのコードベースを維持することの費用が高いからだ。既存のプロダクトロードマップがすでに混雑している場合、実装面を2倍に増やした場合、組織の負担が製品価値よりも多くなることが多い。
製品やエンジニアリングのリーダーから、モバイル開発ハイブリッドが注目されている。ウェブ技術を使用してアプリを構築し、ロジックを再利用し、共有コードベースから複数のプラットフォームにアプリを配信できる。JavaScriptやフロントエンドの強いチームにとって、信頼できるモバイルプレゼンスを迅速に実現する最速のパスとなる。
ただし、ハイブリッドは無料のショートカットではありません。複製されたUIやビジネスロジックを削減する代わりに、複雑さを移すことになる。ウェブビュー、ネイティブプラグイン、パフォーマンスバジェット、リリースパイプライン、モバイル固有のUXなど、設計上の決定を取ることになる。そういったトレードオフを無視したチームは、ネイティブかハイブリッドかという間違った質問を論じているのではなく、実際の要件がモデルに合致しているかどうかを問うべきだ。
実際の開発を比較するための基礎となる点は、ビジネス上の観点から、技術的な偏見にとらわれずにネイティブとハイブリッドの決定をより広範な観点で理解することだ。共有コードベースのアプローチをより広く評価している場合、このクロスプラットフォームモバイルアプリ開発ガイドも参考になるだろう。多くのチームは、レンダリングモデルが異なるにも関わらず、ハイブリッドとクロスプラットフォームの用語を混同している。 ハイブリッド開発の実際の要件を理解するための基礎となる点は、ビジネス上の観点から、技術的な偏見にとらわれずにネイティブとハイブリッドの決定をより広範な観点で理解することだ。共有コードベースのアプローチをより広く評価している場合、このクロスプラットフォームモバイルアプリ開発ガイドも参考になるだろう。多くのチームは、レンダリングモデルが異なるにも関わらず、ハイブリッドとクロスプラットフォームの用語を混同している。 that frames the broader native versus hybrid decision in business terms, not just technical preferences. If you’re evaluating shared-code approaches more broadly, this ハイブリッド開発の実際の要件を理解するための基礎となる点は、ビジネス上の観点から、技術的な偏見にとらわれずにネイティブとハイブリッドの決定をより広範な観点で理解することだ。共有コードベースのアプローチをより広く評価している場合、このクロスプラットフォームモバイルアプリ開発ガイドも参考になるだろう。多くのチームは、レンダリングモデルが異なるにも関わらず、ハイブリッドとクロスプラットフォームの用語を混同している。 ハイブリッド開発の実際の要件を理解するための基礎となる点は、ビジネス上の観点から、技術的な偏見にとらわれずにネイティブとハイブリッドの決定をより広範な観点で理解することだ。共有コードベースのアプローチをより広く評価している場合、このクロスプラットフォームモバイルアプリ開発ガイドも参考になるだろう。多くのチームは、レンダリングモデルが異なるにも関わらず、ハイブリッドとクロスプラットフォームの用語を混同している。
実践ルール: 共有配信速度が絶対レンダリングパフォーマンスよりも重要な場合、またはユーザー体験に影響を与えない限り、プラットフォーム抽象化を許容できる製品の場合、ハイブリッドを選択します。
ハイブリッドアプリの内部構造
ハイブリッドアプリは、 ウェブアプリケーションがネイティブアプリケーションシェル内で実行されているアプリをインストールする際、ユーザーはApp StoreまたはPlay Storeからアプリをインストールするのと同じようにアプリをインストールしますが、ユーザーが見るのは、ネイティブUIコンポーネントではなく、埋め込まれたブラウザ技術によってレンダリングされるものが多くなります。
ネイティブシェルとWebView
ネイティブシェル ネイティブシェルは、プラットフォーム固有のコンテナです。アプリをパッケージ化し、インストールを管理し、アプリライフサイクルイベントに参加し、オペレーティングシステム機能へのアクセスを提供します。ネイティブシェルの中に
WebView Web ViewiOSではWKWeb View、AndroidではWeb Viewが使用されます。アプリのインターフェイスは、SwiftUI、UIKit、Jetpack Compose、またはクラシックのAndroidビューではなく、HTML、CSS、JavaScriptで構成されたブラウザエンジン内でレンダリングされます。
ハイブリッド開発の定義的な特徴は、このアーキテクチャです。イオニクスは明確に説明しています: ハイブリッドモバイル開発は、次の要素で構成されるコアロジックを記述します。 HTML5、CSS、JavaScript ブラウザエンジンとしてWKWeb ViewをiOSで、Web ViewをAndroidで使用します。 ブラウザエンジンが複雑なアニメーションや高頻度の処理のボトルネックになるため、パフォーマンス遅延やアニメーションジャンクが生じる可能性があります。 イオニクスのハイブリッドアプリ開発概要 デバイス機能とのWeb __CAPGO_KEEP_0__のやり取りの実装レベルの説明を求めるチーム向けに、Web __CAPGO_KEEP_0__がWebとネイティブ __CAPGO_KEEP_1__を橋渡しする方法についてのガイド Web ViewiOSではWKWeb View、AndroidではWeb Viewが使用されます。アプリのインターフェイスは、SwiftUI、UIKit、Jetpack Compose、またはクラシックのAndroidビューではなく、HTML、CSS、JavaScriptで構成されたブラウザエンジン内でレンダリングされます。).
For teams that want a more implementation-level explanation of how web code talks to device capabilities, this walkthrough on how Capacitor bridges web and native code は優れた技術的な相棒です。
短い視覚的な説明が役立ちます。製品、エンジニアリング、デザインを同じメンタルモデルに合わせている場合:
能力が住む橋です。
2 番目の重要なレイヤーは、 ネイティブ ブリッジ またはプラグイン レイヤーです。このレイヤーは、JavaScript がオペレーティング システムにネイティブの作業を依頼することを許可します。カメラ アクセス、位置情報、バイオメトリクス、ファイル システム アクセス、プッシュ レジストレーション、などのデバイス機能は、WebView alone から得られません。 これらは、ネイティブ API を Web レイヤーに公開するプラグインから得られます。
実際には、ユーザーは Web UI のボタンをタップします。JavaScript は、ブリッジを通じて呼び出しを発行します。ネイティブ code が受信し、プラットフォーム API と対話し、JavaScript レイヤーに結果を返します。この一巡は、プラグインの品質がどれだけ重要であるかを示しています。ブリッジが不十分に設計され、不安定、または薄く維持されている場合、フロントエンド code が綺麗であっても、アプリは脆弱な印象を与える可能性があります。
ブリッジを製品境界として扱い、便利なレイヤーとして扱わないようにします。バージョンを慎重に管理し、契約を文書化し、各機能チームが独自のネイティブ アブストラクションを開発するのを避けます。
これは、「ウェブサイトを単純に再利用する」ことが失敗する理由でもあります。モバイル ユーザーは、ライフサイクル ハンドリング、オフライン ビヘイビア、ナビゲーション パターン、キーボード ビヘイビア、セーフ エリア サポート、レスポンシブ タッチ インタラクションを期待します。これらの機能は、通常の Web アプリがうまく処理できないことが多くあります。ハイブリッド アプリは、Web レイヤーがモバイル向けに設計されている場合にのみ、ポリッシュされた印象を与えることができます。
フレームワークの選択 ハイブリッド エコシステム
ハイブリッドエコシステムは混乱することがあります。なぜなら、人々はよくフレームワークを組み合わせているからです。 真のハイブリッド フレームワークと クロスプラットフォームネイティブレンダリング フレームワーク。
WebViewベースのハイブリッドフレームワーク
厳密な意味でモバイル開発ハイブリッドを意味する場合、コアスタックは通常 Ionic, Capacitor, and Cordova.
Capacitor Capgo
コンテキスト:ライブアップデート製品ページ。役割:セクションまたはページヘッダー。見られる場所:ライブアップデートページ。Capgo製品/ブランドと開発者用語を厳密に保持する。メッセージキー`live_update_platform_capacitor_title` (ライブアップデートプラットフォームCapacitorタイトル)。 は、構造化されたネイティブアクセスを持つウェブファーストアプリを実現するために多くの現代チームが選択するランタイムです。ウェブ開発の近代的なアプローチに近いワークフローを提供し、クリーンなネイティブプロジェクト、プラグインシステムを提供します。古いハイブリッドスタックよりも近いものです。
Cordova 歴史的にも、既存のエンタープライズアプリのために、CordovaプラグインやCordova時代のビルドアサムションに依存しているものがまだあります。新しいチームにアドバイスを求められた場合、Cordovaは移行先としてではなく、目標として提示することは少ないです。
ネイティブレンダリングの代替
次にあります React Native そして Flutter. これらは、重複したプラットフォームワークを削減することで同じ購入会話に現れることが多いですが、WebViewの意味でのハイブリッドではありません。
React NativeはネイティブUI抽象化を通じてレンダリングを行います。Flutterは独自のレンダリングモデルを使用します。両方ともUI重視の製品で強力な動きのパフォーマンスとプラットフォームのフィールを提供できますが、両方とも独自のエコシステム制約、プラグインの決定、プラットフォーム固有のエスケープハッチを伴います。
ステークホルダーがこれらのオプションを比較している場合、この React Nativeの利点、欠点、コストの の分析は、初期のcodeの共有が衰えると、チームが直面する実際のトレードオフを強調するため、役立ちます。エンタープライズの一般的な決定をより直接的に表現するためには、この React Native と Capacitor は、WebView モデルとネイティブ レンダリング アプローチの違いを明確にする
実践でフレームワークを絞り込む方法
私は人気度から始めません。レンダリング要件、プラグインリスク、チーム構成から始めます。
| フレームワーク | 主な技術 | UI レンダリング | パフォーマンス | ベスト フォー |
|---|---|---|---|---|
| Ionic + Capacitor | HTML、CSS、JavaScript | ネイティブシェル内にWebView | 標準アプリフロー向けに適していますが、グラフィックス重視のインタラクションでは弱い | コンテンツアプリ、エンタープライズアプリ、内部ツール、コマースフロー |
| コルダバ | コンテキスト:ライブアップデート製品ページ。役割:セクションまたはページヘッダー。表示:ライブアップデートページ。メッセージキー`live_update_platform_cordova_title` (ライブアップデートプラットフォームコルダバタイトル) | HTML、CSS、JavaScript | ネイティブシェル内にWebView | アーキテクチャ的制限は似ており、古いプラグインパターン |
| 既存のコードベースと継承されたレガシーハイブリッドアプリ | リアクタネイティブ | JavaScriptまたはTypeScript | フレームワークの抽象化を通じてネイティブレンダリングされたコンポーネント | 多くのアプリタイプに対して強いUI反応性 |
| Flutter | Dart | フレームワーク管理レンダリング | 強力な視覚的統一性と流動的なUIが良く作られた場合 | DartのカスタムUIシステムとDartを採用するチーム |
選択肢を速く絞るには、以下の質問が必要です:
- このアプリは本当に何のアプリですか? A workflow app, catalog, field service tool, booking flow, and internal operations app often fit hybrid well. A game-like interface or highly animated social product usually pushes me toward native-rendering frameworks or native code.
- あなたがすでにどのようなスキルを持っていますか? A strong web team can become productive in Capacitor and Ionic much faster than a team that has to build native mobile depth from scratch.
- どれだけのネイティブサーフェイスが必要ですか? ロードマップがカスタムセンサーや高度なメディアパイプライン、バックグラウンド実行、または通常のOS統合に依存している場合、プラグインの成熟度を慎重に評価する必要があります。
- このアプリはどれくらい生き続けるでしょうか? 短期間で作成されたMVPは、粗い部分を乗り越えることができます。数年間のメンテナンスが必要な規制企業アプリには、きれいな統治、更新戦略、プラグインの所有権が必要です。
フレームワークはほとんどの場合、実際のリスクではありません。弱いリリースの規律、不明瞭なプラグインの所有権、デスクトップWebからコピーしたUI決定が、通常、ハイブリッドプログラムを沈没させるものです。
ハイブリッドの利点と欠点
ハイブリッドは、共通の配信が製品の経済を優先する場合にうまく機能しますが、プラットフォーム固有のパフォーマンスに依存したり、非常にきれいなネイティブのインタラクションパターンに依存したりするアプリの価値が高い場合には苦戦します。
ハイブリッドが強いフィットである場所
多くのビジネスアプリにとって、最大の利点は単純です: 1つのコードベースと1つの主なスキルセット. Web向けのチームは、両方のプラットフォームにビルド、メンテナンス、イテレーションを行うことができます。特徴を2つの別々の実装に分割する必要はありません。
そのような製品としては、以下が挙げられます:
- 運用アプリ チーム、営業チーム、または内部スタッフ向け
- コンテンツ重視のアプリ フォーム、ダッシュボード、リスト、またはアカウントワークフローが主な役割を果たすアプリ
- 商業アプリとサービス 信頼性とリリーススピードが、凝ったアニメーションシステムよりも重要なアプリ
- パイロット製品やMVP ワークフローの検証が、ネイティブの忠実性の最大化よりも重要なアプリ
戦略的な利点は、初期のスピードだけではない。継続的な一貫性もある。共有されたビジネスロジック、統一されたデザインシステム、そしてiOSとAndroidのリリーストレインの単一化により、時間の経過とともにiOSとAndroidの間のズレが減る。
チームが燃えている場所
ハイブリッドがネイティブと同じように振る舞うことを期待するのは、チームがハイブリッドの限界を認識していないことを示している。
一般的な失敗モードは、以下のとおりである。
- パフォーマンスの期待が現実的ではない。 複雑なジェスチャー、高頻度の視覚的更新、グラフィックス重視の画面はブラウザベースのレンダリングの限界を露呈します。
- UIはモバイル向けに設計されていません。 チームはレスポンシブなウェブアプリをシェルに投入し、それを完了と呼びます。ユーザーはすぐに気づきます。
- プラグイン依存性はアーキテクチャ的負債となります。 サポートされていないプラグインが1つでもあると、OSの更新や重要な機能のリリースがブロックされる可能性があります。
- デバッグはレイヤーを超えて行われます。 いくつかのバグはJavaScriptで、他のいくつかのバグはcodeで、そしていくつかのバグは両方の間のブリッジで発生します。
ハイブリッドはデフォルトでは妥協ではありません。ハイブリッドアーキテクチャが1つのものを必要としているのに、もう1つのものに最適化されている場合にのみ、ハイブリッドは妥協になります。
私はエンタープライズチームにこのアドバイスを与えます: アプリの主な仕事がユーザーがタスクを完了するのを助けること、情報を消費すること、またはビジネスワークフローを移動することである場合、ハイブリッドはしばしば実用的なフィットです。アプリの主な仕事が動きを楽しませること、リアルタイムの強力なインタラクション、または高度なグラフィックスである場合、ハイブリッドは通常は重心の間違った場所です。
パフォーマンス、セキュリティ、テストのベストプラクティス
ハイブリッドアプリは、ウェブ技術を使用することによって失敗するのではなく、チームがウェブの習慣をモバイルランタイムに持ち込むことによって失敗するのです。ウェブの標準を変えずにウェブの習慣を持ち込むことは、プロダクショングレードのハイブリッドエンジニアリングには、パフォーマンス、セキュリティ、テストの明示的なルールが必要です。
実際に意味のあるパフォーマンスの作業
ほとんどのハイブリッドパフォーマンスの問題は自作のものです。
大きいバンドル、オーバーサイズの画像、過剰な再レンダリング、長いリストを無防備にレンダリングすると、どのWebViewでも重く感じます。
- まず基本を優先してください: 一度に少ないUIをレンダリングする。
- 長いフィード、カタログ画面、イベントログの場合、仮想スクロールまたはリストウィンドウを使用します。 Split code by route or feature, and keep startup paths lean.
- __CAPGO_KEEP_0__ をルートまたは機能ごとに分割し、起動パスをスリムに保ちます。 画像やアセットを最適化する。
- 大きいメディアファイルは起動時間とスクロール時間に影響を与えます。 アニメーションの最適化を実施する。
- もし画面が複雑な動きに依存して良く感じるのであれば、低端機器で早期にテストすること。 ブラウザ開発者ツールは便利ですが、モバイルのボトルネックはデバイス上で異なる形で現れます。
このガイドの「アプリパフォーマンス最適化」のチェックリストは、この作業に役立ちます。 特に、「動く」ということから「生産機器上で安定感がある」ということまで移行しようとしているチームにとっては、ハイブリッドアーキテクチャのセキュリティルール
ハイブリッドアプリは、ウェブとネイティブの両方の世界からリスクを継承します。つまり、トランスポート、ストレージ、ブリッジコミュニケーションに制御が必要です。
いくつかの重要な点があります:
ブリッジコールを特権操作として扱うこと。
- 入力値を検証し、JavaScriptに過度に広範なネイティブ関数を露出させないようにすること。 敏感なデータを慎重に保存すること。
- 資格情報や規制されたデータのために、ブラウザスタイルのストレージ選択は適切ではないことを想定しないこと。 ウェブ層を守ること。
- Defend the web layer. Web View 内では XSS と安全なコンテンツのインジェクションは依然として重大な懸念事項です。
- プラグインのインベントリを整理しておきましょう。 各プラグインは攻撃面とメンテナンス負担を拡大させます。
セキュリティレビューはアプリケーションを層状のシステムとしてではなく、単にウェブフロントエンドをラッパーとして検討すべきです。
現実に反映されたテストスタック
純粋なウェブテストでは十分ではありません。純粋なデバイステストは遅すぎます。正解は層状の戦略です。
まずビジネスロジックとUIの挙動に関するユニットテストを実行し、主なユーザージャーニーに対するブラウザベースのエンドツーエンドカバレージを追加してください。次に、ネイティブ動作が最も重要な場所でターゲット化されたデバイステストを実行してください。例えば、パーミッション、カメラフロー、プッシュセットアップ、ディープリンク、ファイルハンドリングなどです。
最後のカテゴリは、多くのハイブリッドチームが投資不足に陥っています。アプリケーションはブラウザ上で正常に動作するかもしれませんが、実機上では期待どおりに動作しない可能性があります。ブリッジ契約、ライフサイクル動作、パーミッションフローが予想どおりに動作しない可能性があります。
ビルド CI/CD とライブアップデートのこと
ハイブリッドアプリケーションは、ストアリストイングが公開された時点で完成していません。エンタープライズチームにとって、リリースディスクipline、ロールバック戦略、更新スピードはビルド自体と同等の重要性を持つオペレーショナルモデルです。
ハイブリッドデリバリーピipelineの例
A hybrid CI/CDの設定では、通常、以下のステージを含みます:
-
Webビルドと検証
Webアプリをコンパイルし、テストを実行し、環境設定を検証し、ネイティブパッケージングに触れる前に -
ネイティブ同期とプラットフォームビルド
Webアセットをネイティブプロジェクトに同期し、署名済みiOSおよびAndroidアーティファクトをビルドし、プラグイン統合を検証します。 -
チャネルベースの配布
内部テスト、QA、ベータグループ、またはステージドプロダクションアウディエンスにビルドをプッシュし、広範なリリース前に -
リリース後観察
クラッシュ、ブリッジの失敗、プラグインの不具合、バージョンごとの採用を追跡し、サポートとエンジニアリングが迅速に対応できるようにします。
このパイプラインは重要です。なぜなら、ハイブリッドアプリには2つのリリースサーフェイスがあります:アプリバイナリとそれの中のWebバンドルです。1つの統合されたものとして扱うと、リリースプロセスが遅くなるからです。
ライブアップデートが運用を変える理由
この部分は、多くのハイブリッドガイドがほとんど触れていない部分です。しかし、モデルを正しく使用する場合、ライフサイクル上の最も強力な利点の1つです。
エンタープライズモバイルチームの28％が、App StoreとPlay Storeのレビューサイクルに伴うJS/CSS/構成修正の遅延を報告している。レビューの平均時間は3から7日によると このハイブリッドアプリ開発分析によると、ハイブリッドガイドラインはしばしば独立したアップデータを無視している。これらは 1分単位のロールアウトをサポートし、自動ロールバック保護も提供する.
この問題は実際的なものであり、理論的なものではない。JavaScript、スタイリング、構成、コピー、または他のWeb配信アセットに生じた生産的なバグを待つ必要はしばしば無駄な摩擦である。
ライブアップデートシステムを使用すると、チームは次のことができる:
- ウェブ層の欠陥を迅速に修正する フルアプリバイナリを再構築し、再提出する必要がなくなる
- ロールアウトチャネルをターゲットにする ベータユーザー、地域、または顧客セグメントに変更を選択的に提供する
- 安全にロールバックする アップデートがリグレッションを導入した場合
- ネイティブのリリースをフォーカスさせる ネイティブのレビューが必要な変更に
このカテゴリのオプションの1つは Capacitorのライブアップデートの仕組み. 実際には、プラットフォームはCapgoが署名されたWebバンドルをCapacitorアプリに配信するので、チームは標準のアプリストアのレビューサイクルを回避しながら、JavaScript、CSS、コピー、設定、資産を更新できます。また、ロールバックの制御を維持できます。
ハイブリッドアプリがポストローンチアップデート戦略を持っていない場合、設計は完了していません。最初の船積みだけが完了しています。
重要な境界は、統治です。ライブアップデートは、チャンネル、承認、署名、観察性、ロールバックパスを持つ制御されたリリースシステムとして扱うべきです。エンジニアリングの規範を回避するための言い訳ではありません。規範を適用するための方法です。
企業戦略の移行と拡大
大規模な組織は、通常、2つの方向からハイブリッドに到達します。既存のネイティブとWebの努力を統合したり、既存のハイブリッドアプリを拡大したりする必要があるからです。また、プラグイン、重複したUIパターン、不一致なリリース慣行の絡み合いを避ける必要があるからです。
移行の意味
移行が意味するのは、ビジネスロジックがすでにすでに共有されている、ワークフローがフォームドライブまたはコンテンツ中心である、会社が一つのチームがより多くの配信パスを所有したいということです。
既存のネイティブアプリが、高度にチューニングされたプラットフォームのインタラクション、先進的なメディアパイプライン、またはパフォーマンスに敏感なインターフェイスのために勝つと、意味が少なくなります。 そのような場合、通常、選択的な戦略を推奨します。 ワークフロー重視の表面をハイブリッド層に移し、パフォーマンスクリティカルなモジュールをネイティブに保ちます。
同じ原理は逆も同然です。 成功したハイブリッドアプリは、純粋にハイブリッドである必要はありません。 成熟したチームは、多くの場合、共有Web層にアプリケーションの大部分を置き、特定のネイティブモジュールを切り出すことで、パフォーマンスを向上させます。
スケールする方法を失うことなく
エンタープライズスケールはほとんどが、統治問題です。
いくつかのパターンがうまく機能します。
- プラグインの承認プロセスを定義する。 各チームがネイティブ依存関係を自由に追加しないようにする。
- 共有コンポーネントシステムを維持する。 モバイルWeb層には、どの本格的なフロントエンドプラットフォームと同じ設計の規範が必要です。
- プラットフォームcodeの所有権を明確に分離する。 誰かがiOSビルドの健康、Androidビルドの健康、ブリッジの安定性を所有する必要があります。
- リリースポリシーを標準化する。 リリースから配信されるものは何が含まれるか、ライブアップデート配信の基準は何なのか、ロールバックの承認者は誰なのかを決定する。
- 置き換え可能な設計を意識する。 1つの機能がハイブリッドの制約を超えていく場合、再実装する必要がある場合は、その機能をネイティブに再実装することができるようにする。
The strongest enterprise hybrid programs aren’t the ones that avoid native code at all costs. They’re the ones that use hybrid deliberately, keep boundaries clean, and reserve native investment for the parts that earn it.
If your team is building with Capacitor and needs a controlled way to ship post-launch fixes, Capgo Written by
