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

エクスポ開発クライアントは、エクスポGoが嘘を言う時点で、エクスポ開発クライアントに準備できていることが多いです。

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

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

目次

• エクスポを超えてなぜ進む必要があるか
  • なぜ最初に壊れる
  • 開発クライアントは正しい次のステップなぜ
  • 意識の変化
• 前提条件とプロジェクト設定
  • アカウントとCLIレイヤーから始める
  • ワークフローを可能にするパッケージをインストールする
  • アプリの設定を早めに確認する
  • 良い初期設定の例
• EASでカスタムクライアントを構築する
  • 基本的なEASフロー
  • ビルドプロファイルが実際に何をしているか
  • 結果のインストール
  • 期待しないこと
• 新しいクライアントで実行およびデバッグ
  • 通常の開発セッション
  • 重要なデバッグツール
  • どれがうまくいき、どれがうまくいかないか
• CI/CDとライブアップデートの統合
  • CI/CDの位置づけ
  • ライブアップデートの役割
  • チームの習慣が混乱を防ぐ
• 一般的な落とし穴と修正のトラブルシューティング
  • クライアントがMetroに接続しない場合
  • リビルドがランダムに思える場合
  • ビルドの失敗とチームの疎遠

Expo Goを超えて進む必要がある理由

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

問題は、プロトタイプからアプリが停止したときに始まります。ExpoはExpo Goをsandboxとしてドキュメント化し、通知やOAuth認証などのネイティブ機能を正確にシミュレートできないことを指摘しています。開発用ビルドモデルは、 と位置付けられています。 生産用アプリのための expo-dev-client 「デバッグ」ビルド Expo開発用ビルドの導入 で紹介されています。 Expo Goは、.

何が最初に壊れるか

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

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

Authentication:

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

なぜ開発用クライアントが正しい次のステップであるか

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

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

Capgoの「Expoの代替」という記事は、サンドボックス第一のワークフローを超えてチームがどこから始めるかを強調するため、よりよいコンテキストです。 意識の変化 最大の間違いは、Capgoの開発クライアントを一度のセットアップタスクとして扱うことです。それではありません。それはワークフローの選択です。

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

ワークフロー

何が速いまま

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

前提条件とプロジェクトの構成

何も作る前に、プロジェクトを再現可能なビルドに適応させるようにしてください。ほとんどの初期失敗は、基本的な構成を省略したことによるものではなく、Expo 自身によるものではありません。

Expo のドキュメントとエコシステムのガイドラインでは、開発用ビルドを「完全機能の開発環境」として説明しています 「完全機能の開発環境」 実際の運用環境を表すものは、開発アプリがカスタムネイティブ code またはプロダクション グレードのQAに依存する場合です。 Expoの開発ツールと開発ビルド.

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

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

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

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

通常のセットアップには含まれるものは次のとおりです。

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

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

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

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

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

アプリ設定を早期に確認してください。

多くの混乱は、 app.json または app.config.js エクスポ開発クライアントのワークフローを定義するカスタムランチャーとデバッグ用のネイティブシェルが存在しないことを意味します。

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

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

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

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

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

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

ここがワークフローの実際のところだ。話はカスタムクライアントについてではなく、実際にそれを作る時だ。

Expoでは、カスタムネイティブcodeのインストール expo-dev-client、EAS Buildまたはローカルでネイティブアプリを生成し、実行する。 npx expo start --dev-clientExpoはワークフローの概要で、 JavaScriptのみの変更は速いままなのに対し、ネイティブ__CAPGO_KEEP_0__の変更は新しい開発ビルドが必要だ。 Expo開発クライアントのEAScodeツールを使ったビルドのプロセスを示す4ステップのイラスト。

シーケンスは簡単で、最初の実行は新しいものかもしれないが、順序は次のとおりだ。

EAS__CAPGO_KEEP_0__にインストールし、認証する。

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

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

ビルドプロファイルが実際に何を実行しているか

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

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

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

This is also where CI starts becoming practical. Once a build profile exists and behaves predictably, you can automate it.

CIの実行が実用的なものになるのは、この場所です。ビルドプロファイルが存在し、予測可能に動作するようになれば、自動化が可能になります。 If your team is thinking more broadly about how React Native fits into larger modernization work, Wonderment Apps has a useful perspective onReact Native for AI modernization

React NativeのAI近代化

It’s relevant because the development client often becomes part of the operational base layer when teams are shipping more frequent product changes across mobile surfaces.

開発クライアントは、チームがモバイル表面を横断して頻繁に製品を変更するときに、運用ベースレイヤーの重要な部分になります。

• A short walkthrough can help if you want to see the flow in action: 短いウォークスルーが役立ちます。フローの動作を確認したい場合は、 .apk Installing the result
• 結果をインストールすることです。 チームメンバーと一緒に .ipa ターゲットに応じてシミュレータまたはシミュレータ互換の出力になります。
• チームメンバー向け: 通常のEASメカニズムを通じてビルドを共有するのではなく、必要な場合を除いて、すべての人が自分で作成するのではなくてください。

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

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

期待しないこと

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.

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

新しいクライアントで実行およびデバッグ

最初にインストールしたクライアントを開き、Metroに接続すると、初めての違いが明らかになります。エクスポのように感じますが、もう玩具箱の感覚ではありません。 npx expo start --dev-clientサーバーを起動するには expo-dev-client、デバッグ支援機能のネットワークリクエストの検査など、 Expo SDKのページ.

通常の開発セッション

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

最新のブランチを取得します。インストールされた開発クライアントは、すでにデバイスにインストールされています。Metroを起動し、アプリを起動し、現在のサーバーに接続します。次に、主に以前と同じように作業し、JavaScriptを変更し、すぐに更新を確認します。

必要なのは、実際のネイティブ環境に依存する動作を検査するときです。カスタムクライアントは、通常のループを外に出ることなく、テストすることができます。

重要なデバッグツール

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

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

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

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

あなたのチームがウェブベースのモバイルシェルも配信している場合、Capgoの Capacitorアプリのデバッグの究極のガイド __CAPGO_KEEP_0__アプリのデバッグの究極のガイド

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

何がうまくいきます:

何がうまくいかないか:

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

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

エクスポ開発クライアントは、チームのオペレーションの一部になるまで、個人の設定から離れれば、より多く価値がある。

成熟したワークフローでは、責任を分離することが多い。nativeの変更は新しい開発ビルドを生み出す。JavaScriptとアセットの変更は、より速いアップデートパスを通る。レビューアーとQAは、チームがチャンネル、ビルドプロファイル、更新先について同意したため、正しいものをテストしているかどうか尋ねる必要がない。

CI/CDの位置付け

開発クライアントはCIとよく動作する。自動化に安定したターゲットを提供するからだ。

よくあるパターンは次のようになっている。

• プルリクエストの変更: CIはnative依存関係が変更されたときに開発ビルドを作成したり、有効性を検証したりする。
• ブランチベースの環境: 異なるブランチは異なるアップデートチャネルまたはサーバー目標にマップされます。
• 共有テスターのワークフロー: QAは1つ以上の知られている開発クライアントをインストールし、ランチャーとアップデート構成を切り替えます。

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

ライブアップデートの役割

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

そのことが、有用な分割を生み出します:

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

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

チームの習慣が混乱を防ぐ

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

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

この時点で、エクスポの開発クライアントは開発者にとっての便利さではなく、リリースインフラストラクチャになる

トラブルシューティング:よくあるミスと修正

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

最も一般的な問題の1つは、物理デバイスにメトロに接続できないことであり、これは企業や分散チーム環境におけるローカルネットワークのセグメント化、VPN、ファイアウォールのルールによって引き起こされることが多い点が、この Expo Dev Clientのトラブルシューティング動画.

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

この問題は、よく正常なアプリのように見えて、実際には最も時間を浪費する問題です。

まず確認してみてください:

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

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

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

リビルドがランダムに感じられる

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

通常、チームがリビルドの境界を理解していないことを意味します:

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

ビルドの失敗とチームのずれ

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

• 依存関係の不一致: A package version doesn’t align with the rest of the project.
• Native plugin assumptions: A config plugin expects setup the project doesn’t have.
• Credential confusion: Signing or account access isn’t consistent across the team.
• Stale local expectations: Someone assumes a fresh build isn’t needed when it is.

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

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

チームがもともとCapacitorアプリを配信している場合、ストアのレビューを待たずにJavaScript、資産、設定の更新を制御して配信したい場合は、 Capgo Capacitor