- Shopifyは5年前、React Native（RN）をモバイル開発の未来と位置づけて以来、すべてのアプリをRNへと移行することに成功した
- React Native導入の主な理由
- 1回の実装で2つのプラットフォームをサポート: iOSとAndroidで同じ機能を2度開発する非効率をなくすため
- 人材の流動性向上: 開発者がiOS、Android、Webを自由に行き来しながら作業できるよう支援
- より多くの価値を提供: 機能同等性の確保にかかる時間を減らし、ユーザーにより多くの価値を届ける
- 移行の成功した結果
- 同じ機能を2度開発しなくてよくなり、生産性が大幅に向上した
- エンジニアがWebとモバイルの両方を扱えるようになり、同じ人員でより多くの作業をこなし、新たな成長機会を生み出した
- iOSとAndroid間の機能同等性維持が問題ではなくなり、より多くの価値を提供できるようになった
- アプリの画面読み込み時間は500ms以下と高速で、セッションの99.9%以上が安定して維持されている
- 作業に最も適したツールとしてネイティブコードも引き続き活用し、両方の世界の利点を享受している
主な学び
React Nativeアプリは速い
- Shopifyはパフォーマンスを非常に重視しており、CEOのTobi Lutkeは「すべての速いソフトウェアが素晴らしいわけではないが、すべての素晴らしいソフトウェアは速い」と強調している
- React Native（RN）へ移行する前、最大の問いはRNが性能目標を満たせるかどうかだった
- そのため、移行を決める前に広範なプロトタイピングを行い、実現可能かどうかを検証した
- Metaが性能ボトルネック解消のために進めている作業を確認し、リストのような領域で貢献できる部分を特定した
- RNはまもなくさらに高速になると判断し、全面的な導入を決定した
- 5年経った現在、RNアプリは高速に動作しており、Shopifyアプリでは500ms以下（P75）の画面読み込み時間を達成している
- 同様の性能目標を他のすべてのアプリでも問題なく達成した
- 性能ボトルネックを取り除くために、優れたパターンと技術を適用することが不可欠である
- ネイティブが常に速いとは限らず、RNが常に遅いわけでもない
- RNはこの数年で大きく進化し、ワールドクラスのアプリを構築できるプラットフォームとして定着した
- RNフレームワークが成熟するにつれ、高速なアプリを開発することはますます容易になると期待している
- チームの専門性が高まるにつれて、より良いアプリを作る余地も広がっていく
ホットリロードの利点
- React Native（RN）のホットリロードは、変更が即座に反映されることで開発環境に革新をもたらした機能である
- ネイティブ開発における最大の問題の1つは、コードベースの規模によっては些細な変更でもコンパイルし、エミュレータや実機で実行するまでに数分かかることだった
- その結果、時間が無駄になり、開発者の作業フローが中断される問題が発生していた
- RNのホットリロードはこの問題を完全に解消し、生産性と開発体験を大きく向上させた
TypeScriptによる人材流動性の確保
- TypeScriptが広く使われるようになったことで、React WebとReact Native（RN）の間で開発者がスムーズに移動できるようになった
- Web開発者: RNによって、ネイティブiOSやAndroid開発よりもはるかに容易にモバイル作業を始められる
- モバイル開発者: RNによって、Webの仕事にも容易に参加できる
- 人材流動性の利点
- エンジニアにより多くの成長機会を与え、人員配置の柔軟性を高める
- 同じ開発人員でより多くの仕事をこなせる能力を強化する
- Webとモバイル間でのコード共有を通じて、より大きな効率性と生産性を生み出す
- 複数プラットフォームで作業できる開発者は、より迅速なリリースを可能にし、技術間のアイデアを交換して新しい形で応用できる
- 技術を道具として捉える文化を形成し、チームの視野を広げ、作業に最も適したツールを選べるよう促す
ネイティブ開発者は不可欠
- iOSとAndroidに特化したモバイルエンジニアは、優れたモバイルアプリを構築するうえで不可欠である
- 複数のモバイル製品を開発する中で蓄積された経験と、ユーザビリティや慣習に対する深い理解は代えがたい
- プラットフォームレイヤーへのアクセス、バインディングの作成、ビルドと配布の習熟、そしてReact Nativeのバージョン更新管理といった作業にはネイティブの専門知識が必要である
- ネイティブ開発者は、多様なデバイスモデルでアプリ性能を最適化し、すべてのユーザーに一貫した体験を提供する
- iOSとAndroidの新機能、API、ツールチェーンの変化への対応や、React Nativeのバージョン更新管理にも不可欠である
- ネイティブモバイル開発者向けのReact Native研修コースを開発:
- セルフラーニング形式で構成し、プロダクションレベルのコードを書けるよう支援
- React Nativeに習熟した開発者とのQ&Aセッション、ペアプログラミング、コードレビューを通じて追加支援
- Web開発者（JavaScript、TypeScript、Reactの専門家）をモバイルチームへ追加配置:
- ネイティブとReact Nativeの両面で強い専門性をバランスよく保有
- 時間とともにチーム全体の技術レベルが向上
- ネイティブ開発者とWeb開発者がうまく調和したチーム構成こそが、React Nativeを活用した優れたモバイルアプリ開発の鍵である
ネイティブコードは不可欠
- 100% React Nativeの使用は避けるべき: RNは機能を一度だけ開発すればよい効率的なツールだが、あらゆる状況に適した技術ではない
- ネイティブコードが必要なケース
- 先端機能の開発: 2D/3DスキャンやオンデバイスAIモデル実行など、ハードウェアを活用する機能
- メモリ制約のある機能: ホーム画面・ロック画面ウィジェット、Apple Watchアプリとコンプリケーション、App Intents、Siri Shortcutsなど
- 長時間実行されるバックグラウンド処理:
- 例: ShopifyのPoint of Saleアプリは、大量のデータをバックグラウンドでダウンロード・同期し、オフラインでも取引を処理できる
- ネイティブコードを活用してバックグラウンド処理を完全にオフロードし、アプリ性能に影響しないよう設計している
- RNは大半の機能を一度だけ開発するのに適しているが、ネイティブが最もよく機能する領域ではネイティブコードを活用するのが理想的である
- RNが標準で備えるネイティブとの強力な相互運用性により、両技術の組み合わせは容易になっている
- RN「または」ネイティブという関係ではなく、RN「そして」ネイティブという関係で捉えることが重要である
- ネイティブの専門性を持つチーム構成が、この調和を効果的に実現するうえで不可欠である
デバッグの難しさ
- React Native（RN）のデバッグには不安定な面があり、VSCodeで正しく設定するには追加作業が必要である
- iOSとAndroidは強力で安定したデバッグ機能を標準で提供している
- Metaは最近、RNのデバッガスタックを全面的に書き直して改善を進めており、新しいデバッガは有望な結果を示している
- ShopifyはMetaと協力し、RNのデバッグ環境をワールドクラスへ引き上げるために取り組んでいる
React Nativeのアップデートはシームレスではない
- React Native（RN）の新バージョンへアプリを更新するには多くの作業が必要で、しばしばコードベースの再構成も求められる
- Shopifyはこれに対処するため、小規模なローテーション開発者グループを編成して更新作業を専任させ、他のチームは機能開発に集中できるようにしている
- RNフレームワークが成熟するにつれ、アップデート作業は徐々に容易になると見込まれる
- New Architectureがより広く採用されれば、更新関連作業の複雑さは軽減されると期待される
サードパーティライブラリへの依存増加
- React Native（RN）フレームワークはネイティブに比べて包括性が低いため、より多くのサードパーティライブラリを使うことになる
- この数年でエコシステムが成熟し、必要なほぼすべての機能について適切に保守されたライブラリを容易に見つけられるようになった
- ただし、サードパーティライブラリを継続的に更新・維持する必要があり、サプライチェーン攻撃の対象領域も広がる
- ShopifyはDependabotを活用した自動依存関係更新を導入した
- 自動コードスキャンによって悪意あるコードを検知・防止
- RNフレームワークがより明確な方向性を持ち、標準でより多くの機能を提供する方向へ発展することを期待している
共有基盤の活用で得られる大きな利点
- React Native（RN）を初めて導入した当時は、RNでモバイルアプリを構築した経験が乏しく、ネイティブ開発で蓄積した共有基盤も活用できなかった
- 当初は各チームが独自に問題を解決しながらアプリを開発しており、これは迅速に開始し、アプリを移行するうえでは効果的だった
- しかし、各チームが同じ問題を何度も解決することで、非効率な重複作業が発生した
- RNの専門性を築くために時間と労力を投資し、スピードを優先する代わりに一貫性を犠牲にするというトレードオフを意図的に選んだ
- 2023年以降、すべてのアプリが成熟するにつれて一貫性の強化を始めた
- 共通コンポーネント（例: Identity、リアルタイム監視、性能計測など）を共有ライブラリとして抽出し、すべてのアプリで活用
- これにより、各チームはすでに解決済みの問題を再び解く必要がなくなり、既存の解決策を活用できるようになった
- 2025年にはコード共有をさらに拡大し
- チーム間で知識と専門性を広げ
- 共有コンポーネント改善の恩恵をすべてのアプリが自動的に受けられるようにし
- エンジニアリングリソースを節約して、ユーザー価値を届ける作業に集中する
React Nativeの未来
- React Native（RN）の未来は明るく、Metaはこのプロジェクトの優れた管理者として継続的な改善を提供している
- 各リリースでは開発者のフィードバックがロードマップに大きく反映されており、高速なアプリを作ることはますます容易になると期待される
- ShopifyはNew Architectureを導入しながら、RNの発展を継続的に支援していく計画である
- Microsoft、Amazon、Tesla、SpaceX、Coinbaseといった主要企業がRNを採用しており、高品質なサードパーティライブラリやフレームワークも継続的に登場している
- Shopifyは次のような形でオープンウェブ、オープンソース、オープンスタンダードに貢献している
- さらに2025年にはReact Native Working Groupを再始動する
- RNを支援する組織の主要リーダーを集め、エコシステムの重要課題を特定し、投資の優先順位を定め、協力を促進し重複作業を減らすことが目的
- これまでの参加企業: Meta、Twitter、Coinbase、Microsoftなど
- 参加を希望する場合は問い合わせ
- RNは過去5年間で大きく進化しており、導入をためらわせていた多くの制約は今や解消されている
- しばらくRNを使っていないなら、今こそRNをもう一度試すのに良いタイミングである
9件のコメント
同じような時期に同じような理由でRNを導入しましたが、うまく活用しています。
パフォーマンスの問題については少し共感しにくいですが、それはおそらくreact-domレベルで解決すべき問題でしょう。
少ない人数で多くのことができるのが、いちばん大きな利点だと思います。
RN の Native API でカバーできないネイティブ機能には何があるのか気になります。
印象的な体験談の共有です。今は仕事でKotlinを使ってAndroidアプリ開発をしていますが、ときどき考えます。本当にネイティブで行く必要があるのだろうか……？（私の場合はプラットフォームと密接に連携して作業しなければならないものがあり、やむを得ずネイティブを選びましたが）可能であれば、React NativeやFlutterのようにクロスプラットフォームに対応した方向で進むのも良い気がします。
Shopify、すごいですね@.@
"100% React Native should be an anti-goal. It is great for building features just once, but is not the right technology for everything."
"Instead of thinking native or React Native, think native and React Native."
エンジニアリングに100%はありません（「無条件でAのほうが良い」という釣りタイトルには注意）。
それぞれに長所と短所があり、状況に合ったツールがあるということです。
Shopifyのチームビルディング哲学も見えてきて、とても良い記事です。
それでも私はFlutterを称賛したいです。
RNですべてのアプリを移行……すごいですねｗ
@shopify/flash-list、最高です。ありがとうございます。shopifyShopifyはRuby on Railsエコシステムでも中核的な役割を果たしていますが、
RNエコシステムでも驚くべき歩みを見せていますね。素晴らしい会社です。