Expo SDK 53の変更点とアップグレード手順|New Architecture既定化とexpo-avの非推奨化

Expo SDK 53の変更点とアップグレード手順|New Architecture既定化とexpo-avの非推奨化

Expo SDK 53は2025年4月30日に公開され、React Native 0.79とReact 19を同梱します。SDK 52までと比べて破壊的な変更が多く、New Architectureの既定有効化、Metroのpackage.json exports対応、Androidのedge-to-edge、expo-avの非推奨という4点が、移行時に確認する主な変更です。このページでは、SDK 53で実際に何が変わったのか、SDK 52からどう上げるのか、そして2026年9月時点でSDK 53に留まっている場合に何が効いてくるのかを、公式チェンジログと設定スキーマの実測値だけでまとめます。なおSDK 56の変更点についてはExpo SDK 56の新機能と変更点まとめ|React Native 0.85対応・SDK 55からのアップグレード手順を参照してください。

まとめ:Expo SDK 53の要点

  • SDK 53は2025年4月30日公開・React Native 0.79 / React 19です。確認したnpmのsdk-53タグは53.0.27を指しています。
  • New Architectureが全プロジェクトで既定有効になりました。SDK 53と54ではnewArchEnabledで無効化できますが、この設定はSDK 55の設定スキーマから削除済みです。無効化に頼った移行は54で行き止まりになります。
  • Metroでpackage.jsonexportsが既定有効になりました。ライブラリ側が未対応だと解決に失敗するため、unstable_enablePackageExports: falseで一時退避できます。
  • Androidのedge-to-edgeはExpo Go・新規プロジェクト・既存プロジェクトで挙動が3分岐します。既存プロジェクトだけは既定で無効です。
  • expo-avは非推奨になりexpo-audioへ移行します。expo-background-fetchexpo-background-taskへ置き換わりました。
  • アップグレードはnpx expo install expo@^53.0.0 --fixで行います。旧来のexpo upgradeコマンドは現行のExpo CLIに存在しません
  • 2026年9月21日時点の最新SDKは57(RN 0.86)です。SDK 53は対応する旧版のExpo Goを入手できるAndroid実機・エミュレーターとiOS Simulatorで実行できます。iOS実機でSDK 53を使い続ける場合は、開発ビルドを使用してください。

Expo SDK 53の位置づけと、SDK 57までの距離

SDK 53は2025年4月30日の公開で、2026年9月21日時点ではSDK 57が最新です。SDK 53から見ると4世代分の差があります。各SDKが同梱するReact Nativeの版と、SDK 53から上げていくときに効く要点は次のとおりです。

SDK 公開日 React Native React SDK 53から見た要点
53 2025-04-30 0.79 19 New Arch既定化・exports既定化
54 2025-09-10 0.81 19.1 Legacy Arch対応の最終版
55 2026-02-25 0.83 19.2 Legacy Arch廃止・設定キー削除
56 2026-05-21 0.85 19.2 Hermes v1のメモリ回帰(57で解消)
57 2026-06-30 0.86 19.2 現行の最新SDK

公式のアップグレード手順は「一度に1世代ずつ上げる」ことを推奨しています。同じページには、Expo Goについて「it only supports the latest SDK version and previous versions are no longer supported」と書かれています。ただし旧版Expo Goの入手方法を案内するページによれば、Android実機・エミュレーターとiOS Simulatorであれば、expo.dev/go かexpo-go CLIでSDK 53対応の旧版を入れて開けます。制約が出るのはiOS実機で、「For projects using SDK 53 or earlier, you cannot install an older version of Expo Go on a physical iOS device」と明記されているため開発ビルドが必要です。Expo Goと開発ビルドの違いはExpo(React Native)とは?Expo Go・開発ビルド・EASの役割と採用判断を実装目線で解説【2026年版】で扱っています。

New Architectureの既定有効化とオプトアウトの期限

SDK 53のチェンジログは「In SDK 53, the New Architecture is enabled by default in all projects」と明記しています。FabricとTurboModulesを使う構成が全プロジェクトの既定になったということです。既定化の根拠として、2025年4月にEAS BuildでビルドされたSDK 52プロジェクトの74.6%が既にNew Architectureを有効にしていたと公表されています。SDK 54の時点では、SDK 53プロジェクトの75%という数字に更新されました。

すぐに移行できない場合は、app.jsonでプラットフォーム単位または全体で無効化できます。

{
  "expo": {
    "newArchEnabled": false,
    "android": { "newArchEnabled": false },
    "ios": { "newArchEnabled": false }
  }
}

ただしこの逃げ道には期限があります。SDK 54のリリースノートは「SDK 54 is the final release to include Legacy Architecture support」と宣言し、SDK 55では「the newArchEnabled config option has been removed from app.json」と書かれました。実際にExpoの設定スキーマAPIで各版を取得すると、53.0.0と54.0.0にはnewArchEnabledの定義がありますが、55.0.0では出現数が0です。SDK 55以降はNew Architecture専用なので、SDK 53で無効化したまま止めているプロジェクトは、54までしか進めません。New Architecture自体の構造はReact Nativeとは?仕組みとNew Architectureの構造・採用判断を実装目線で解説【2026年版】で解説しています。

ライブラリ側も新アーキテクチャ専用へ寄っています。たとえばReanimatedはv4でNew Architectureのみの対応になりました(React Native Reanimatedとは?UIスレッド駆動の仕組みと4系の版の縛り【2026年8月時点】)。

Metroのpackage.json exports既定有効化と解決エラー対策

React Native 0.79でMetroのpackage.jsonexports対応が既定で有効になりました。この機能自体はReact Native 0.72から使えましたが、SDK 53で既定になったため、未対応のライブラリを含むプロジェクトはアップグレード直後に解決エラーが出ます。チェンジログは、Node標準ライブラリをインポートしようとした旨のエラーが出る例と、@supabase/supabase-js@firebase/*で既知の問題があることを挙げています。

切り分けのため、metro.config.jsで一時的に無効化できます。

const { getDefaultConfig } = require('expo/metro-config');

const config = getDefaultConfig(__dirname);
config.resolver.unstable_enablePackageExports = false;

module.exports = config;

無効化はあくまで一時退避です。エラーが出ないのに挙動がおかしい場合は、同じライブラリのESM版とCommonJS版が二重に読み込まれる「dual package hazard」を疑ってください。状態を持つライブラリだと、別々の状態を持つ2つのコピーが同時に存在することになります。バンドルの中身はEXPO_ATLAS=1 npx expoで起動するExpo Atlasで確認できます。SDK 53でAtlasは試験的機能から安定版へ昇格しました。

Androidのedge-to-edge既定値と実行環境別の違い

SDK 53のAndroidでは、edge-to-edge表示の既定値が実行環境ごとに違います。チェンジログの記述は次の3点です。

  • Expo Goでは既定で有効、オプトアウト不可です。
  • 新規プロジェクトでは既定で有効、Expo Go以外ではオプトアウトできます。
  • 既存プロジェクトではExpo Go以外で既定は無効、オプトインできます。

つまり「Expo Goでは画面がシステムバーの下まで伸びるのに、ビルドしたアプリでは伸びない」という食い違いは、SDK 53では仕様どおりです。既存プロジェクトで有効化するには、app.jsonに次のキーを置きます。

{
  "expo": {
    "android": { "edgeToEdgeEnabled": true }
  }
}

SDK 53の設定スキーマでは、このキーの説明は「Default to false」で、既定値もfalseです。SDK 54でedge-to-edgeは常時有効になり、SDK 55の設定スキーマからはedgeToEdgeEnabled自体が消えていますnewArchEnabledと同じく出現数0)。背景には、Android 16(API 36)を対象とし、Android 16端末で動作するアプリではedge-to-edgeを拒否できなくなるというGoogle側の変更があります。SDK 53はその移行期にあたるため、既定値がこのように割れました。なおSDK 53では、新規Androidプロジェクトの既定テーマもDayNightへ変更されています。

expo-avの非推奨とexpo-audioへの移行

SDK 52で映像側がexpo-videoに置き換わったのに続き、SDK 53で音声側がexpo-audioの安定版に置き換わりました。チェンジログはexpo-avについて「The expo-av package will no longer be maintained and we will not publish any new versions for SDK 54 and beyond」と書いています。ただしnpmの公開履歴を見ると、この予告どおりにはなりませんでした。SDK 54向けの16.0.0が2025年8月13日に公開され、16.0.8(2025年12月5日)まで更新が続いています。告知の文面ではなく、実際にどの版まで出ているかで判断してください。

移行は、Audio.Soundを組み立てる書き方から、フック中心の書き方へ変わります。次の例はexpo-audioをインストールし、assetsディレクトリにbeep.mp3を配置したプロジェクトで使用します。

import { useAudioPlayer } from 'expo-audio';
import { Button } from 'react-native';

export default function Player() {
  const player = useAudioPlayer(require('./assets/beep.mp3'));
  return <Button title="再生" onPress={() => player.play()} />;
}

削除時期の告知は版をまたいで表現が変わっている点に注意してください。SDK 54のリリースノートは「expo-av will be removed in SDK 55」と予告しましたが、SDK 55の実際の記述は「expo-av was removed from Expo Go because it has been replaced by expo-video and expo-audio. Additionally, expo-av is no longer receiving patches and may not continue working in your apps as a result」です。パッケージがnpmから消えたのではなく、Expo Goから外れて保守が止まったという書き方です。ただしSDKに同梱されるモジュールの一覧を実際に取得すると、expo-avはSDK 53と54には含まれ、SDK 55以降の一覧からは消えています。バージョン整合の対象から外れた以上、npx expo install --fixで版を合わせてもらうこともできません。移行は先送りしない方が安全です。

expo-background-taskへの移行と実行間隔の制約

バックグラウンド処理はexpo-background-taskに置き換わり、expo-background-fetchは非推奨になりました。新モジュールはAndroidでWorkManager、iOSでBGTaskSchedulerを使います。どちらもOS側が実行タイミングを決める仕組みなので、登録した間隔どおりに走るとは限りません。

import * as BackgroundTask from 'expo-background-task';
import * as TaskManager from 'expo-task-manager';

TaskManager.defineTask('sync-task', async () => {
  console.log('sync-task: 動作確認用のタスクを実行しました');
  return BackgroundTask.BackgroundTaskResult.Success;
});

BackgroundTask.registerTaskAsync('sync-task', {
  minimumInterval: 30,
}).catch(console.error);

公式リファレンスによるとminimumIntervalの単位は分で、既定は12時間に1回、最小間隔は15分です。15分より短い値を渡しても縮まりません。もう一点、複数のJavaScriptタスクを定義しても「Expo Background Task uses a single worker on both platforms」と明記されているとおり、実行は単一のワーカーにまとめられます。開発モードではtriggerTaskWorkerForTestingAsyncで登録済みタスクの動作確認ができます。本番ビルドでは使用できず、iOSでは実機が必要です。

SDK 52からSDK 53へのアップグレード手順

まず前提の確認です。旧来の記事や社内手順書に残っているexpo upgradeexpo initは、現行のExpo CLIには存在しません。公式リファレンスが載せているnpx expo -hの出力は「start, export / run:ios, run:android, prebuild / install, customize, config / login, logout, whoami, register」で、upgradeinitも含まれていません。アップグレードはinstall--fixを付けて行います。

npm i -g eas-cli
npx expo install expo@^53.0.0 --fix
npx expo-doctor@latest

CNGを使用し、ネイティブ側の変更をapp configやConfig Pluginから再生成できる場合は、旧SDKで生成したandroid・iosディレクトリを削除して再生成します。手動でネイティブコードを管理している場合は削除せず、Native project upgrade helperの差分を適用し、iOSではnpx pod-installを実行してください。次のコマンド例はCNGを使用する場合です。

npx expo prebuild
npx pod-install
npx expo run:ios

合わせて次の4点を確認してください。1点目はNode.jsです。SDK 53のチェンジログは、Node 18が2025年4月30日にEOLを迎えたことを受けて「We recommend you use at least Node 20 for SDK 53 projects」としていました。ただしそのNode 20も2026年4月30日にEOLを迎えているため、いま作業するならサポート中のLTSを選んだうえで依存関係との互換性を確かめてください。2点目はXcodeです。SDK 53公開時の案内では、iOSのビルドにXcode 16、推奨は16.2以降とされていました。ただし2026年4月28日以降にApp Store Connectへアップロードするアプリは、Xcode 26以降でのビルドが必須です。SDK 53のままEAS Buildで提出するにはeas.jsonで"image": "macos-sequoia-15.6-xcode-26.2"のように明示する必要があり、Expo自身も「not all SDK versions will be compatible with Xcode 26」「We recommend upgrading to at least SDK 54」と書いています。SDK 53に留まったままのストア提出は、この時点で条件付きになっています。3点目はlockfileです。EAS BuildはSDK 53以降のプロジェクトでlockfileを凍結した状態でインストールする挙動が既定になったため、lockfileが古いままだとビルドが失敗します。4点目はpackage.jsonのoverridesやresolutionsです。多くのライブラリがReact 18をpeer dependencyに指定しているため、Reactが二重にインストールされて実行時エラーになることがあります。

expo-updatesのfallbackToCacheTimeoutの既定値と起動待ち時間

OTA更新の挙動で最初に見る設定がupdates.fallbackToCacheTimeoutです。設定スキーマの説明は「How long (in ms) to wait for the app to check for and fetch a new update upon launch before falling back to the most recent update already present on the device. Defaults to 0. Must be between 0 and 300000 (5 minutes)」となっています。

{
  "expo": {
    "updates": {
      "url": "https://u.expo.dev/your-project-id",
      "fallbackToCacheTimeout": 3000
    }
  }
}

既定の0は「起動時に更新の取得を待たない」という意味です。この場合、起動中にダウンロードされた更新は次回起動時に適用されます。値を延ばすと、指定時間内に更新の確認とダウンロードが完了した場合に、その起動で更新を適用できます。ただし通信状態などに左右されるため、当日中の適用は保証されず、起動時の待ち時間も増える可能性があります。指定できる上限は300000ミリ秒(5分)です。このキーはSDK 53だけのものではなく、SDK 55の設定スキーマにも同じ定義が残っています。newArchEnablededgeToEdgeEnabledのように消えた設定ではないため、上位SDKへ移行しても書き換えは不要です。

SDK 53ではexpo-updates側にも変更がありました。実行時にヘッダを差し替えるUpdates.setUpdateURLAndRequestHeadersOverride()が追加され、Androidでは起動時に埋め込みアセットをコピーしなくなりました。後者について、テストプロジェクトでは起動処理が約300ミリ秒から約100ミリ秒に短縮されたと報告されています。問題が出た場合はEX_UPDATES_COPY_EMBEDDED_ASSETS=trueで以前の挙動に戻せます。

よくある質問

SDK 53のプロジェクトをExpo Goで開けますか?

Android実機・エミュレーターとiOS Simulatorでは、SDK 53対応の旧版Expo Goで開けます。公式のアップグレード手順が「it only supports the latest SDK version and previous versions are no longer supported」と書いているとおり、サポート方針と旧版の入手可否は区別する必要があります。SDK 53対応の旧版を新たにインストールできないiOS実機では、SDK 53のプロジェクトは開発ビルドを作って動かしてください。

New Architectureを無効にしたままSDKを上げ続けられますか?

SDK 54までです。SDK 54のリリースノートが「SDK 54 is the final release to include Legacy Architecture support」と明記し、SDK 55ではnewArchEnabledがapp.jsonから削除されました。設定スキーマを実際に取得しても、55.0.0にはこのキーの定義がありません。

expo-avはもう使えないのですか?

SDK 53と54では使えますが、保守は止まりました。SDK 53のチェンジログは「SDK 54以降は新しい版を公開しない」と予告していましたが、実際にはSDK 54向けの16.0.0が2025年8月13日に公開され、16.0.8(2025年12月5日)まで更新が続いています。その16.0.8がnpmのlatestが指す最後の安定版で、SDK 55以降は同梱モジュールの一覧から外れました。音声はexpo-audio、映像はexpo-videoへ移行してください。

expo upgradeコマンドが見つからないのはなぜですか?

現行のExpo CLIにそのコマンドが無いためです。公式リファレンスが掲載するnpx expo -hの出力にも含まれていません。npx expo install expo@^53.0.0 --fixで依存関係をSDK 53向けに揃えたあと、npx expo-doctor@latestで不整合を確認する流れになります。

アップグレード後にモジュールが解決できないエラーが出るのはなぜですか?

Metroのpackage.json exports対応が原因である可能性が高いです。metro.config.jsでconfig.resolver.unstable_enablePackageExports = falseを設定してエラーが消えるなら、依存ライブラリ側が未対応です。恒久対応としてはライブラリの更新を待つか、対応済みの版へ上げてください。

関連記事

資料請求

RELATED POSTS 関連記事