Expo開発クライアントの使い方

Expo Goは嘘を言い始めたその時点で、通常はExpo開発クライアントに準備が整っている

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

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

目次

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

Expo Goを超える必要性

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

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

最初に壊れるのは

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

• ネイティブ依存関係 パッケージがExpo Goに含まれないネイティブcodeが必要です
• 認証 OAuthフローは、実際のネイティブ構成を使用するアプリで異なる動作をします
• 通知とデバイス機能 The sandbox doesn’t reflect how the production app will request permissions or receive events.
• チームQA: Aテスターには、実際のネイティブ設定を表す安定したバイナリが必要です。

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

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

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

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

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

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

https://capgo.com/blog/alternative-to-expo

エクスポの開発クライアントを、一度のセットアップタスクとして扱うのは最大の間違いだ。実際は、開発のワークフローを選択することだ。

あなたは、コントロールを得るために、1 つのトレードオフを認めています。

プロフェッショナルなアプリ開発では、良い取引だ。最小限のデモを優先するのではなく、信頼性の高い配信を優先するようになる。

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

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

Expoのドキュメントとエコシステムガイドラインは、開発ビルドを「実際の生産環境を表す完全機能の開発環境」と説明しています。 「実際の生産環境を表す完全機能の開発環境」 これは、カスタムネイティブcodeや生産環境向けQAに依存するアプリが存在する場合に、実際の生産環境と同等のものであることを示しています。これについては、DraftbitのExpoデバッグツールと開発ビルドの概要で説明されています。 アカウントと__CAPGO_KEEP_0__層から始めましょう。.

Start with the account and CLI layer

Expo__CAPGO_KEEP_0__アクセス

1. EASCLIアクセス
2. EAS CLI access

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

__CAPGO_KEEP_0__は置き換えられます

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

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

このセットアップの中心は expo-dev-clientビルドフローを可能にするパッケージをインストールしてください

このセットアップの中心は

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

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

多くの混乱は、 app.json やをメタデータとしてのみ扱うことから生じます。そうではありません。これらのファイルは、アイデンティティを定義します。 app.config.js プロジェクトには、以下のものが必要です:

ユニークなアプリ名:

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

If your local environment is messy, it’s worth tightening it up before the first build. Capgo’s guide to Capacitor環境の設定 ローカル環境の設定はExpoに特有のものではありませんが、再現可能なモバイルワークは安定したローカルツールと明示的な設定から始まることを思い出させるものです。

良い初期設定の例

EASの開始前にこのチェックリストを使用してください:

The goal isn’t perfection. The goal is making the first build boring. That’s a win.

Building Your Custom Client with EAS

This is the point where the workflow becomes real. You stop talking about a custom client and generate one.

Expo recommends a development build workflow for apps with custom native code: install expo-dev-client, generate a native app with EAS Build or locally, then run npx expo start --dev-client. Expo also notes in the workflow overview that JavaScript-only changes stay fast, while native-code changes require a new development build.

EASの基本フロー

シーケンスは、最初の実行が不思議に感じられる場合でも、簡単です:

1. EAS CLIのインストールと認証
2. ビルド設定の初期化または確認
3. 開発用ビルドプロファイルの作成
4. iOSまたはAndroid向けのビルドをトリガー
5. デバイスまたはエミュレータに結果のバイナリをインストール

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

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

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

That usually means the installed app should:

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

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

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

A short walkthrough can help if you want to see the flow in action:

結果をインストールする

ビルドが完了したら、実際のアプリバイナリとして扱うようにしてください。そうすることで、実際のアプリバイナリと同じように動作することを保証できます。

• Androidでは: 一般的には、 .apk を物理デバイスまたはエミュレータ上でインストールします。
• iOSでは: 一般的には、 .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__

初回起動時にMetroに接続すると、明らかに異なる感覚が得られます。エクスポに似ていますが、玩具箱のような感覚はなくなりました。

__CAPGO_KEEP_0__ npx expo start --dev-client次に、シミュレーター、エミュレーター、または物理デバイス上で開発クライアントを開き、ランチャーUIを通じて接続してください。ランチャーは、__CAPGO_KEEP_0__が導入した重要な変更の1つであり、ネットワークリクエストの検査など、デバッグサポートも提供しています。 expo-dev-client__CAPGO_KEEP_0__ 男性のソフトウェア開発者がSDKをノートパソコンに書き込む姿が、専門的なオフィスワークスペース環境の中で見られます。.

通常の開発セッション

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

__CAPGO_KEEP_0__

最新のブランチを取得します。インストール済みの開発クライアントはすでにデバイスにあります。Metroを起動し、アプリを起動し、現在のサーバーに接続します。すると、以前とほぼ同じように作業できます。JavaScriptを変更し、更新がすぐに表示されます。

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

The extra tooling isn’t decorative. It solves daily problems.

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

APIが開発用クライアントで失敗した場合、リクエストパスと環境の仮定を検査し、UIに触れる前にcodeを確認してください。

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

チームがウェブベースのモバイルシェルも配信している場合、Capgoの Capacitorアプリのデバッグの究極のガイド は、より広範なデバッグの視点を考慮することの重要性を理解するのに値です。ツールは異なりますが、Disciplineは似ています:トランスポート、環境、ランタイムの動作を検査し、推測するのではなく。

What works well and what doesn’t

What works well:

What doesn’t work well:

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

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

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

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

CI/CDはどこに適合する?

CI環境では、開発クライアントは自動化の安定したターゲットを提供するため、CIとよく組み合わされる。

CI環境では、開発クライアントは自動化の安定したターゲットを提供するため、CIとよく組み合わされる。

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

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

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

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

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

エクスポの更新スタック外のチーム向け CapgoのCI/CDのOTA更新のための統合ガイド Capacitor側では、類似した運用モデルを示しています。 チームが制御されたロールアウトチャネルと更新の配信の自動化を望む場合の1つのオプションです。

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

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

技術的な設定は重要ですが、運用ルールがそれ以上に重要です:

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

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

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

Expo開発クライアントの多くの問題は、問題の場所を知っているだけです。失敗はしばしば境界を越えて発生します:ノートパソコンからデバイス、Metroからアプリ、ネイティブ設定からJavaScriptランタイム

物理デバイスへのMetroへの接続の失敗は、企業や分散チーム環境のローカルネットワークセグメント、VPN、ファイアウォールルールの問題です。この点は、この Expo Dev Clientトラブルシューティングビデオ.

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

この問題は、最も時間を浪費する問題です。アプリが壊れているように見えますが、アプリはよくありません。

最初にチェックするもの

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

If the project works in a simulator but not on a physical device, suspect the network before suspecting your React code.

デバイスが実際にMetroを実行しているマシンに接続できることを確認する前に、デバッグで接続エラーを解決しません。

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

変更が一部は即座に表示され、他の変更は頑固に表示されないという一般的な不満は、チームがリビルドの境界を理解していないことを意味します。

症状

これはワークフローの欠陥ではない。ワークフローは、正しく機能している。

ビルド失敗とチームの変化

ビルドが失敗した場合、原因は以下のいずれかであることが多い。

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

Capgoの記事 開発者向けのライブ更新の一般的な問題と解決策 この問題のリリース側の問題に対する参考になる補足資料です。異なるスタックでも同じ教訓が得られます: 多くの「アプリのバグ」は実際には配信、環境、またはバージョン対称性のバグです。

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

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