Expo GoとDevelopment Buildの違い｜切り替えが必要になる機能と判断基準

画面や処理の試作を、Expo Goに含まれる機能だけで進めるならExpo Goを使えます。独自のネイティブ機能やアプリ固有の設定を試す段階では、Development Build（自分のアプリに開発用ツールを組み込んだビルド）へ切り替えます。 切り替えた後も、JavaScriptやTypeScriptだけの変更なら、通常はアプリを毎回作り直す必要はありません。

たとえば、カメラを使うという理由だけで移行が必要になるわけではありません。Expo Goに含まれるexpo-cameraは利用できます。一方、iOSのホーム画面ウィジェットを作るexpo-widgetsはExpo Goに含まれず、Development Buildが必要です。

この記事では、機能別の判断、ビルド方法の選び方、移行後に変更を反映する手順を整理します。2026年9月10日時点の公式資料に基づく解説で、ネイティブビルドや通知・ウィジェットの実機動作を検証した記事ではありません。 SDK（開発用ライブラリ一式）の対応条件は、使用中のバージョンの資料でも確認してください。

違いは「端末に入るネイティブコード」を変更できるか

Expoのアプリを考えるときは、端末にインストールするアプリと、開発中にPCから送るJavaScriptのコードを分けると理解しやすくなります。

ネイティブコードは、iOSやAndroidの機能を使うために端末側で動く処理です。JavaScriptからカメラなどを呼び出すときも、その呼び出し先になる実装がインストール済みアプリに必要です。

図：ExpoのDevelopment builds FAQを基に独自作成。

npx expo installでライブラリを追加しても、すでに端末へ入っているExpo Goの中身は増えません。JavaScript部分だけが更新され、呼び出したいネイティブ実装が端末側になければエラーになります。

Development Buildでは必要な実装を含めてアプリを作れるため、この制約を解消できます。ただし、ライブラリが対象OSや使用中のSDKに対応していることは別途必要です。Development builds FAQ、Add custom native codeを参照してください。

機能別に切り替えを判断する

「ネイティブ機能だからすべて不可」ではなく、その機能と設定がExpo Goに含まれるかを確認します。ライブラリ名が同じでも、一部の設定だけ独自ビルドを必要とする場合があります。

カメラとSQLiteの対応はExpo CameraとExpo SQLite、ウィジェットの条件はExpo Widgetsに記載されています。リンクの関連付けと外観の制約はDevelopment builds FAQが参考になります。

通知はローカルとリモートを分ける

「10分後にこの端末へ通知する」ローカル通知と、「サーバーから別の端末へ知らせる」リモート通知では、必要な仕組みが異なります。

Expo Notificationsでは、AndroidのExpo GoはSDK 53からリモート通知に非対応と明記されています。ローカル通知は引き続き利用できます。現行のDevelopment builds FAQも、リモート通知にはDevelopment Buildを使う方針を示しています。

古い記事の「Expo Goで通知できた」という説明を読むときは、通知の種類、OS、SDKの3点を確認してください。移行しても通知の認証情報や権限設定が自動で完成するわけではなく、送信・受信・通知タップ時の処理を確認する必要があります。

起動画面はDevelopment Buildだけで完了にしない

Development Buildは、実際に配布するリリース用アプリとは開発ツールや動作条件が異なります。

Expo SplashScreenは、SDK 52以降のAndroidについて、Expo GoとDevelopment Buildではユーザーが見る起動画面を完全に再現できないと説明しています。設定が反映されない場合にキャッシュ削除だけを繰り返すより、リリース用ビルドで確認する項目かを先に判断します。

Development BuildとEAS Buildは役割が違う

Development Buildは作るアプリの種類です。EAS Buildは、Expoのサービスでアプリをビルドする方法です。Development Buildはローカルでも作れます。以下で使うCLIは、ターミナルからコマンドで操作するツールのことです。

各経路の概要はIntroduction to development buildsにまとまっています。EASの利用枠と課金条件はExpo Application Services pricingで実行前に確認してください。

WindowsからiPhone向けに作る場合

WindowsからEASのクラウドビルドを依頼することはできます。ただし、iPhone実機用のビルドにはApple Developer Programのアカウントや端末登録などの条件があります。iOS実機向けクラウドビルドの手順を確認します。

iOS Simulator（Mac上のiOSシミュレーター）向けビルドは別の成果物で、iPhoneにはインストールできません。Simulator向けならストア開発者アカウントは不要ですが、作ったアプリを動かすMac側の環境が必要です。Create your first buildに対象別の条件があります。

MacとXcodeでローカルに作る場合は、有料のApple DeveloperアカウントなしでiPhoneへ開発用アプリを入れる経路もあります。署名や使える機能の条件があるため、「Development Buildには必ず有料登録が必要」と一括りにせず、自分のビルド経路と必要機能で判断します。

既存プロジェクトを移す手順

以下は公式手順に沿った導入例です。既存のExpoプロジェクトで実行することを想定しています。認証情報の作成やクラウドビルドまでを自動実行するスクリプトではありません。

1. 現在の状態を残し、開発用ライブラリを追加する

作業前に、動いているソースとロックファイルをGitのコミットなどで保存します。特にios/やandroid/を手編集している場合は、後述するネイティブプロジェクトの再生成に注意が必要です。

プロジェクトのルートで実行します。

# 使用中のExpo SDKに合うバージョンを選ぶためexpo installを使う
npx expo install expo-dev-client

expo-dev-clientは、開発サーバーを選ぶ画面や開発メニューなどをアプリへ組み込むためのライブラリです。依存関係に追加した時点では端末のアプリは更新されないため、続いてビルドとインストールを行います。

2. 選んだ経路でビルドする

ローカルでAndroidを作る例です。Android Studioなどの環境を用意し、エミュレーターを起動しておきます。

npx expo run:android

MacでiOS Simulator向けに作る例です。XcodeとSimulatorの準備が必要です。

npx expo run:ios

これらのコマンドは、対象のネイティブディレクトリがなければ生成し、ビルド・インストール・開発サーバー起動へ進みます。実機を選ぶ場合は--deviceを使いますが、接続・開発者モード・署名などの端末別準備を済ませてください。公式のローカル導入手順が前提を説明しています。

EASのクラウドで作る場合は、クラウド開発ビルドの設定手順に従い、Expoへのログインとプロジェクトの関連付け、eas build:configureを行います。

作成されたeas.jsonでは、使うプロファイル（ビルド設定のまとまり）にdevelopmentClient: trueとdistribution: internalがあることを確認します。既存ファイル全体をサンプルで上書きせず、他の設定を残します。

EAS CLIを導入・設定済みで、利用枠と署名の扱いを確認した後のAndroid向け実行例は次のとおりです。

# developmentプロファイルを指定し、開発用アプリを作る
eas build --profile development --platform android

ビルドが成功したら、その成果物を対象端末へインストールします。iOS実機は前述の端末登録を含む専用手順に従い、Simulator向け設定と混ぜないでください。

3. 自分の開発用アプリを開く

インストール後、開発サーバーの接続先を明示します。

# Expo Goと取り違えないよう開発用アプリを接続先にする
npx expo start --dev-client

端末では、今回インストールした自分の開発用アプリを起動し、サーバーへ接続します。PCと端末が通信できることも必要です。--dev-clientは接続先を指定するためのオプションです。端末へ入れる開発用アプリは、先にビルドしておく必要があります。

ここでの成功条件は、自分のアプリから開発サーバーへ接続でき、画面の文言などを変更すると反映されることです。接続方法はUse a development buildを参照してください。

変更後は再読み込みか、再ビルドか

移行後の作業を決める基準は、変更がインストール済みアプリのネイティブ部分に及ぶかどうかです。

図：ExpoのUse a development buildを基に独自作成。

config pluginは、ビルド前にネイティブプロジェクトへ設定を反映する仕組みです。app.jsonを変更したというだけで一律に判断するより、変更した項目がネイティブ設定に反映されるかを確認します。Add custom native codeとUse a development buildが参考になります。

ネイティブディレクトリがある場合の注意

CNG（設定からネイティブプロジェクトを生成する運用）でネイティブ設定を変更した場合は、ios/やandroid/へ再反映する工程も必要です。すでに存在するディレクトリを、後続のビルドがいつでも自動更新するとは限りません。

特にnpx expo prebuild --cleanは、生成済みディレクトリを作り直すため、そこへ加えた手修正を失う可能性があります。ネイティブコードを手で管理しているプロジェクトでは無条件に実行せず、変更を保存し、採用している運用に合わせて反映してください。CNGを使っていて、手修正をconfig pluginなどから再現できる状態なら、prebuild --cleanで再生成してからビルドします。Continuous Native Generationに、EAS Buildとローカル実行それぞれの扱いが記載されています。

移行できたかを確認する

画面が開いたら、今回Development Buildへ移った理由になる機能を試します。次の表は、読者の環境で行う確認項目です。

ネイティブモジュールが見つからない場合は、依存を入れた後にビルドしたか、新しい成果物を端末へ入れたか、正しいアプリを開いているかを確認します。足りないネイティブ実装は、JavaScriptのキャッシュを消すだけでは追加できません。

学習中の画面試作ならExpo Goから始められます。アプリとして継続開発するなら、必須機能にExpo Go非対応のものがあると分かった時点で、機能実装と並行してDevelopment Buildを用意するのが進めやすいでしょう。リモート通知やウィジェットを最後まで未確認のまま残さず、早い段階で端末上の制約を確かめられます。