Capgoのガイド: Expo開発用クライアント

エクスポ開発クライアントにアクセスする準備はできたと思いますが、実際にはエクスポゴが嘘を言っている時点です。

アプリはサンドボックスで動作しています。高速リフレッシュは素晴らしい感じです。すると、ネイティブ依存関係を追加したり、プッシュ通知を設定したり、OAuthフローをテストしたり、またはプロダクションアプリの起動方法をミラーリングしたりすると、ギャップが明らかになります。実際にはアプリをデバッグしていません。簡略化された環境をデバッグしています。

エクスポ開発クライアントはワークフローを変えるものです。エクスポが人気のある高速JavaScriptループを維持しながら、テストをカスタムネイティブバイナリに移行します。このバイナリは、最終的に配信するアプリとよく似ています。ソロ開発者にとって、これはサイクル終盤に驚きを減らすことです。チームにとっては、エクスポゴがすべてをカバーできることを前提にしない開発プロセスをサポートすることができます。共有ビルド、QA、プレビュー環境、更新検証など、エクスポ開発クライアントはこれらの機能をサポートします。

なぜCapacitorを超えて進む必要があるのか

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

問題は、プロトタイプがアプリではないときに始まります。ExpoはExpo Goを「サンドボックス」としてドキュメント化し、通知やOAuth認証などのネイティブ機能を正確にシミュレートできないことを指摘しています。開発ビルドモデルは「デバッグ」ビルドとして位置付けられており、生産環境向けアプリ用に構築されています。 Expo GoとExpo Development Clientツールの主な違いと制限を比較した表 Capacitorを超えて進むことの限界 expo-dev-client Expo Go Expo Development Client Expo Go Expo Development Client.

Expo Development Client

実際の開発では、最初の破損は通常以下のいずれかです:

ネイティブ依存関係: パッケージには、Expo Goが含まないネイティブcodeが必要です。
認証: OAuthフローは、実際のネイティブ設定を使用するアプリで異なる動作をします。
通知とデバイス機能: サンドボックスでは、実際のアプリがパーミッションを要求したりイベントを受け取ったりする方法を反映していません。
チームQA: テスターには、実際のネイティブ設定を表す安定したバイナリが必要です。

それらはエッジケースではありません。実際のモバイルプロジェクトの通常のステージです。

Expo Goはインターフェイスを証明するのに素晴らしいですが、実際のプロダクション動作を検証するには弱い場所です。

開発クライアントはなぜ正しい次のステップであるかを理解する

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

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

あなたもより広範なアプリ配信モデルを比較している場合、Capgoの「Expoの代替」という記事は、サンドボックス第一のワークフローを超えてチームがどこから探しているかを強調するため、有用な背景情報です。意識の変化最大の間違いは、Expo開発クライアントを一度のセットアップタスクとして扱うことです。それではありません。それはワークフローの選択です。

あなたは、制御を得るために受け入れるトレードオフがあります。

ワークフロー

何が速いまま

何がより形式的な手順を必要とする	Expo Go	__CAPGO_KEEP_0__
Expoの代替	基本的なJavaScriptループ	ネイティブの現実に依存するすべてのもの
エクスポ開発クライアント	JavaScriptの変更はカスタムアプリ内で発生します	ネイティブ依存関係の変更とネイティブ設定の変更

プロフェッショナルなアプリ開発では、最も簡単なデモを最適化するのではなく、信頼性の高い配信を最適化するという良い取引です。

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

何も作る前に、プロジェクトを再現可能なビルドに耐える状態にします。ほとんどの初期失敗は、基本的な設定を省略したことではなく、エクスポ自体の問題ではありません。

エクスポのドキュメントとエコシステムガイドラインは、開発ビルドを「完全機能の開発環境」と表現しています。 実際のプロダクション環境を表すものです。 カスタムネイティブcodeや、Draftbitのエクスポ開発ツールと開発ビルドの概要でカバーされているプロダクショングレードのQAに依存するアプリが存在する場合に限ります。エクスポの開発ツールと開発ビルド.

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

アプリ層の重要性は、以下の2つのことが動作する前にありません:

Expo CLI アクセス
EAS CLI アクセス

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

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

Expoアカウントのセッション: これはローカル作業をリモートビルドサービスとプロジェクト所有権とつながします。
EAS CLI インストール済み: EASはプロジェクトをiOSまたはAndroidバイナリに変換するものです。
ローカルに実行可能なプロジェクト: 基本的なアプリ起動が動作する前にビルドの複雑さを導入しないようにしてください。

パッケージをインストールしてワークフローを可能にする

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

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

実用的なルール: ネイティブ依存リストがチームメンバーが同じバイナリをインストールして使用できるようになるまでに開発クライアントをビルドする

アプリ設定を早めに確認する

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

プロジェクトには以下の要件があります:

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

ローカル環境が汚れている場合、最初のビルド前に整理する価値があります。 Capgo のローカル環境の設定ガイド setting up a Capacitor local environment 良い初期設定の例

EASの開始前にチェックリストを使用します。

チェック

なぜ重要か	Why it matters (Japanese translation): なぜ重要か
`expo-dev-client` __CAPGO_KEEP_0__	カスタム開発クライアントの動作を有効にする
Expoアカウントがリンクされている	EASのSmoothな使用のために必要
アプリ識別子は一意	ネイティブビルドとインストールの競合を防止
プロジェクトはローカルに開始	ランタイムの問題とビルドの問題を混同しないようにする
チームは再構築するときに知る	ネイティブの変更後混乱を減らす

最初のビルドが面白くないことが目標。それが勝ち

EASでカスタムクライアントをビルドする

このワークフローは現実のものになります。カスタムクライアントについて話すのではなく、実際にクライアントを生成します。

Expoはカスタムネイティブcodeを持つアプリの開発ビルドワークフローを推奨しています。codeをインストール expo-dev-client、EASビルドまたはローカルでネイティブアプリを生成し、実行します。 npx expo start --dev-clientExpoはまた、ワークフロー概要で、JavaScriptのみの変更は高速で、ネイティブ__CAPGO_KEEP_0__の変更は新しい開発ビルドが必要であることを指摘しています。 EAS__CAPGO_KEEP_0__ツールを使用してExpo開発クライアントを構築するプロセスを示す4ステップのインフォグラフィック。 that JavaScript-only changes stay fast, while native-code changes require a new development build.

A four-step infographic illustrating the process of building an Expo development client using EAS CLI tools.

EAS__CAPGO_KEEP_0__にインストールして認証

ビルド構成を初期化または確認

Install and authenticate with EAS CLI
Initialize or confirm build configuration
Create a development build profile
iOSまたはAndroid用のビルドをトリガーする
デバイスまたはエミュレータに結果のバイナリをインストールする

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

ビルドプロファイルが実際に行っていること

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

通常、インストールされたアプリは次のようになります:

開発クライアントの動作を含める
開発者やテスターにとって、簡単に起動できるようにする
メトロサーバーに接続する
ネイティブ依存性が変更されるまで再利用できる

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

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

実行の流れを確認するには、短いウォークスルーが役立ちます:

結果のインストール

ビルドが完了したら、出力を実際のアプリバイナリとして扱うようにしてください。そうでなければなりません。

Android の場合: 通常、 .apk 物理デバイスまたはエミュレータにインストールします。
iOS の場合: ターゲットに応じて、 .ipa またはシミュレータ互換出力を使用します。
For teammates: 正常のEASメカニズムを通じてビルドを共有するのではなく、必要な場合を除いて、すべての人がスクラッチから作成するのを避けること。

開発ビルドは、チームが一つのルールに同意することで、最も管理しやすいです:ネイティブの変更に対してビルドを再構築するのではなく、すべてのcodeの変更に対して。

What not to expect

最初のビルドはネイティブの複雑さを排除することを期待しないでください。それを正しい場所に置きます。

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

Running and Debugging with Your New Client

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

サーバーを起動して npx expo start --dev-client次に、シミュレーター、エミュレータ、または物理デバイス上で開発クライアントを開き、ランチャーUIを通じて接続してください。そのランチャーは、デバッグサポートやネットワークリクエストの検査など、 expo-dev-clientExpo __CAPGO_KEEP_0__ページの開発クライアントのドキュメントで、 Expo SDK page for dev client.

A male software developer writing code on a laptop computer in a professional office workspace environment.

通常の開発セッション

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

最新のブランチを取得します。インストール済みの開発クライアントはデバイスにすでにインストールされています。Metroを起動し、アプリを起動し、現在のサーバーに接続し、次に主に以前と同様に作業し、JavaScriptを変更し、更新が速く表示されます。

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

重要なデバッグツール

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

ランチャーUI: 環境やチームメイトがホストするサーバー間で切り替える際に便利です。
開発者メニュー: アクティブなイテレーション中の期待どおりのアクションを提供します。
ネットワーク検査: UIが壊れているように見えるが、実際の問題はリクエストの失敗、認証状態、または環境の設定が不正である場合に役立ちます。

APIの呼び出しが開発用クライアントで失敗した場合、リクエストパスと環境の仮定を調べて、UIに触れる前にcodeを確認してください。問題は、見ているコンポーネントの外側にあります。

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

チームがもともとウェブベースのモバイルシェルを配信している場合、Capgoの ultimate guide to debugging Capacitor apps 最終的なガイド

最終的なガイド

最終的なガイド	最終的なガイド
最終的なガイド	最終的なガイド
API の統合を検証中	ネットワークの検査はフィードバックループを短縮します
環境を切り替える	ランチャーUIは不要な再構築を避けます
チームのQAは1つのバイナリで実行されます	全員が同じネイティブのセットアップをテストします

うまくいかないこと:

クライアントを廃棄物として扱うことはうまくいきません: チームがメンテナンスしないと、混乱が急速に広がります。
ネイティブの再構築の境界を無視することはうまくいきません: ネイティブの依存関係が変化すると、古いクライアントは時間を浪費します。
すべての接続失敗はアプリのバグであると仮定することはうまくいきません: 多くののはローカル環境の問題です。

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

エクスポの開発クライアントは、個人設定からチームオペレーションに変わり、より価値のあるものになります。

成熟したワークフローでは、責任の分離が行われます。

Nativeの変更は新しい開発ビルドを生成します。

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

レビューアーとQAは、チームがチャンネル、ビルドプロファイル、更新先について同意しているため、どのものをテストしているのか尋ねる必要がありません。

プロフェッショナルなチームがCI/CDパイプラインの自動化ワークフローを大きなオフィスディスプレイスクリーンで共同作業しています。

CI/CDはどこに当てはまるか 開発クライアントはCIとよく動作するため、自動化に安定したターゲットを提供します。
よくあるパターンは次のようになります。 プルリクエストの変更:「CIはNative依存関係が変更されたときに開発ビルドを作成または検証します。
共有テスターのワークフロー: QAは1つ以上の知られている開発クライアントをインストールし、ランチャーと更新構成を切り替えています。

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

ライブ更新の役割

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

そのような分割は便利です:

変更の種類	配信パス
新しいネイティブモジュールまたはパーミッションの変更	新しい開発ビルド
JavaScriptの動作修正	更新の公開
アセットのコピーまたは調整	更新の公開
環境の検証	__CAPGO_KEEP_0__でインストール済みクライアントのチャネルまたはサーバーを切り替える

Expoの更新スタック外のチーム向け CapgoのCI/CD統合ガイド Capacitor側の比較的運用可能なモデルを示しています。

The reliable pattern is simple. Build when native code changes. Publish when the installed binary already contains everything the change needs.

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

混乱を防ぐチームの習慣

技術的な設定は重要ですが、運用ルールの方が重要です。 staging, productionチャネル名を明確に設定し、
ドキュメント再構築トリガー: 新しいプラグイン、権限の変更、またはネイティブ SDK の更新は、判断を下す必要のないものであるべきです。
環境ごとに 1 つのインストール可能なクライアントを維持する戦略: 多くのバリアントがサポートのノイズを生み出す。
更新の検証を明示的にする: 誰かが、更新が適用され、チームが期待する同一のバイナリ内で起動することを確認するべきです。

この時点で、エクスポ開発クライアントは開発者にとっての便利さからリリースインフラストラクチャに変わります。

トラブルシューティング:よくある間違いと解決策

エクスポ開発クライアントの多くの問題は、知っている場所に知識があると、普通のものです。失敗はしばしば境界を越えて発生するため、不思議に感じることがあります:ラップトップからデバイス、メトロからアプリ、ネイティブ設定からJavaScriptランタイム。

最も一般的な未論議の問題の 1 つは、物理デバイスに Metro に接続できないことです。これは、エンタープライズ環境や分散チーム環境におけるローカルネットワークのセグメント化、VPN、ファイアウォールのルールなどによるものです。この点は、このエクスポデバイスクライアントのトラブルシューティングビデオ.

クライアントがメトロに接続しない場合

この問題は、よくあるように、問題が実際にはないように見えるため、最も時間を浪費する問題です。

まず確認するものはこちらです:

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

プロジェクトがシミュレーターで動作するが、物理デバイスでは動作しない場合、まずネットワークを疑うのではなく、Reactを疑うのではなく、codeを疑うことから始めましょう。

アプリ内から接続の失敗をデバッグするのではなく、まずデバイスが実際にMetroを実行しているマシンにアクセスできることを確認することから始めましょう。

__CAPGO_KEEP_0__

__CAPGO_KEEP_1__

__CAPGO_KEEP_2__

症状	原因	対処
JavaScript の更新は通常通り適用されます	期待される動作	既存のクライアントで作業を続ける
新しいネイティブ依存関係が表示されない	ネイティブ層が変更された	新しい開発用ビルドを作成する
権限に関連する動作が不一致です	ネイティブ設定が変更されました	再構築と再インストール
1人のチームメンバーは異なる動作を確認します	異なるクライアントバイナリがインストールされています	同じビルドに合わせる

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

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

ビルドが失敗すると、原因は以下のいずれかです:

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

Capgoの記事開発者向けに、実行中の更新の一般的な問題と解決策については、リリース側のこの問題の補完的な読み物です。異なるスタック、同じ教訓: 多くの「アプリのバグ」は実際には配信、環境、またはバージョン対齐のバグです。

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

チームがもともとCapacitorアプリを配信し、JavaScript、資産、設定の更新をストアのレビュー待たずに制御して配信したい場合、 Capgo は、オプションの1つです。CapacitorとElectronワークフローのためのライブ更新、ロールアウト制御、CI/CD統合を提供します。

エクスポ開発クライアントのガイド

目次