Expo SDK 56 へのアップグレード方法

Expo SDK 56 がリリースされ、React Native 0.85 と React 19.2 に対応した。Android API level 36、および Xcode 26.4 以降をサポートする。対応する最小 OS バージョンもこれまでどおりで、SDK 56 は Android 7+ と iOS 16.4 以降向けにアプリをビルドできる。変更内容の全容はチェンジログを参照してほしい。以下はハイライトをまとめた短い動画だ:

どの SDK も、大量のテストとベータ期間を経てリリースされる。その間に Expo チームとコミュニティが一体となって問題を洗い出し、他のユーザーのアップグレードを妨げる事態を防いでいる。Expo のエンジニアの多くは自身でアプリを運用しており、ベータが公開されるとすぐにアップグレードを試す。

とはいえ、実際に起こりうるパターンはほぼ無限にある。アプリはそれぞれ異なり、複雑さもさまざまだから、アップグレードのたびに個別の事情を考慮する必要がある。そこで、SDK 56 へのアップグレードに影響しうる重要な変更点をいくつか取り上げ、あわせて最新の Expo SDK へアップグレードする際に長く役立つ指針も紹介したい。

SDK 56 へのアップグレード前に知っておきたいこと

Claude Code で SDK アップグレードを進める

Expo では日々の業務で Claude Code を使っている。その経験をもとに、Expo アプリでありがちなタスクをこなす skills を expo/skills リポジトリで公開している。そのひとつが最新の Expo SDK バージョンへのアップグレードだ。パッケージのバージョン更新といった基本作業だけでなく、破壊的変更への対応や古くなった設定の整理もこなす。

ターミナルの Claude Code で次を実行する。

/plugin marketplace add expo/skills

skills marketplace を Claude に追加し、次を実行する。

/plugin install expo

Claude を再起動すれば、自然言語で SDK のアップグレードを指示できる。正しくインストールされていれば、Claude が作業を始めるときにこの skill を参照するのがわかるはずだ。

他の agent に Expo skills を導入するには、bunx skills add expo/skills を使う。

いつもどおり、作業は別ブランチで。マージやデプロイの前にコードをレビューすること。LLM は強力だが、Claude と Expo upgrade skill がすべてのケースをカバーできるわけではない。このワークフローにおいて、人間の開発者は依然として欠かせない。

ネイティブビルドの高速化

iOS ビルドを高速化するため、SDK 56 では iOS 上で最も複雑ないくつかの Expo モジュールにプリコンパイル済み XCFramework を用意した。ローカルビルドと EAS Build の両方でデフォルトで有効になり、設定は不要。無効にするには、ローカルビルドでは環境変数 EXPO_USE_PRECOMPILED_MODULES を 0 に設定し、EAS Build でも同じ値を EAS 環境変数として設定する。

Android では、expo-build-properties に手動で有効化する android.usePrecompiledHeaders オプションが追加された。自動リンクされた各ネイティブモジュールの C++ codegen 出力に CMake プリコンパイルヘッダーを適用し、Android の CMake コンパイル時間を大幅に短縮する。

Expo Go のアップデート

SDK 56 の Expo Go は Apple App Store と Google Play Store に公開されていない。公開の時期も未定で、決まり次第 SDK 56 の changelog を更新する。詳しくは「Expo Go and the App Store in May 2026」を参照。

Expo Go は手早く始めるためのツールで、モバイル開発の学びを助けるという位置づけだ。この移行期間を利用して、プロジェクトを development build に移すことを勧める。アプリストアへのリリースに必要なものは、すべてそこに揃っている。

Android 端末では Expo CLI から SDK 56 の Expo Go を直接インストールできる。iOS なら TestFlight External Beta を使うか、eas go コマンドで SDK 56 の Expo Go を自分でビルドし、自分の TestFlight チームにアップロードすればよい。

アップデート用 Hermes バイトコード diff がデフォルトで有効に

SDK 55 では expo-updates と EAS Update 向けに手動で有効化する Hermes バイトコード diffを導入した。クライアントは更新のたびに完全な bundle をダウンロードするのではなく、インストール済みバイトコードに対するバイナリパッチをダウンロードする。

SDK 56 では diffing がデフォルトで有効になる。無効にするには app.json の updates ブロックで "enableBsdiffPatchSupport": false を設定する。詳細は expo-updates API リファレンスを参照。

Expo モジュールのインライン化

プロジェクト構成の中に、JavaScript / TypeScript コードと並べて Expo モジュールを直接定義できるようになった。これをインラインモジュールと呼び、ネイティブコードの試作がかつてなく簡単になる。インラインモジュールはプロジェクト構成の一部なので、Android Studio、Xcode、その他の IDE で開発できる。詳しくはインラインモジュールのリファレンスとチュートリアルを参照。

Expo SDK アップグレードのヒント

アップグレード中に問題が起きたときの詳しいトラブルシューティングをまとめた。アップグレード前と最中の注意点を網羅し、試すのが速くて簡単な順に並べた推奨リストも付いている。ガイド全体に目を通すことを勧めるが、ここでも要点をいくつか挙げておく。

upgrade skill を使う

二度言う価値がある。expo/skills リポジトリを LLM に追加して、アップグレードを任せよう。

Expo MCP で問題を切り分ける

Expo MCP には、Claude Code、Codex、Cursor などと組み合わせてアップグレードの問題を調査するためのツールが増えた。EAS ビルドが失敗したら、build_logs ツールでビルドログを取得して AI に分析させる。expo-mcp パッケージが入っていれば、collect_app_logs ツールでシミュレータ／エミュレータからネイティブの logcat / macOS コンソールログを取得できる。

changelog を読む

ほとんどの SDK リリースには、既知の破壊的変更や、アプリ固有の事情によって設定の調整が必要になりうる重要な変更が並んでいる。changelog と破壊的変更を読むのに最適なタイミングはアップグレードの前で、そうすればテスト前に調整を済ませられる。次に良いのはアップグレードの後、特にコンパイルエラーやクラッシュに遭遇したときだ。

Expo Go の代わりに development build を使う

アップグレードは、時間に余裕があって急いでいないときにやるのが一番いい。SDK のリリース後、手元の Expo Go は自動で最新版に上がる。するとアプリが Expo Go で動かなくなり、機能開発を続けるにはすぐアップグレードしなければ、と思うかもしれない。

Development build があれば少し落ち着ける。進行中の機能開発を止めずに、時間と余裕をもってアップグレードできる。Development build の使い勝手は Expo Go とよく似ていて、QR コードをスキャンすればローカルでコードを変更でき、再ビルドは不要だ。ただしこれは自分のアプリなので、Expo Go の新バージョンが出ても一緒にアップグレードされることはない。

Expo Go をどうしても使い続けたいなら、Play Store や App Store にある最新版を使う必要はない。https://expo.dev/go から旧バージョンをダウンロードすれば、Android 実機と iOS シミュレータで使える。残念ながら、App Store の制約により iOS 実機では使えない。

とはいえ、development build に移行すべき理由はもう一つある。Expo Go は本番アプリを再現する能力がかなり限られているため、「Expo Go では問題なかったのに、本番アプリをビルドしたら壊れた」という事態がよく起きる。Expo Go は JavaScript は動かせるが、app.json / app.config.js の設定の大半は使われない。ネイティブコードの変更が必要だからだ。要するに、あなたのアプリの独特な部分、特別な部分は、Expo Go にはほとんど載らない。development build なら載る。Free プランの枠でも development build はいくつか作れるし、npx expo run:android や npx expo run:ios でローカルビルドもできる。

New Architecture に関するアドバイス

Expo SDK 54 は Old Architecture をサポートする最後の SDK だ。SDK 55+ / React Native 0.83+ は New Architecture しかサポートしない。まだ New Architecture にアップグレードしていないなら、今がまさにその時だ。react-native-reanimated v4 や @shopify/flash-list v4 など、主要パッケージの最新版の多くは New Architecture しかサポートしていない。

Expo SDK のアップグレードと New Architecture への移行を同時にやらないこと。 問題を切り分けるのが難しくなる。Expo SDK のアップグレードよりも New Architecture への移行のほうが変更が大きいので、問題が起きれば原因はまずそちらだと考えられる。しかし、二つを同時に進めると、それが判断できなくなる。

まず SDK 54 のまま新アーキテクチャへアップグレードし、それから development build を作ることを勧める。テストして問題があれば、New Architecture のトラブルシューティングガイドを参照してほしい。新アーキテクチャへのアップグレードだけで問題なく動くことを確認してから、SDK 56 にアップグレードして新しい development build を作る。こうすれば、SDK 56 へのアップグレードを単独でテストできる。

トラブルシューティングガイドを見る

よく使うトラブルシューティングガイドをまとめたページがあるので、自分の問題に応じてたどってほしい。ビルド時のエラーなら、クラッシュやパフォーマンスの問題とは取るべき手順が違う。根本原因を完全に特定できなくても、ADB Logcat や macOS コンソールなどのツールを使ってOS が報告するクラッシュのネイティブエラーを突き止めれば、さらに調査するにせよ、誰かに助けを求めるにせよ、大きな助けになる。

助けが必要なら連絡を

バグ報告とフィードバックに感謝する。問題を伝える最善の方法は、常に最小再現を添えた GitHub issue だ。デフォルトのプロジェクトテンプレート（npx create-expo-app で作成）をベースにした GitHub リポジトリのリンクと、問題を再現するのにちょうど足りるコードを添えてほしい。

最小再現があれば、チームがあなたと同じものを見ていると確認でき、修正があなたの問題に効くかどうかもテストできる。手間に見えても、15〜30 分かけて最小再現を作るほうが、実際のアプリで何時間もデバッグするより効率的なことが多い。実際のアプリは変数が多すぎて、問題を切り分けるのが難しいからだ。Claude のような AI ツールなら、最小再現作りを手伝ってくれる。

再現を用意する準備がまだできていなくても、その場で問題について話すことには価値がある。同じ状況に遭遇した他の開発者が、すでに答えを持っているかもしれない。Discord、Reddit、Bluesky などで問題を話すことは、協調的なラバーダックデバッグになり得る。やり取りのなかで一緒に答えを見つけられる。

遭遇した問題を説明するのにスクリーンショットや動画を送ってほしい。少なくとも、具体的に何が起きているのか、どのプラットフォームに影響するのかを書いてほしい。どこでつまずいているのかを把握でき、コミュニティが原因の特定と解決に動きやすくなる。アップグレードの過程について詳細なフィードバックがあり、単一の問題の最小再現に収めるのが難しい場合も歓迎する。ソーシャルフォーラムのほか、サポートページに届いたメッセージも常に確認している。

アップグレードがうまくいきますように。SDK 56 を楽しんでほしい！