「Project is incompatible with this version of Expo Go」と出たとき、プロジェクトを疑う前に見る三か所

QR コードを読み込んだ直後、Expo Go の画面に英語の二行が出ました。「Project is incompatible with this version of Expo Go」、そして「This project requires a newer version of Expo Go」です。

新しいバージョンが必要だと言われても、アプリは入れたばかりでした。私は自分のプロジェクトのほうが壊れたのだと思い込み、node_modules を消して入れ直し、キャッシュを消して再起動し、それでも同じ画面を見て、ようやく手を止めました。

あとから気づいたのは、このメッセージが「壊れている」と言っているわけではない、ということです。「合わなかった」と言っているだけで、どちらが合っていないのかは教えてくれません。 そこで私は、手を動かす前に照合先を三つに分けて確かめる順番にしています。

このメッセージは、三つの数字の照合結果です

Expo Go は、開こうとしたプロジェクトが名乗る SDK のバージョンと、自分が対応している SDK のバージョンを突き合わせています。一致しなければ、冒頭の画面を出して止まります。

つまり疑う場所は、プロジェクトだけではありません。Expo Go のアプリ側にも、ビルドの取り違えという原因がありえます。

一と二は、名前を見れば誰でも確かめられます。三は少し珍しい話ですが、2026 年の夏に実際に起きたことなので、後半で触れます。

一つめ：プロジェクトの SDK を、数字で確かめます

最初に、自分のプロジェクトが何を名乗っているのかを数字にします。Rork から書き出した Expo プロジェクトでも、手元で作ったものでも、見る場所は同じです。

# プロジェクトのルートで実行します
grep -E '"(expo|react-native)"' package.json
 
# Expo が想定している版とのずれを一覧にします
npx expo install --check

一行目で、expo の版（たとえば ~56.0.11 なら SDK 56）と react-native の版が分かります。二行目は、SDK に対して合っていない依存を挙げてくれます。ここに赤い行が並ぶなら、Expo Go を疑う前にプロジェクトの側を直す番です。

数字をメモに一行残しておくのをおすすめします。次の手順で、Expo Go 側の数字と並べるためです。

// check-sdk.js — 手元のメモ代わりに置いている小さなスクリプトです
// 使い方: node check-sdk.js
const pkg = require('./package.json');
const dep = { ...pkg.dependencies, ...pkg.devDependencies };
 
const expo = dep.expo || '(expo が見つかりません)';
const major = String(expo).match(/(\d+)\./)?.[1] ?? '?';
 
console.log(`expo        : ${expo}`);
console.log(`SDK (推定)  : ${major}`);
console.log(`react-native: ${dep['react-native'] ?? '(未指定)'}`);
// ここで出た SDK の数字を、Expo Go の設定画面に出る
// 「Supported SDK」の数字と目で照らし合わせます。

「なぜこんな小さなスクリプトを」と思われるかもしれません。画面の英語を読みながら package.json を開き直すより、数字が三行で並んでいるほうが、比べる手が止まらないからです。

二つめ：Expo Go が何番までを受け付けるのかを見ます

次に、手元の Expo Go が対応している SDK を確かめます。アプリ内の設定画面に、対応する SDK の番号が表示されています。ある報告では、Play ストアから入れた版が「Supported SDK 54」のまま止まっていて、SDK 55 や 56 のプロジェクトが開けなかったという書き込みがありました。

ストアの版が最新の SDK に追いついていないことは、実際にあります。その場合は、Expo の公式ページ（expo.dev/go）で SDK のバージョンと端末の種類を選ぶと、その SDK に対応した版の入れ方が案内されます。

もう一つの対処は、プロジェクトの側を Expo Go が対応している SDK に合わせることです。ただし、SDK を下げる作業は依存関係に波及します。私は、プロジェクトを下げる前に Expo Go を入れ直すほうを、先に試すようにしています。戻しやすい操作を先に、戻しにくい操作を後に。 この線引きだけは、焦っているときほど守るようにしております。

三つめ：SDK は合っているのに弾かれる、Android の一件

一と二を確かめても合っているのに、同じ画面が出る場合があります。2026 年 6 月、GitHub の expo/expo に、まさにその報告が上がりました。

報告によると、Android 版の Expo Go 56.0.1 が、SDK 56 のプロジェクトをすべて弾いたのです。作りたての空のテンプレートでも同じでした。開発サーバーから読み込む場合も、EAS Update から読み込む場合も、どちらも失敗したと書かれています。

報告者は原因を丁寧に切り分けていました。プロジェクトが名乗る SDK は 56.0.0 で、サーバーの対応表も 56.0.1 のクライアントを受け付ける側のはずでした。そこで、手元のプロキシでマニフェストの値だけ 56.0.1 に書き換えたところ、プロジェクトは開いたといいます。逆に、一つ前の Expo Go 56.0.0 を入れると、書き換えなしでも開きました。

報告者の見立てでは、56.0.1 のクライアントが、プロジェクトの SDK 番号を自分のアプリの版の文字列と丸ごと比べていたようです。「SDK が同じ 56 なら通る」という比較ではなかったことになります。私が確かめたのは報告の記述までで、原因の特定は報告者の推測であることをお断りしておきます。

ここで効いた対処は、報告のコメントによれば二つでした。

この issue は 2026 年 10 月 26 日に閉じられました。SDK 56 に対応した Expo Go が公式ページで入手でき、6 月以降に新しい報告がなかったためと説明されています。いま同じ画面に出会ったなら、まず公式ページから入れ直すのが先です。

直感に反していたのは、「最新が一番安全」ではなかったことです

私はずっと、アプリは最新が一番安全だと考えていました。この件は逆でした。同じ SDK 56 の中でも、パッチ番号が一つ違うだけで、開けるプロジェクトと開けないプロジェクトが分かれたのです。

だからといって、いつも古い版を入れればよいわけではありません。教訓は、「最新に上げて直らなければ、一つ前を試す」という選択肢を持っておくことだと思います。

どうしても直らないとき

照合先を三つとも確かめて合っているなら、Expo Go をやめて、自分のアプリとして端末に入れる開発ビルドに切り替える手もあります。Expo Go は学習や試作のための砂場で、本番に近い構成を試すには向いていません。

iPhone の実機で確かめたいだけなら、Rork Companion の側から入るほうが近道になる場合もあります。繋がらないときの見方は、同じ Wi-Fi のはずなのにプレビューが出ないときにまとめています。QR は読めるのに開かないという別の症状でしたら、QR を読んだのに開かないときの確認順をご覧ください。

無料のままどこまで実機で試せるかが気になる方には、Companion の無料枠と Apple Developer の 99 ドルを払う時期も参考になるはずです。

次に同じ画面を見たときの、最初の三分

個人開発で更新を出す週は、手が急いで順番を飛ばしがちです。私自身、いまはこの画面に出会ったら、まず grep で SDK の数字を出し、次に Expo Go の設定画面を開き、最後に公式ページを開くところから始めます。node_modules を消すのは、そのあとです。

まずは手元の package.json に書かれた expo の数字を、メモに一行だけ書き残してみていただければと思います。その一行があるだけで、次に同じ画面が出たとき、迷う時間がはっきり短くなります。