AirbnbがReact Nativeを諦めてネイティブアプリに方向転換したわけ

なんと、AirbnbがReact Nativeを諦めてネイティブアプリに方向転換すると発表した!

facebookもネイティブアプリにすることに決めたので、React Nativeの支援軍の両大山脈がReact Nativeからの撤退を決めたことになる。Airbnbがその背景を長文の記事で公開していたので、要点だけ(「超」がつくほど簡単に)整理してみる。


採用の理由

Airbnbは2016年度にReact Nativeを採用すると決めた。(色々カッコつけた採用の理由を言っているが)その背景には彼らが当時必要だったネイティブエンジニアを十分に確保できなかったことがある。要するに、スマホの使用率の増加に伴って迅速にアプリを作成・改善しないといけなかったのにネイティブエンジニアを適時に採用できなかったのだ。Airbnbはウェブのサービスを運用していたので、当時の社内にはウェブのエンジニアが沢山いた。だから、彼らが親しみ易いものを選んだのも一つの理由。

技術的な側面

うまくいったこと

  • クロスプラットフォーム: React Nativeの主なメリットであり、95~100%のコードを共有することができた。
  • 統合されたデザイン言語システム(DLS):AirbnbはDLSというクロスプラットフォーム用のデザイン言語を開発した。DLSはアンドロイド、iOS、ウェブとReact Nativeという各プラットフォームに対して独自のコンポーネントを開発して柔軟性を得たけど、これは同時に断片化を招いた。
  • Reactのメリット:Reactの採用によってシンプルさとパワー、そしてスケーラビリティを得た。
  • イテレーションの速度:hot reloadingを使うことでアンドロイドやiOSのコードのテストを数秒で行うことができた。
  • インフラへの投資:膨大な数のネイティブなインフラストラクチャーをReact Native APIでラッピングすることでアンドロイドとiOSの差を隠蔽した。このようなインフラへの相当な投資がなかったらReact Nativeへの投資は失敗したんだろう。つまり、既存のアプリにReact Nativeを導入することはそんな簡単なことではないと言える。
  • パフォーマンス:さほど問題にならなかったし、多くのパフォーマンスの問題はshouldComponentUpdateremoveClippedSubviewsを効果的に使うか、Reduxをうまく使うことで解決できた。しかし、初期化や初回のレンダーリング時間の遅さはReact Nativeアプリにいくつかの問題を起こした。
  • Redux:一言で言うと、難しかった!
  • ネイティブの支援:独自のネイティブのブリッジコードを作った。

うまくいってなかったこと

  • React Nativeがまだ新しいものなので、どこに罠があるか事前に分からなかった。一回ハマるとどれくらい時間がかかるかも予測できなかった。
  • 同じ理由で、React Nativeのバージョンの更新も早く、それに追従するのが大変だった。
  • JavaScriptは動的タイピングを許す言語なのでスケールし辛い。リファクタリングも大変。あれこれ対策を試したけど結果的にはうまく行ってない。今でもTypeScriptを試している。
  • JavaScriptCoreがプラットフォームごとに異なるので、それを原因とする問題のデバッグが大変。これも一回ハマると相当時間がかかる。
  • ほとんどのエンジニアはiOSかアンドロイドのどちらかの環境には詳しいけど、両方を熟知している人は少ない。React Nativeのオープンソースのライブラリはそのような人々によって作られている。結果的に安心して使うことはできない。テストも大変。
  • 最初にレンダーリングする時にランタイムの初期化に数秒もかかる。
  • アプリサイズが大きくなる。
  • アンドロイドで64ビット対応が未だにできない。
  • 複雑なジェスチャーが使えない。
  • その他(細かく技術的なことが書かれているので省略)

組織的な側面

React Nativeの採用はエンジニアの組織にも変化をもたらした。何か問題が発生した場合、その原因となる理由を探すのは結構大変だった。React Nativeが常に変わっているし、Airbnbで作ったインフラストラクチャーのコードも、プロダクトのコードもまた変わっている。文書、ガイドラインなども不安定な状態に陥る。

よくある勘違いはReact Nativeを使うとネイティブコードを書かなくて済むということだが、現実はそうではない。品質のいいアプリを作るにはネイティブコードとReact Nativeのコードのバランスを慎重に検討する必要がある。

デバッグをする際にはネイティブコードを深追いしないといけない場合があるのでネイティブ開発の知識は必要。また、React Nativeとネイティブのどこをみればいいかを判断することも容易ではない。結果的にエンジニアは全てのプラットフォームとReact Nativeの知識を学習する必要がある。

このようにReact Nativeとネイティブコードが混在する環境でどのようにチームを構成して運営すべきか?どんな人を採用するか?エンジニアはどうやって3つのプラットフォームに対してテストできるか?全部難しい問題。

React NativeとiOS、アンドロイドの3つのプラットフォームの開発環境を合わせることも大変。

アンドロイドとiOSに比べるとReact Nativeは文書も情報も少ない。

React Nativeを諦める

上記のあれこれの理由で、AirbnbはReact Nativeを諦めてネイティブアプリに再投資する。ただし、React NativeがAirbnbのゴールに合ってなかっただけで、エンジニアのReact Nativeへの評価はよかった。(この部分はReact Nativeコミュニティへのインパクトを考慮して書かれていることは明らかなので、省力した。)

結論的に、React Nativeをネイティブとシームレスに連携してアプリを作ることは可能ではあるけど、容易なことではない。

Airbnbの今後のモバイル

ネイティブアプリ開発に向けていくつか新しいことをやっている。

  • サーバー側でレンダーリングするフレームワークを試している。
  • 新しいAndroidのフレームワークを作っている。
  • ビルドタイムを短縮するツールを作っている、等。

私の感想

結構長文の記事だったけど、直接コードを書いてなく、彼らの記事だけで理解しているものの視点では、普通に想像がつく以上のことはあまり書かれてなかった。それよりは、「あなた達、2年間何やってたんですか?」と聞きたい。インフラとしてネイティブのコードをそんなに沢山書くくらいなら、普通にネイティブアプリとして作った方がよかったと思う。(まあ、ネイティブエンジニアがいなかったと言っているけど)またコードベースの管理がどれくらい大変だったかも十分想像がつく。あれで本当によくできたと言えるんだろうか?

また、ネイティブアプリに方向転換したのはいいものの、今後ネイティブアプリに対してまた独自の作り込みをして行くことを企んでいることをみると、「この人達、何も学んでないな」と思ってしまう。汎用的なプラットフォームの上に独自の世界を構築しても、配下のプラットフォームの変化を常にキャッチアップして行かないと砂上の楼閣になるのは避けられない。特に現在のモバイル環境のように変化が激しいところは尚更だ。React Native程ではないけど、モバイルOSもまだまだ枯れた技術とは言えない。

結論的に、会社のお金で一部のコアなエンジニア達が遊んでいるようにしか見えない。しかも、彼らはウェブエンジニアの視点を保ったままネイティブに取り組んでいる。多分、また失敗する。

しかし、このような遊び心があって、それが許される環境があるからこそ技術的発展もあるだろう。お金の余裕がある会社が多様な試しみを行って、それがたまには受け入れられて、周りに広がるといいだろう。

さて、React Nativeの将来はどうなるんだろう?それに乗っかっているVue Nativeは?