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

エクスポ開発クライアントの準備はエクスポ・ゴーが嘘を言うのと同じタイミングです。

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

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

目次

• エクスポ・ゴーを超える必要性
  • 何が最初に壊れるか
  • 開発クライアントは正しい次のステップ
  • マインドセットの変化
• 前提条件とプロジェクト設定
  • アカウントとCLI層から始める
  • ワークフローを可能にするパッケージをインストールする
  • アプリの設定を早期に確認する
  • 良い初期設定の例
• EASでカスタムクライアントを構築する
  • 基本的なEASフロー
  • ビルドプロファイルが実際に何をしているか
  • 結果をインストールする
  • 期待しないこと
• 新しいクライアントで実行とデバッグ
  • 通常の開発セッション
  • The debugging tools that matter
  • What works well and what doesn’t
• CI/CDとライブ更新の統合
  • CI/CDの位置づけ
  • ライブ更新の役割
  • チームの習慣が混乱を防ぐ
• よくあるトラブルシューティングと修正
  • クライアントがMetroに接続しないとき
  • リビルドがランダムに感じられる
  • ビルドの失敗とチームの変化

Expo Goを超える必要性

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

アプリがプロトタイプから離れ始めた時点で問題が生じます。 ExpoはExpo Goをサンドボックスとしてドキュメントし、通知やOAuth認証などのネイティブ機能を正確にシミュレートできないことを記載しています。 開発用ビルドモデルは「デバッグ」ビルドとして位置付けられています。 expo-dev-client Expo開発ビルドの導入 Expo GoとExpo Development Clientツールの主な違いと制限を比較する表。 実際に最初に壊れるのはどれか 実用上、最初に壊れるのは通常、次のいずれかです。.

パッケージがExpo Goに含まれないネイティブ__CAPGO_KEEP_0__が必要です。

Expo Go

• Expo Go A package needs native code that Expo Go doesn’t include.
• Authentication: OAuthフローは、実際のネイティブ設定を使用するアプリで動作が異なる。
• 通知とデバイス機能: サンドボックスでは、実際のアプリがパーミッションを要求したりイベントを受け取ったりする方法を反映していない。
• チームQA: テスターは、実際のネイティブ設定を表す安定したバイナリが必要です。

それらはエッジケースではない。実際のモバイルプロジェクトの通常のステージである。

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

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

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

そのシフトは、実際のアプリを構築していることに関係する。

あなたは、より広範なアプリ配信モデルを比較する場合もあるかもしれない。Capgoの記事では、 Expoの代替 は、サンドボックスベースのワークフローを超えてチームが探している場所を強調するため、有用なコンテキストです。

意識の変化

Expo開発クライアントを1回限りのセットアップタスクとして扱うのが最大の間違いだと思います。それではありません。それはワークフローの選択です。

コントロールを得るために受け入れる1つのトレードオフ

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

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

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

Expoのドキュメントとエコシステムガイドは、開発ビルドを「完全機能の開発環境」と説明しています。 実際のプロダクション環境を表すものです。カスタムネイティブ__CAPGO_KEEP_0__や、Draftbitの概要で説明されているプロダクショングレードのQAに依存するアプリが存在する場合に限ります。 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 アカウントと__CAPGO_KEEP_0__層から始めます。.

Start with the account and CLI layer

Expo__CAPGO_KEEP_0__アクセス

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

ターミナルからExpoアカウントにログインしていることを確認してください。

チームはよくこの点を省略します。ローカルコマンドは、最初のリモートビルドまたはクレデンシャルプロンプトが表示されるまで、問題なく動作するように見えます。

• クリーンなセットアップには、通常以下の要素が含まれます。 Expoアカウントセッション:
• EAS CLI installed: EAS __CAPGO_KEEP_0__ インストール済み:
• EASはプロジェクトをiOSまたはAndroidバイナリに変換するものです。 既存のローカルに動作するプロジェクト:

基本的なアプリ起動が動作することを確認する前に、ビルドの複雑さを導入しないでください。

ワークフローを可能にするパッケージをインストールする expo-dev-clientセットアップの中心は、

アプリプロジェクトにインストールし、Expoの設定が一貫していることを確認してください。実行するコマンドはパッケージマネージャによって異なるかもしれませんが、アーキテクチャ的にはこのパッケージは、

アプリが「共有サンドボックスで実行される」から「開発用バイナリ内で実行される」に変換するものです。 実用的なルール:

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

アプリの設定を早めに確認してください app.json 多くの混乱は、 app.config.js または

をメタデータのみとして扱うことから生じています。そうではありません。これらのファイルはアイデンティティを定義します。

• プロジェクトに次のものが必要です: ユニークなアプリ名:
• 開発者が一台のデバイスに複数のバリアントをインストールする場合に便利です。 ユニークなバンドルまたはパッケージ識別子:
• 環境をクリアする意図: チームが別々のステージングとプロダクションのアイデンティティを使用している場合、意図的に反映する。

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

良い初期設定の例

EASの開始前に使用するチェックリスト

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

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

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

Expoはカスタムネイティブcode:インストールの開発ビルドワークフローを推奨します expo-dev-client、EASビルドまたはローカルでネイティブアプリを生成し、実行します npx expo start --dev-client. Expoも、ワークフロー概要で、JavaScriptのみの変更は高速で、native-__CAPGO_KEEP_0__の変更は新しい開発ビルドが必要であると記載しています。 ワークフロー概要 JavaScriptのみの変更は高速で、native-codeの変更は新しい開発ビルドが必要です。

EASの基本フロー

シーケンスは、最初の実行が不慣れに感じても、簡単です。

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

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

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

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

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

• 開発クライアントの動作を含める
• 開発者やテスターにとって、簡単に起動できる
• メトロサーバーに接続する
• 開発の日常業務で

ネイティブ依存関係が変更されるまで再利用できる

これは、CIが実用的なものになる場所でもあります。ビルドプロファイルが存在し、予測可能である場合、自動化することができます。 あなたのチームが、React Nativeがより広い現代化の作業にどのように組み込まれているかについて考える場合、Wonderment Appsは便利な視点を持っています。React Native for AI現代化

簡単なガイドを通して、流れを実際に動作させることができます。

インストール結果を設定します。

ビルドが完了したら、出力は実際のアプリケーションバイナリと同じように扱うことができます。

• Android上で Capgoを使用して通常は、__CAPGO_KEEP_0__をインストールします。 .apk ハードウェアデバイスまたはエミュレータ上で。
• iOS上では Capgoのチームと協力して、 .ipa ターゲットに応じて、シミュレータ互換出力になります。
• チームメンバー向け EASの通常メカニズムを通じてビルドを共有するのではなく、必要な場合を除いて全員が自分で作るのを避けること。

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

What not to expect

最初のビルドではネイティブの複雑さが消滅するわけではありません。 その複雑さを適切な場所に置きます。

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

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

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

サーバーを起動して npx expo start --dev-client. その後、シミュレーター、エミュレータ、または物理デバイスで開発クライアントを開き、ランチャーUIを通じて接続してください。 そのランチャーは、デバッグサポートやネットワークリクエストの検査など、ドキュメントされている expo-dev-clientExpo __CAPGO_KEEP_0__ページの開発クライアント 男性のソフトウェア開発者がSDKをノートパソコンに書き込む、専門的なオフィスワークスペース環境の写真。.

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

__CAPGO_KEEP_0__

You pull the latest branch. The installed development client is already on your device. You start Metro, launch the app, and connect to the current server. Then you work mostly as you did before, changing JavaScript and seeing updates quickly.

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

デバッグに必要なツール

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

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

開発クライアントでAPIが失敗した場合、リクエストパスと環境の仮定を調べる前に、UIcodeを触るのを避けましょう。問題は、見ているコンポーネントの外側にあります。

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

あなたのチームもウェブベースのモバイルシェルを配信している場合、Capgoの Capacitorアプリの最終ガイド __CAPGO_KEEP_0__アプリのデバッグのより広い視点

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

どれがうまくいき:

よくない点:

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

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

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

__CAPGO_KEEP_0__

CI/CDの位置付け

CI/CDは開発クライアントが自動化に安定したターゲットを提供するため、CIとよく動く。

CI/CDのパターン

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

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

The role of live updates

The development client often enables teams to save the most time operationally. The development client is a strong place to validate update behavior before release because it can switch between development servers and published updates in a production-like app shell, as described earlier in the Expo documentation.

That opens a useful split:

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

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

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

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

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

この時点で、エクスポ開発クライアントは開発者の便利さではなく、リリースインフラストラクチャになります。

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

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

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

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

これは、問題がよく発生するため、最も時間を浪費する問題です。アプリがよくあるように、問題はアプリ自体にあります。

最初に確認してください:

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

プロジェクトがシミュレーターで動作するが、物理デバイスでは動作しない場合、まずネットワークを疑うのではなく、React codeを疑うのではなく、デバイスが実際にMetroを実行しているマシンにアクセスできることを確認することから始めましょう。

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

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

リビルドの境界を理解していないチームが多い場合、変更が一部は即座に反映され、他の変更は頑固に反映されないという感覚が一般的な悩み事です。

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

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

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

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

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

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

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

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