__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

ドナルディュー・マーティン

ドナルディュー・マーティン

目次

• Expo Goを超えて進む理由
  • なぜ最初に壊れるか
  • 開発用クライアントは正しい次のステップ
  • 意識の変化
• 前提条件とプロジェクト設定
  • アカウントとCLI層から始める
  • ワークフローの可能なパッケージをインストールする
  • アプリの設定を早めに確認する
  • 良い初期設定の例
• EASでカスタムクライアントを構築する
  • EASの基本フロー
  • __CAPGO_KEEP_0__は実際に何を実行しているのか
  • __CAPGO_KEEP_0__の結果をインストール
  • 期待しないこと
• __CAPGO_KEEP_0__と一緒に実行してデバッグ
  • 通常の開発セッション
  • デバッグに役立つツール
  • どれがうまく動作し、どれがうまく動作しないか
• CI/CDとライブアップデートの統合
  • CI/CDの役割
  • ライブアップデートの役割
  • チームの習慣が混乱を防ぐ
• 一般的な障害と修正
  • クライアントがMetroに接続しないとき
  • Metroに接続するときにランダムに再構築される
  • ビルドの失敗とチームの疎遠

Capgoの必要性

Expo Goは初期段階では便利です。セットアップの摩擦を削減し、React Nativeプロジェクトを迅速に実行し、迅速なフィードバックループを提供します。これが多くのチームがそこから始まる理由です。

問題は、プロトタイプがアプリケーションに変化したときに始まります。ExpoはExpo Goを サンドボックス としてドキュメントし、通知やOAuth認証などのネイティブ機能を正確にシミュレートできないことを注釈しています。開発用ビルドモデルは expo-dev-client と位置付けられており、生産用アプリケーション向けの デバッグ ビルドとして構築されています。 Expoの開発用ビルドの導入.

何が最初に壊れるか

実際には、最初の破損は通常次のいずれかです。

• ネイティブ依存関係: A package needs native code that Expo Go doesn’t include.
• 通知とデバイス機能: サンドボックスでは、実際のアプリがパーミッションを要求したりイベントを受け取ったりする方法を反映していません。
• チームQA: テスターは、実際のネイティブ設定を表す安定したバイナリが必要です。
• それらはエッジケースではありません。実際のモバイルプロジェクトの通常のステージです。 Native dependencies:

Authentication:

Expo Goは、インターフェイスを提供するのに適しています。 しかし、実稼働の動作を検証するには弱い所です。

開発クライアントは正しい次のステップです

Expoの開発ツールを組み込んだカスタムアプリバイナリを提供するExpo開発クライアントは、開発者体験を強固に維持しながら、ネイティブ層をあなたのものにします。 つまり、インストールされたクライアントは、チームがテストする対象になり、汎用コンテナに頼る必要がなくなります。

そのシフトは、実際にはそれほど大きくないように思えるものの、重要です。 カスタムクライアントに移行すると、質問が「Expo Goで動くか？」から「私たちが作っているアプリで動くか？」に変わるのです。 これが正しい質問です。

あなたが、より広範なアプリ配信モデルを比較している場合、Capgoが書いた「Expoの代替」という記事は、チームがサンドボックス第一のワークフローを超えて見るようになった所の重要な背景を示しています。 意識の変化 Expo開発クライアントを扱う際の最大の間違いは、1回のセットアップタスクとして扱うことです。 そうではありません。 それはワークフローの選択です。

あなたは、コントロールを得るために1つのトレードオフを受け入れることになります。

ワークフロー

何が速いままであるか?

プロフェッショナルなアプリ開発では、信頼性の高い配信を優先するようになります。デモの最適化を停止し、信頼性の高い配信を優先します。

前提条件とプロジェクト設定

何も作る前に、プロジェクトを再現可能なビルドに適した状態にします。基本的な設定を省略することによる失敗した最初の試みの多くは、Expo自体ではなく、Expoのドキュメントとエコシステムガイドラインが開発ビルドを「完全機能する開発環境」と説明しているためです。

Expoのドキュメントとエコシステムガイドラインでは、開発ビルドを「完全機能する開発環境」と説明しています。 “完全機能する開発環境” That’s representative of a real production environment once apps depend on custom native code or production-grade QA, as covered in Draftbit’s overview of Expoの開発ツールと開発用ビルド.

アカウントとCLI層から始めましょう

アプリ層が重要になる前に、2つのことが動作している必要があります:

1. ExpoのCLIアクセス
2. EASのCLIアクセス

また、ターミナルからExpoアカウントにログインしていることも必要です。チームはこのことを省略することがよくあります。ローカルコマンドは、最初のリモートビルドまたはクレデンシャルプロンプトが表示されるまで、問題なく動作するように見えます。

通常、クリーンなセットアップには含まれます:

• Expoアカウントセッション これはローカルワークをリモートビルドサービスとプロジェクトオーナーシップに結び付けます。
• EAS CLI installed: EASはプロジェクトをiOSまたはAndroidバイナリに変換するものです。
• A project that already runs locally: 基本的なアプリ起動が動作する前に、ビルドの複雑さを導入しないでください。

アプリのワークフローを可能にするパッケージをインストールしてください

このセットアップの中心は expo-dev-clientそれがないと、カスタムランチャーとデバッグ用のネイティブシェルが定義されるエクスポ開発クライアントワークフローが実行されません。

アプリプロジェクトにインストールし、エクスポの設定が一貫していることを確認してください。パッケージマネージャによって実行するコマンドが異なるかもしれませんが、アーキテクチャ的には、このパッケージはアプリを「共有サンドボックス内で実行する」から「開発用バイナリ内で実行する」に変換するものです。

実用的なルール: ネイティブ依存リストがチームメンバーが同じバイナリをインストールして使用できるようになるまでに安定していることを確認して開発クライアントをビルドしてください。

アプリの設定を早く確認してください

多くの混乱は、 app.json 、 app.config.js をメタデータとしてしか扱わないことから生じています。そうではありません。これらのファイルはアイデンティティを定義しています。

プロジェクトには、以下の条件を満たしていることを確認してください:

• ユニークなアプリ名: 開発者が 1 つのデバイスに複数のバリアントをインストールする場合、役に立つ場合があります。
• ユニークなバンドルまたはパッケージ識別子: ネイティブビルドと後続の署名のために重要です。
• 明確な環境の意図: チームが別々のステージングとプロダクションのアイデンティティを使用している場合、意図的に反映することが必要です。

ローカル環境が汚れている場合、最初のビルド前に整理する価値があります。 Capgoのローカル環境の設定方法のCapgoのガイドはExpoに依存していないですが、再現可能なモバイル作業は安定したローカルツールと明示的な設定から始まることを思い出させるものです。 setting up a Capacitor local environment EASの開始前にこのチェックリストを使用してください:

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

完全なものを作るのではなく、最初のビルドを面白くなくすことが目標です。それが勝ちです。

EASでカスタムクライアントを作成する

ワークフローが実際に始まるこの点で、話し合いから実際のカスタムクライアントの生成に移ります。

Expoは、カスタムネイティブcodeのインストール、生成のネイティブアプリ、EAS Buildまたはローカルで、またはEAS Buildまたはローカルで生成したネイティブアプリを実行するという開発ビルドワークフローを推奨しています。 expo-dev-clientExpoは、ワークフローの概要で、JavaScriptのみの変更は高速で、ネイティブ__CAPGO_KEEP_0__の変更は新しい開発ビルドが必要であると記載しています。 npx expo start --dev-clientEASでカスタムクライアントを作成するためのExpo開発クライアントの作成プロセスを示す4ステップのイラスト。 基本的なEASフロー that JavaScript-only changes stay fast, while native-code changes require a new development build.

The basic EAS flow

The sequence is straightforward even if the first run feels foreign:

1. Install and authenticate with EAS CLI
2. 構成を初期化または確認する
3. 開発用ビルドプロファイルを作成する
4. iOSまたはAndroid用のビルドをトリガーする
5. デバイスまたはエミュレータに結果のバイナリをインストールする

EASは、各開発者がローカルで独自のネイティブビルド状態を実行するのではなく、チームが共有されたビルド定義からバイナリを生成できるようにすることで一貫性を提供します。

あなたのビルドプロファイルが実際に何をしているか

A development プロファイルは単にラベルではありません。ビルドシステムに、このバイナリはアクティブ開発用であり、ストア配布用ではないことを伝えます。

通常、インストールされたアプリは:

• 開発用クライアントの動作を含める
• 開発者やテスターにとって簡単に起動できる
• メトロサーバーに接続して、日常の作業中に
• __CAPGO_KEEP_0__がnative依存関係の変更まで再利用可能です

CIが実用的なものになるのは、この場所です。ビルドプロファイルが存在し、予測可能に動作するようになると、自動化することができます。

Wonderment Appsは、React Nativeがより広い現代化作業にどのように組み込まれるかについて、より広い視点でチームが考えている場合に、役立つ視点を持っています React Native for AI現代化開発クライアントは、チームがモバイル表面を横断して頻繁に製品を変更する場合、運用ベースレイヤーの一部になることがよくあります。

実行の流れを確認したい場合は、短いガイドを参照してください:

結果のインストール

ビルドが完了したら、実行可能ファイルとして出力物を扱うようにしてください。そうすることで、実際のアプリケーションバイナリと同じように扱うことができます。

• Androidの場合: 通常、 .apk 物理デバイスまたはエミュレータにインストールします。
• iOSの場合: You’ll work with an __CAPGO_KEEP_0__ or simulator-compatible output depending on the target. .ipa チームメンバー向け:
• Share the build through the normal EAS mechanisms instead of asking everyone to create their own from scratch unless necessary. 開発用ビルドの管理は、チームが一つのルールで同意することが最も簡単です: rebuild for native changes, not for every __CAPGO_KEEP_0__ change.

A development build is easiest to manage when the team agrees on one rule: rebuild for native changes, not for every code change.

Don’t expect the first build to eliminate native complexity. It puts that complexity in the right place.

新しいネイティブモジュールを追加したり、権限を変更したり、__CAPGO_KEEP_0__-level ネイティブ依存関係を更新したり、またはプラグインドライブネイティブ設定を変更した場合、最新の開発用ビルドが必要になります。 それが正常です。 その報酬は、クライアントがアプリを反映しているので、日常のJavaScript作業は、クライアントが反映しているので、迅速に進むことができます。

If you add a new native module, change permissions, update SDK-level native dependencies, or modify plugin-driven native config, you’ll need a fresh development build. That’s normal. The reward is that your day-to-day JavaScript work still moves quickly inside a client that reflects your app.

最初に、Metroに接続したインストールされたクライアントを開くと、違いが明らかになります。 それがExpoですが、もう玩具箱の意味ではありません。

Start the server with

次に、シミュレーター、エミュレータ、または物理デバイスで開発クライアントを開き、ローンチャーUIを通じて接続してください。 そのローンチャーは、Capacitorによって導入された重要な変更の1つです。 npx expo start --dev-clientWhat’s changed expo-dev-client、ネットワークリクエストの検査など、デバッグサポートとともに、 Expo SDK の開発用クライアントのドキュメント.

通常の開発セッション

通常のセッションは次のようになります。

最新のブランチを取得します。インストールされている開発クライアントはすでにデバイスにインストールされています。Metroを起動し、Appを起動し、現在のサーバーに接続し、次に通常どおり作業を続けます。JavaScriptを変更し、すぐに更新を確認します。

実際のネイティブ環境に依存する動作を検査する必要があるときに、大きな違いが現れます。カスタムクライアントは、通常のループを外に出ることなく、テストフローを実行することを許可します。

重要なデバッグツール

追加のツールは装飾ではありません。日常の問題を解決します。

• ランチャーUI: 環境を切り替えたり、チームメイトがホストするサーバーに接続したりするときに便利です。
• 開発者メニュー: 開発中の反復で期待どおりのアクションを提供します。
• ネットワークの検査: UI が壊れているように見えても実際の問題はリクエストの失敗、認証状態、または環境の設定ミスです。

When API calls fail in a development client, inspect the request path and environment assumptions before touching UI code. The bug is often outside the component you’re staring at.

ここに実用的な利点があります。1 つのインストール済みバイナリで複数の環境を検証できます。毎回コンパイルする必要はありません。特にレビュアーが PR のプレビューをテストしたい、QA エンジニアがステージングをテストしたい、開発者がローカルブランチをテストしたい場合に便利です。

チームがもともとウェブベースのモバイルシェルを配信している場合、Capgo の 開発者向けの Capacitor アプリのデバッグの究極のガイド は、より広範なデバッグの視点を取り入れるのに値です。ツールは異なりますが、Discipline は似ています: 送信、環境、実行時ビヘイビアを検査して推測するのを避けます。

どれがうまくいき、どれがうまくいかないか

どれがうまくいくか

よくない点は

• クライアントを廃棄物として扱うこと: チームがメンテナンスしないと、混乱が急速に広がる
• ネイティブのビルドの境界を無視する: __CAPGO_KEEP_0__は古いクライアントが時間を浪費する場合に発生します。
• __CAPGO_KEEP_0__がすべての接続失敗をアプリのバグであると仮定すると: __CAPGO_KEEP_0__は多くの場合、ローカル環境の問題です。

CI/CDとライブアップデートの統合

Expo開発クライアントは、チームのオペレーションの一部になるまで、個人の設定から離れると、より多くの価値を提供します。

成熟したワークフローでは、責任の分離が一般的です。

JavaScriptとアセットの変更は、より速いアップデートパスを通っています。

レビューアーとQAは、チームがチャンネル、ビルドプロファイル、およびアップデートのDESTINATIONについて同意したため、どのものをテストしているかを尋ねる必要がなくなります。

CI/CDパイプラインの自動化ワークフローを大きなオフィスディスプレイスクリーンに共有するプロフェッショナルチームの例です。

• CI/CDの位置付け 開発クライアントはCIとよく動作するため、自動化に安定したターゲットを提供します。
• Branch-based environments: 異なるブランチは異なる更新チャネルまたはサーバー ターゲットにマップされます。
• 共有テスター ワークフロー: QAは1つ以上の知られている開発クライアントをインストールし、ランチャーと更新構成を切り替えています。

その構造は曖昧さを軽減します。開発者は再構築が必要なときにわかります。テスターは、既存のバイナリの上に配信される更新を検証するか、ネイティブの変更を検証しているかを知っています。

ライブ更新の役割

開発クライアントは、チームが最も時間を節約できるオペレーションを実行できることがよくあります。開発クライアントは、リリース前に配信更新の動作を検証する強力な場所です。開発サーバーと公開更新を、プロダクション ライクなアプリ シェル内で切り替えることができます。これは、以前Expoドキュメントで説明したように。

そのため、有用な分割が生まれます:

Expoの更新スタック外のチーム向け CapgoのCI/CD統合ガイド Capacitor側で比較的運用可能なモデルが示されています。 チャネルと更新の配信の自動化を実現したいチーム向けのオプションです。

信頼できるパターンは簡単です。ネイティブcodeの変更をビルドする。インストール済みバイナリが必要な変更すべてを含む場合、既にインストールされているバイナリを公開します。

混乱を防ぐチームの習慣

技術的な設定は重要ですが、運用ルールの方が重要です:

• Name channels clearly: staging, productionとチャンネル名が明確であること。
• Document rebuild triggers: 新しいプラグイン、権限の変更、またはネイティブ SDK の更新は、判断が必要なものではありません。
• Keep one installable client per environment strategy: 多くのバリエーションはサポートのノイズを生み出します。
• Make update validation explicit: 誰かが、更新が適用され、起動する同一のバイナリであることを確認する必要があります。

At this point, the Expo development client stops being a developer convenience and becomes release infrastructure.

トラブルシューティングの一般的なミスと修正

Expo開発クライアントの多くの問題は、問題の場所を知っている場合、普通のものです。彼らは、境界をまたいで失敗することが多いから、不思議に感じることになります: ラップトップからデバイス、メトロからアプリ、ネイティブの構成からJavaScriptの実行環境。

一番よくある、しかし、よく話されていない問題は、物理デバイスにメトロに接続できないことです。ローカルネットワークのセグメント、VPN、企業や分散チーム環境のファイアウォールのルールのためです。 Expo Dev Clientのトラブルシューティング動画.

Metroに接続しないクライアント

この問題は、よくあるアプリが正常に動作しているのに、壊れたアプリのように見えるため、最も時間を浪費する問題です。

最初に確認するものは次のとおりです:

• 同一ネットワークの仮定: デバイスとノートパソコンは、孤立したセグメントに座っている場合でも、接続されているように見える可能性があります。
• VPNの干渉: 企業または個人のVPNは、Metroが許容しないように、トラフィックをリダイレクトする可能性があります。
• ファイアウォールのルール: セキュリティツールは、開発用のローカルトラフィックをブロックすることがあり、明確に示されない可能性があります。
• 企業デバイスのポリシー: 管理されたデバイスでは、開発ツールが依存するトラフィックパターンを制限することがあります。

プロジェクトがシミュレーターで動作するが、実機では動作しない場合、ネットワークを疑う前にReact codeを疑ってください。

アプリ内から接続の失敗をデバッグしないでください。デバイスが実際にMetroを実行しているマシンにアクセスできることを確認してください。

再構築がランダムに感じられる

よくある悩みの1つは、ある変更が即座に表示され、他の変更が頑固に表示されないように感じることです。

通常、チームが再構築の境界を理解していないことを意味します:

これはワークフローの欠陥ではありません。ワークフローは正しく動作しています。

ビルドの失敗とチームのズレ

ビルドが失敗した場合、原因は以下のいずれかです:

• 依存関係の不一致:依存関係が一致していません パッケージのバージョンがプロジェクトの他の部分と一致していない。
• ネイティブ プラグインの仮定: プロジェクトに設定されていない config プラグインの期待値:
• 資格情報の混乱: チーム全体で署名またはアカウントアクセスが一貫していない。
• 古いローカル期待値: 誰かが、実際には必要な新しいビルドが必要な場合に、ビルドが必要ではないと仮定している。

Capgoの開発者向けの ライブ更新の一般的な問題と解決策の記事は、この問題のリリース側の参考資料として役立ちます。 異なるスタックでも同じ教訓があります。多くの「アプリのバグ」は実際には配信、環境、またはバージョン統合のバグです。

エクスポの開発クライアントは、環境の信頼性をエンジニアリングの一部としてチームが扱う場合に最もよく機能します。後思いつくものではありません。そうすることで、セットアップは予測可能になり、予測可能なのは、モバイル ツールから求められるものです。

チームが Capacitor アプリも配信し、JavaScript、資産、設定の更新をストアのレビューを待たずに制御して配信したい場合 Capgo CapacitorとElectronワークフロー向けのライブアップデート、ロールアウト制御、CI/CD統合を提供するのが一つの選択肢です。