【ITニュース解説】React Native Version Matrix: The Hidden Upgrade Path

React Nativeは、一つのコードベースでiOSとAndroidの両方に対応するモバイルアプリを開発できる便利なツールだ。しかし、そのバージョンアップは、一見すると単純な作業に見えても、実は非常に複雑で困難な場合がある。この記事は、その複雑さの背景にある理由と、システムエンジニアを目指す上で知っておくべき重要な教訓を解説している。

ある企業がReact Nativeで開発したアプリが、4年もの間バージョンアップされずに放置され、App StoreやGoogle Playストアからの削除危機に瀕した事例が紹介されている。このアプリは2019年8月にリリースされたReact Native 0.61という古いバージョンで動いており、2023年の時点ではまさに「博物館の展示品」のような状態だったという。調査の結果、多くの関連ライブラリも時代遅れで、開発チームはモバイルアプリ開発の経験も不足していたため、結局はアプリの「完全な書き換え」という決断を下さざるを得なかった。もし定期的なメンテナンスが行われていれば、数週間の軽い作業で防げたはずの危機が、外部の専門家の助けを借りて数週間かかる大規模な再構築へと発展してしまったのだ。

この状況を説明するために、「アップグレード難易度 = （バージョン間の隔たり × アーキテクチャ変更） × 依存関係の劣化率」という計算式が提示されている。この式で30点を超えると「書き換え」の候補とされ、前述のアプリは47点という高いスコアを記録した。これはもはやアップグレードではなく、「考古学的な発掘作業」に等しいと筆者は表現している。筆者は過去7年間で12の企業アプリのReact Native移行を経験し、バージョンアップが単純な線形的な進行ではないことを発見したという。むしろ、バージョン間で複雑に絡み合う依存関係の網をnavigするようなもので、安易なバージョン飛ばしが予期せぬ連鎖的な障害を引き起こすことがある。

React Nativeの各リリースには「破壊点」が存在する。これらは「改善」と称されることが多いが、実際には既存のコードだけでなく、アプリを取り巻くエコシステム全体を破壊するような変更をもたらす。例えば、「AndroidXへ移行」という変更は、一見簡単そうに聞こえる。しかし実際には、Android関連のすべての依存ライブラリがこの変更に対応する必要が生じ、アプリのビルド時間が倍増したり、コンパイルは成功しても実行時に予期せぬエラーが発生したりすることがある。また、「新しいアーキテクチャが利用可能に」という変更は、異なる二つのアーキテクチャが同時にアプリ内で動作することを意味し、以前は簡単なJavaコードで済んだモジュールがC++の専門知識を必要としたり、アニメーションの動作に影響を与えたりした。さらに、「パッケージが@react-nativeスコープへ移動」という変更は、コードベース内のすべてのインポート文を壊し、その移動パターンも予測できないため、修正に多大な労力を要したという。

企業規模のReact Nativeアプリでは、これらの破壊的な変更が複雑なコードベース全体にどのように波及するかが明らかになる。単なるルーチンワークに見えるバージョンアップが、以下のような複数週間にわたる緊急プロジェクトへと変わるのだ。ライブラリの移行と互換性テスト（3〜5日）、ドキュメントの少ないアーキテクチャの書き換え（5〜7日）、ビルド設定の現代化（2〜3日）、プラットフォーム固有の競合解決と専門知識の投入（1〜2日）、難解なネイティブエラーを伴う依存関係のデバッグ（3〜4日）。一つの問題を解決すると、さらに二つの問題が表面化するという連鎖反応が起きる。あるライブラリを更新するとアップロード機能が壊れ、ナビゲーションを直すとディープリンクが機能しなくなる。それぞれの依存関係が、さらに独自の互換性要件を持つ下位の依存関係のエコシステムに影響を及ぼす。結果として、ステークホルダーに対し「簡単なアップデート」がなぜ機能開発の停止期間になったのかを説明することになり、アプリは指数関数的に技術的負債を蓄積していくことになる。

筆者が7年間にわたる12のエンタープライズ移行プロジェクトを通じて発見した、React Nativeのバージョンアップを規定する「四つの不変のルール」がある。一つ目のルールは「壁は動かない」である。AndroidXへの移行はReact Native 0.60で、新しいアーキテクチャへの移行は0.68〜0.70で、パッケージの再編成は0.72で発生した。これらはReact Nativeの歴史における「地層」のようなもので、プラットフォームの動作方法における根本的な変化を示している。これらの「壁」を避けて通ることはできず、必ず乗り越える必要がある。二つ目のルールは「時間は全てを複雑にする」である。開発から1ヶ月しか経っていないアプリのアップデートは2時間で済むかもしれないが、1年経ったアプリは2週間、1年半経ったアプリは2ヶ月を要する。これは指数関数的に作業量が増えることを意味する。なぜなら、依存関係は分岐し、ライブラリは開発が放棄され、破壊的変更は積み重なり、段階的な修正では対応できなくなるからだ。三つ目のルールは「依存関係が運命を決定する」である。アプリのアップグレードパスは、React Native自体よりも、最も更新の遅い依存ライブラリによって決まる。もし、React Native 0.58に固定された古いカメラライブラリを使っているなら、たとえそれ以外の部分を最新に保とうとしても、アプリ全体が0.58のアプリとして扱われることになる。一つの放棄されたパッケージが、アプリ全体を古いバージョンに縛り付けてしまうのだ。四つ目のルールは「位置が難易度を決定する」である。特定のReact Nativeバージョンには12〜18ヶ月の安定期間があり、この間はルーチン的なメンテナンスでアップデートが可能だ。しかし、別のバージョンにいると、全ての変更がアーキテクチャの決定に連鎖し、常にアップデートサイクルに巻き込まれることになる。賢明なチームは、主要な「壁」を越えた直後の安定したゾーンにアプリを配置し、次の安定ゾーンが現れるまでそのバージョンに留まる戦略をとる。

このように、すべてのReact Nativeアプリは、バージョンマトリックス上の特定の座標に位置している。この位置が、現在の安定性だけでなく、将来のアップグレードパスや依存関係の決定の複雑さを決定する。一般的なアップグレードガイドは段階的な更新を推奨するが、筆者は時にはクリーンな書き換えが、数年分の技術的負債のギャップを埋めるよりも早く安全だと主張する。前述のBluecrew社の事例が、その好例だった。彼らの完全な再構築は、複数のバージョンの壁を越える「段階的な」移行を試みるよりも少ない時間で完了したのだ。

この連鎖的な影響はランダムではなく、予測可能なパターンに従う。これらのパターンを理解することが、日々のルーチンメンテナンスと、開発サイクル全体とチームの信頼を消費する緊急プロジェクトとの分かれ道となる。現在「安定している」と信じているReact Nativeアプリも、開発が放棄されたnpmパッケージや非推奨のAndroid API、そしてもう会社にいない開発者によって書かれたネイティブコードの上に成り立っている可能性がある。待てば待つほど、その基盤は少しずつ崩れていくのだ。

React Nativeのエコシステムは、4つの予測可能な「破壊点」であるバージョン間の「壁」で分断される。これらの壁では、エコシステム全体が崩壊し、単純なアップデートではなく、完全な移行戦略が必要となる。これらの壁は動かない「地層」であり、すべてのアプリはいずれこれらを越えなければならない。この解説文はシリーズのパート1であり、パート2以降では各「壁」について、何が壊れ、なぜ壊れ、どのような技術的判断が移行期間に影響するかを詳細に解説するとのことだ。これらの壁と、それに伴う失敗パターン、移行要件を理解することで、アプリを戦略的に配置し、ビジネスの現実と整合したアップグレード計画を立てることが可能になる。多くのチームがこの事実を緊急の週末デプロイメントで、あるいはステークホルダーに「簡単なアップデート」がなぜ数ヶ月かかるプロジェクトになったのかを説明する中で、困難な方法で学ぶことになるが、そうする必要はないと筆者は結論付けている。