本日、React Native 0.82をリリースできることを嬉しく思います。これは完全にNew Architectureで動作する初のReact Nativeです。これはReact Nativeにとってマイルストーンとなるリリースであり、新時代の始まりだと信じています。今後のバージョンでは、インストールサイズを削減し、コードベースを合理化するために、Legacy Architectureの残りのコードを削除していく予定です。さらに、0.82では、Hermes V1と呼ばれる新しいバージョンのHermesへの実験的なオプトインも提供されます。また、Reactのバージョンを19.1.1に更新することで複数のReact機能を有効にし、DOM Node APIのサポートも提供します。
ハイライト
- New Architectureのみ
- 実験的なHermes V1
- React 19.1.1
- DOM Node APIs
New Architectureのみ
React Native 0.76では、New ArchitectureがReact Nativeのデフォルトアーキテクチャになったことを発表しました。それ以来、New Architectureはテストと改良が重ねられ、このバージョンと今後のバージョンのReact Nativeで唯一のアーキテクチャにすることに確信を持っています。
これは、AndroidでnewArchEnabled=falseを設定しようとしても、またはiOSでRCT_NEW_ARCH_ENABLED=0でCocoaPodsをインストールしようとしても、これらは無視され、アプリは依然としてNew Architectureを使用して実行されることを意味します。
移行方法
プロジェクトをNew Architectureに移行していない場合は、まずプロジェクトをReact Native 0.81またはExpo SDK 54に移行することをお勧めします。これらはLegacy Architectureの使用を許可する最後のバージョンです。これらには、New Architectureへの移行を支援するための警告とパフォーマンス改善が特別に含まれています。
次に、0.81でNew Architectureを有効にし、アプリケーションが正常に動作することを確認してください。0.81でNew Architectureを使用している場合は、Legacy Architectureの有効化を防ぐReact Native 0.82に安全に更新できます。
互換性のないサードパーティの依存関係がNew Architectureへの移行を妨げている場合は、ライブラリのメンテナーに直接連絡することをお勧めします。React Nativeコアのバグが移行を妨げている場合は、issue trackerを通じてご連絡ください。
Interop Layersとサードパーティライブラリの互換性
Interop layersは当面の間、コードベースに保持されます。Interop layersで必要なすべてのクラスと関数は、すぐには削除されません。Interop Layersの削除に関する詳細な更新は今後共有します。
また、両方のアーキテクチャとの後方互換性を提供するサードパーティライブラリは、New Architectureが唯一のアーキテクチャである0.82でも引き続き動作することを確認しています。
Legacy Architectureクラスの削除
後方互換性を確保し、破壊的変更を減らすため、このバージョンではReact NativeのコアからLegacy ArchitectureのAPIを削除していません。Legacy Architectureの削除により、全体的なバンドルサイズを大幅に節約できるため、削除はReact Nativeの次のバージョンから開始される予定です。
詳細については、RFC0929: Removal of the Legacy Architecture of React Nativeをご覧ください。
実験的なHermes V1
React Native 0.82では、Hermes V1へのオプトインサポートが追加されました。Hermes V1はHermesの次の進化です。私たちは内部的にアプリでそれを実験してきており、今度はコミュニティにも試してもらう時が来ました。
コンパイラとVMの改善により、Hermesのパフォーマンスが向上します。初期のテストとベンチマークから、Hermes V1は様々なシナリオで現在のHermesを上回る性能を示しています。バンドル読み込みとTTIの改善が見られました。改善は、アプリの詳細に大きく依存します。
実世界の複雑なアプリケーションであるExpensifyアプリでは、以下の改善が見られました：
| メトリック | Android（ローエンドデバイス） | iOS |
|---|
| Bundle Load Time | 3.2%高速 | 9%高速 |
| Total TTI | 7.6%高速 | 2.5%高速 |
| Content TTI | 7.2%高速 | 7.5%高速 |
Total TTIでは、バンドル読み込みからアプリの最初の画面がレンダリングされ、インタラクティブになるまでの時間を測定しました。Content TTIでは、コンポーネント自体の最初のレンダリングから、コンポーネントがインタラクティブになるまでの時間を測定しました。
Hermes V1には、JS-to-nativeコンパイル（以前は「Static Hermes」として知られていた）やReact Native EU 2023で発表されたJITコンパイルはまだ含まれていません。これらの機能はまだテスト中であり、進展があり次第共有します。
Hermes V1の有効化方法
info
Hermes V1が実験段階にある間は、それを試すためにReact Nativeをソースからビルドする必要があります。Hermes V1が将来のReact Nativeバージョンでデフォルトとして出荷されると、この制限は解除されます。
自分のプロジェクトでHermes V1を試すには、以下の手順を使用してください：
package.jsonファイルの対応するセクションを変更して、パッケージマネージャーにHermes V1コンパイラパッケージの実験バージョンを解決するよう強制します（現在のバージョニング規則はHermes V1の実験段階のみのものです）：
yarn
"resolutions": {
"hermes-compiler": "250829098.0.1"
}
npm
"overrides": {
"hermes-compiler": "250829098.0.1"
}
android/gradle.properties内にhermesV1Enabled=trueを追加してAndroid用のHermes V1を有効にします：
hermesV1Enabled=true
android/settings.gradleを編集してReact Nativeをソースからビルドするよう設定します：
includeBuild('../node_modules/react-native') {
dependencySubstitution {
substitute(module("com.facebook.react:react-android")).using(project(":packages:react-native:ReactAndroid"))
substitute(module("com.facebook.react:react-native")).using(project(":packages:react-native:ReactAndroid"))
substitute(project(":packages:react-native:ReactAndroid:hermes-engine")).using(module("com.facebook.hermes:hermes-android:250829098.0.1"))
}
}
RCT_HERMES_V1_ENABLED=1環境変数でpodsをインストールしてiOS用のHermes V1を有効にします：
RCT_HERMES_V1_ENABLED=1 bundle exec pod install
Hermes V1はプリコンパイルされたReact Nativeビルドと互換性がないため、podsをインストールする際にRCT_USE_PREBUILT_RNCOREフラグを使用しないでください。
アプリがHermes V1を実行していることを確認するには、アプリまたはDevToolsコンソール内で以下のコードを実行してください。このコードはHermesのバージョンを返し、ステップ1で指定したバージョン（250829098.0.1）と一致するはずです：
HermesInternal.getRuntimeProperties()['OSS Release Version'];
React 19.1.1
このReact Nativeのリリースには、最新のReact安定版であるReact 19.1.1が含まれています。このReactのリリースには、React Native用のowner stacksの完全サポートが含まれています。
React Native 0.80で19.1.0のサポートを出荷した際、@babel/plugin-transform-function-name Babelプラグインを使用している場合、owner stacksが完全にサポートされていないと述べました。このリリースではこの制限が解除され、すべてのReact Nativeユーザーでowner stacksが有効になります。
BEFORE → AFTER
React 19.1.1はまた、React NativeでのSuspense境界内でのuseDeferredValueとstartTransitionの信頼性も向上させます。これらはアプリの応答性を向上させるために設計された重要なReact機能です。以前は、React NativeでSuspense境界と一緒に使用すると、両方とも誤ってfallbackコンポーネントを表示していました。React 19.1.1では、React Native上で期待通りに一貫して動作し、Webでの動作と一致します。
DOM Node APIs
React Native 0.82から、ネイティブコンポーネントはrefs経由でDOM風のノードを提供します。以前は、ネイティブコンポーネントはmeasureやsetNativePropsなどの少数のメソッドのみを持つReact Native固有のオブジェクトを提供していました。このリリース後は、UIツリーの走査、レイアウトの測定など、Web上と同様にDOM APIのサブセットを実装するノードを提供します。
例：
function MyComponent(props) {
const ref = useRef();
useEffect(() => {
const element = ref.current;
element.parentNode;
element.parentElement;
element.childNodes;
element.children;
const bounds = element.getBoundingClientRect();
const doc = element.ownerDocument;
const maybeElement = doc.getElementById('some-view');
element.measure((x, y, width, height, pageX, pageY) => {
});
}, []);
return <View ref={ref} />;
}
さらに、これによりリーフテキストノード（Textコンポーネントによって作成される）とReact Nativeルートノードを表すドキュメントノードへのアクセスが公開されます。
新しいノードは引き続きレガシーメソッド（measureなど）を実装するため、これは後方互換性のある変更です。
詳細については、ドキュメントをご確認ください。
その他の変更
Web Performance APIs（Canary）
React NativeはWeb上で利用可能なperformance APIのサブセットを実装するようになりました：
- High Resolution Time:
performance.now()とperformance.timeOriginを定義
- Performance Timeline:
PerformanceObserverとperformanceオブジェクトのパフォーマンスエントリにアクセスするメソッド（getEntries()、getEntriesByType()、getEntriesByName()）を定義
- User Timing:
performance.markとperformance.measureを定義
- Event Timing API:
PerformanceObserverに報告されるイベントエントリタイプを定義
- Long Tasks API:
PerformanceObserverに報告されるlongtaskエントリタイプを定義
これらにより、実行時にアプリのパフォーマンスの様々な側面を追跡（テレメトリ用）でき、React Native DevToolsのパフォーマンスパネルで表示されます（React Nativeの将来のバージョンで利用可能）。
現在はcanary release levelでのみ利用可能で、React Nativeの将来のバージョンで安定版としてリリースされます。
Android用最適化デバッグビルドタイプ
React Native 0.82から、開発体験を高速化するためにdebugOptimizedビルドタイプを使用できるようになります。
従来、Androidは2つのデフォルトビルドバリアントを作成していました：
- debug: 開発時にデフォルトで使用され、React Native DevTools、Metro、Android JVM、C++デバッガーなどの様々なデバッガーツールに接続可能
- release: アプリケーションを本番環境に出荷する際に使用。完全に最適化され、難読化と最適化によりデバッグが困難
ほとんどのReact Native開発者は開発時にC++デバッガーを必要としないため、debugOptimizedビルドタイプを導入しました。debugOptimizedでは、複数のC++最適化が有効になったReact Nativeビルドを実行するため、アニメーションと再レンダリングが高速になります。同時に、JavaScriptコードをデバッグするためにReact Native Dev Toolsを引き続き使用できます。
debugOptimizedを使用する場合、C++ネイティブデバッガーは使用できませんが、debugビルドタイプを使用すれば引き続き使用できます。
アプリのdebugOptimizedバリアントを実行するには、以下を実行できます：
Community CLI
npx react-native run-android --mode debugOptimized
Expo
npx expo run:android --variant debugOptimized
info
debugOptimizedビルドタイプはReact Native 0.81とExpo SDK 54にもバックポートされています。
複数のアニメーションを画面上でレンダリングするこれらのサンプルで、debugOptimizedの動作を確認できます。debugビルドは約20FPSで実行されているのに対し、debugOptimizedは約60FPSで実行されています：
debug → debugOptimized
破壊的変更
キャッチされていないpromise rejectionがconsole.errorを発生させるようになりました
前のバージョンでキャッチされていないJavaScriptエラーの報告が改善されたことに続き、キャッチされていないpromiseもそのメカニズムを通じて報告されるようになります：
バグにより、これらは以前は完全に飲み込まれて無視されていたため、React Native 0.81にアップグレード後に既存のエラーが表面化することを予期してください。そのため、以前から存在していたエラーがバックエンドに報告されるJavaScriptエラーにも表面化し、新しいレポートの急増を引き起こす可能性があります。
その他の破壊的変更
全般
- ReactNativeFeatureFlagsをsrc/privateに移動: 一般的に、ReactNativeFeatureFlagsはプライベートAPIであるため、まったく依存すべきではありません。
- Appearance.setColorScheme()の型が更新され、null値を受け入れなくなりました: カラースキームをリセットする必要がある稀なケースでは、null/undefinedの代わりに'unspecified'を使用してください。
iOS