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

あなたは通常、Expo Goが嘘を言うときに、Expo開発クライアントが準備できているはずです。

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

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

目次

• Expo Goを超える理由
  • 何が最初に壊れるか
  • 開発クライアントが正しい次のステップである理由
  • 意識の変化
• 前提条件とプロジェクト設定
  • アカウントとCLI層から始めましょう
  • ワークフローを可能にするパッケージをインストールしてください
  • アプリの設定を早期に確認してください
  • 初期設定の良い例
• EASでカスタムクライアントを作る
  • EASの基本フロー
  • ビルドプロファイルが実際に何をしているか
  • 結果をインストールする
  • 期待すべきことと期待しないこと
• 新しいクライアントで実行とデバッグ
  • 通常の開発セッション
  • デバッグに役立つツール
  • どれがうまくいき、どれがうまくいかないか
• CI/CDとライブアップデートの統合
  • CI/CDの位置づけ
  • ライブアップデートの役割
  • チームの習慣が混乱を防ぐ
• 一般的な落とし穴と修正
  • クライアントがメトロに接続しないとき
  • リビルドがランダムに感じられるとき
  • ビルドの失敗とチームのズレ

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

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

問題は、プロトタイプがアプリケーションから離れるときに始まります。ExpoはExpo Goを サンドボックス と記載し、通知やOAuth認証などのネイティブ機能を正確にシミュレートできないことを指摘しています。開発ビルドモデルは expo-dev-client と位置付けられています 「デバッグ」ビルドの生産用アプリ 「」の中で エキスポ開発用ビルドの紹介.

何が最初に壊れるか

実際には、最初の破損は通常これらのうちの1つです

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

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

Expo Goはインターフェイスを証明するのに適していますが、生産的な動作を検証するのは弱い所です。

開発クライアントの正しい次のステップの理由

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

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

あなたがより広範なアプリ配信モデルを比較する場合、Capgoによる Expoの代替 の記事は、サンドボックス第一のワークフローを超えてチームがどこから始めるかを強調するため、有用な背景情報です。

意識の変化

最大の間違いは、Expo開発クライアントを一度のセットアップタスクとして扱うことです。そうではありません。ワークフローの選択です。

制約を引き受けることでコントロールを得る

ネイティブ依存関係とネイティブ設定の変更

Prerequisites and Project Configuration

プロジェクトをビルドする前に、再生可能なビルドに耐える状態にプロジェクトを置く必要があります。多くの初期失敗は基本的な構成を省略したことによるものではなく、Expo自体によるものではありません。

Expoのドキュメントとエコシステムガイドラインは開発ビルドを 「実際の生産環境に代表される完全機能の開発環境」と説明しています。 実稼動環境を表すものは、開発中のアプリがカスタムネイティブ code またはプロダクション向けQAに依存するようになると、Draftbitが提供する概要で説明されているように Expoの開発ツールと開発ビルドの概要についてDraftbitが説明しています。.

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

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

1. ExpoCLIアクセス
2. EASCLIアクセス

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

きれいなセットアップには通常含まれます:

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

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

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

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

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

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

多くの混乱は、 app.json または app.config.js これらのファイルは、メタデータとしてのみ使用される。実際には、これらはアイデンティティを定義するものである。

または

• Appflowの比較/移行マーケティングコピー。役割:長いマーケティングまたは法的文章。見つける場所:ページalternatives/ionic-appflow.astro。Capgo製品/ブランドと開発者用語を完全に保存する。メッセージキー`appflow_cta_questions` (Appflow CTA質問)。 または
• バンドルまたはパッケージのユニークな識別子: または
• コンサルティングサービスページ。役割:セクションサブタイトルまたはタグライン。見つける場所:ページconsulting.astro。Capgo製品/ブランドと開発者用語を完全に保存する。メッセージキー`consulting_faq_subtitle` (コンサルティングFAQサブタイトル)。 Appflowプラグインまたは

ローカル環境が整理されていない場合は、最初のビルド前に整理する価値があります。 Capgoのガイドを setting up a Capacitor local environment Expo開発用のクライアントは、Capgoでは使用できませんが、再現可能なモバイル開発の基礎となるのは、安定したローカルツールと明示的な設定です。

良い初期設定の例

EASの開始前に、このチェックリストを参照してください。

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

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

ここがワークフローの現実化のポイントだ。話はカスタムクライアントから実際の生成に移る。

Expoはカスタムネイティブcodeのアプリ用に開発ビルドワークフローを推奨している。まずcodeをインストールし expo-dev-client、EAS Buildまたはローカルでネイティブアプリを生成し、次に実行する。 npx expo start --dev-clientExpoはワークフローオーバービューで 、JavaScriptのみの変更は高速で、ネイティブ__CAPGO_KEEP_0__の変更は新しい開発ビルドが必要であることを記載している。 EAScodeツールを使用したExpo開発クライアントの作成プロセスを示す4ステップのイラスト

EASの基本フロー

最初の実行は不慣れに感じるかもしれませんが、シーケンスは簡単です:

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

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

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

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

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

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

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

React Nativeのより広い現代化の取り組みについて考えているチームには、Wonderment Appsが役立つ視点があります。 React Native for AI modern化。開発クライアントは、チームがモバイル表面を跨いだ頻繁な製品変更を配信する際に、運用ベースレイヤーの一部になることがよくあります。

短いウォークスルーが役立ちます。実際のフローを確認したい場合は、以下の手順を参照してください:

結果をインストールする

ビルドが完了したら、実際のアプリバイナリとして扱うことができます。そうすることで、開発クライアントの機能を含めることができます。

• Androidの場合: 通常、 .apk デバイスまたはエミュレータ上で
• iOSの場合: チームメンバーの場合: .ipa 通常のEASメカニズムを通じてビルドを共有するのではなく、必要な場合を除いて、すべての人が自分で作成するのではなく、
• 開発用ビルドは、チームが一つのルールに同意することで、最も管理しやすいです: 原生変更の場合にのみビルドを再構築する、

各codeの変更の場合にビルドを再構築するのではなく。

期待しないこと

最初のビルドは原生の複雑さを排除することを期待しないでください。

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に接続すると、違いは明らかです。エクスポに似ていますが、玩具箱のような感覚はありません。

サーバーを起動するには npx expo start --dev-client。次に、シミュレーター、エミュレータ、または物理デバイス上で開発クライアントを開き、ランチャーUIを通じて接続します。そのランチャーは、Metroの重要な変更の1つです。また、ネットワークリクエストの検査など、デバッグサポートも提供しています。 expo-dev-clientエクスポの__CAPGO_KEEP_0__ページで詳細を参照してください。 男性のソフトウェア開発者がSDKを書きながら、専門的なオフィスワークスペース環境でノートパソコンを操作している様子。.

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

セッションの例は以下のようになります。

JavaScriptを変更し、更新が速く表示されるようにします。

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

重要なデバッグツール

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

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

開発クライアントでAPIが失敗した場合、リクエストパスと環境の仮定を検査し、UIcodeに触れる前に問題の場所を確認してください。問題は通常、表示しているコンポーネントとは別の場所にあります。

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

チームがウェブベースのモバイルシェルを配信している場合にも、Capgoの Capacitorアプリのデバッグの究極のガイド は、より広いデバッグの視点を身に付けるのに値です。ツールは異なるかもしれませんが、環境、トランスポート、ランタイムの動作を検査するというDisciplineは似ています。推測するのではなく、検査してください。

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

何がうまくいくか:

何がうまくいかないか:

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

CI/CDとLive Updatesの統合

エキスポ開発クライアントは、個人設定からチームオペレーションに変わり、より多くの価値を提供するようになることがあります。

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

CI/CDの位置づけ

開発クライアントはCIとよく組み合わさり、自動化に安定したターゲットを提供します。

一般的なパターンは次のようになります。

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

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

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

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

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

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

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

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

技術的な設定は重要ですが、運用ルールがさらに重要です:

• チャンネル名を明確に設定してください: staging, production、そしてプレビュー名は明らかでなければなりません。
• リビルドのトリガーをドキュメント化してください: 新しいプラグイン、パーミッションの変更、またはネイティブ SDK の更新は、判断が必要なものではありません。
• 環境ごとに 1 つのインストール可能なクライアントを維持する戦略を採用してください: 多すぎるバリエーションはサポートのノイズを生みます。
• 更新の検証を明示的に行ってください: 誰かが、更新が適用され、チームが期待するバイナリ内で起動されることを確認する必要があります。

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

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

エクスポ開発クライアントの多くの問題は、どこにでもあるものです。ただし、問題が発生する境界が複数あるため、不思議に感じることがあります。例えば、ラップトップからデバイス、メトロからアプリ、ネイティブ設定からJavaScriptランタイムまでです。

最も一般的な問題の1つは、物理デバイスへのメトロへの接続の失敗です。これは、企業や分散チーム環境におけるローカルネットワークのセグメント化、VPN、ファイアウォールのルールなどによって引き起こされます。この問題は、この動画で取り上げられています。 エクスポ開発クライアントのトラブルシューティング.

メトロへの接続ができない

この問題は、最も時間を浪費する問題です。なぜなら、アプリが壊れているように見えるからです。実際、アプリはよく動作しています。

まず、次の点を確認してください。

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

プロジェクトがシミュレーターで動作するが、物理デバイスでは動作しない場合、まず React の code を疑うのではなく、ネットワークを疑ってみてください。

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

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

別の一般的なフラストレーションは、ある変更が即座に表示され、他の変更が頑張って表示されないという感じです。

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

これはワークフローの欠陥ではない。ワークフローは正しく動作しているだけだ。

ビルド失敗とチームの疎外

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

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

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

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

チームがもともとCapacitorアプリを配信し、JavaScript、資産、設定の更新をストアのレビュー待たずに制御して配信したい場合 Capgo は、実行中の更新、ロールアウトの制御、CI/CD統合を提供し、CapacitorとElectronワークフローをサポートします。