これはFOLIO Advent Calendar23日目の記事です。
昨日は3tty0nさんによる、「Tracing the Meta-levelとは？PyPyのJITコンパイラについて」でした。

テーマ投資サービスを運営する株式会社FOLIOでiOSエンジニアを担当している近藤です。
とても優秀な人たちばかりで、毎日充実した開発生活を送らせていただいています。

FOLIOのiPhoneアプリのアーキテクチャに関しては、杉上さんのRedux+Rxを活用したiOSアプリアーキテクチャが参考になります。アプリはRxやReduxを使ったネイティブで現在開発中です。

【SwiftエンジニアがReact Nativeでアプリを作って感じたこと】

上に書いた通り普段の業務ではSwiftを書いているのですが、一方でReact Nativeにも強い興味を持っています。

興味を持ったきっかけとしては、
・ UIKitの作者がUIKitよりReact Nativeの方が "圧倒的に" 優れていると言っている
・ 有名な海外のアプリで結構採用されている
・ メルカリがReact Nativeを使っている
・ @typesterさんがrebuild.fmでReact Nativeをべた褒めしていた
・ ProgateがフルReact Nativeで開発している
などです。

せっかく学ぶなら何か作ってみようということで、「ブラよろ英会話」というアプリをリリースしました。全くゼロから勉強しながら3日ほどの突貫で作ったような記憶があります。

公式ドキュメント以外では、Stephen GriderさんのUdemyの講座がとても参考になりました。

この記事の対象者

普段Swiftに触れていて、React Nativeに興味はあるがまだ手を出せていない人

この記事を書く動機

ネット上にあるReact Nativeに関する記事のほとんどが、Webエンジニアの視点から書かれていました。
「ネイティブエンジニアから見たReact Native」という視点には一定の価値があると思いました。

先にまとめ

実際に触ってみてすごく面白かったのですが、あくまでも自分は「ネイティブ vs React Native」の構図ではまだ中立の立場です。React Nativeには強力なメリットや将来性があるものの、すぐにネイティブのアプリが滅ぼされるというわけではないでしょう。
React Nativeがまだ発展途上であること、ネイティブにはネイティブの良さがあるということで、これからもキャッチアップし続けたいと思っています。
自分がWebやReactの知識があまりなかったことでReact Nativeの機能をフルに活かしきれていなかったかもしれませんので、反論があれば是非コメントお待ちしております。

【React Nativeの良いところ】

Viewを組むのがめちゃくちゃラク！

React Nativeで苦労したViewも部分的にはありましたが、総合的なラクさはやはりReact Native > UIKitだと思います。
少し想像していただきたいのですが、UIKitで「テキストの一部分のみクリッカブル」なViewを書くのは大変そうだと思われませんか？
React Nativeでは、なんと<Text>のタグの中に<Touchable...>タグで挟んだテキストを置くだけで実現できます。

<Text>
  AB
  <TouchableOpacity>
    CD
  </TouchableOpacity>
  EF
</Text>

また、「widthからはみ出したテキストは自動で改行する」ように出来るなど、UIKitで面倒な部分がすんなり書けてしまいます。
スタイルはCSSのようなもので書いていきますが、スタイル部分のみ切り出して書くことができるため可読性も保つことが出来ます。UIKitで書いている時のように、ロジックとスタイルがごちゃ混ぜになることもありません。

Build待ち地獄から開放される

多くのSwiftエンジニアがReact Nativeに興味を持つ理由はこちらでしょう。
「いくつか遷移を挟んだ奥の画面の、Viewの色を少しずつ調節したい。」 たったこれだけのことが、Swiftで書いていると本当に辛くなってきます。
規模の大きなSwift製のアプリだとBuildで数分待たされることはザラにあり、効率がとても悪いです。
Swiftは安全性や可読性が高く、保守のし易い愛すべき言語ですが、開発効率はやはりJavaScriptには及びません。
React Nativeには「Hot Reload」という神がかった機能があります。これは、遷移やStateを維持したままコードを変更し、すぐに画面に反映させることが出来る機能です。これによって効率の爆上がりは間違いないでしょう。

Hot Code Pushすごい

こちらはまだ試していないのですが素晴らしい機能です。なんと、「Appleの審査を通さずにコードを変更」出来てしまいます。（軽微な変更のみ）
上に書いたようにメルカリはReact Nativeを採用しているそうですが、その一番の理由がこのHot Code Pushだそうです。特にABテストと相性が良いため、この機能を使ってどんどん新機能を試しているそうです。
このシステムを導入していれば、ある程度見切り発車でリリースしてしまい、もしバグが出たらすぐにその部分のみ修正するということも可能だと思います。Appleの審査はやはりiOSエンジニアとしては悩みのタネであるため、とても心強いですね。

有名なのはMicrosoftのCodePushでしょう。

（場合によっては）UIKitよりパフォーマンスチューニングがラク

React Nativeの話をするとよく「パフォーマンスが心配」ということを言われます。
しかし、相当パフォーマンスを意識しなければならないアプリでなければ全く心配ないと思います。むしろ場合によっては、メモリ管理がラクだと感じました。
FlatListというテーブルビューのようなコンポーネントがありますが、「Cellの再利用」などに気を使わなくてもかなりサクサク動きます。
雑に作ったUIKitのViewよりは、React Nativeで作られたViewの方が内部で最適化されているな、と感じました。

【React Nativeの微妙（or 発展途上）なところ】

Objective-Cで書かれている

徐々に充実してきてはいるものの、React Native公式で用意されているコンポーネントのみで作りたい機能全てを揃えるのはまだまだ難しいです。
そういった場合、ネイティブのコードをブリッジングして、ネイティブの機能へアクセスすることが出来ます。
これはネイティブエンジニアとしては安心できる要素で、「困ったらネイティブのコードを呼べば良いや」と思えるのはありがたいです。
しかしReact NativeはObjective-Cで書かれているため、Swiftのコードを呼ぶためには一度Objective-Cを挟む必要があります。これは非常に効率が悪いのでReact Nativeを書く時は、2014年以降の記憶は一切消して、Objective-C脳に徹することをおすすめします。

とはいえ、シンプルなアプリであれば全くネイティブコードを書くこと無く、React Nativeだけで開発可能です。

使える機能がまだまだ少ない

上記に関連していますが、React Nativeのバージョンはまだ 0.51 (2017/12現在) と、正式リリース前です。
View周りのコンポーネントはわりと充実していますが、それ以外のネイティブの機能はまだあまり揃っていません。
有志の方々が色々と公開してくれているので、そういったものを利用するか、独自でObjective-Cを書いて呼ぶことになるでしょう。
ふんだんにOSや端末の機能を使ったり、最新のAPIを利用したいのであれば、React Nativeの恩恵はあまり受けられないかもしれません。

まだ不安定

開発中に何度も謎のクラッシュを経験しました。ログなどがあまりまだ充実しておらず、アプリがクラッシュすると、シミュレーターに真っ赤な画面が表示され突き放されるため、精神衛生上あまり良くないです。
今回はローカルのDBとしてRealm React Nativeを利用しました。
Realm公式から提供されているもので使い勝手はとても良かったのですが、たまたま利用していたReact Nativeのバージョンと相性が悪かったらしく、Realmを入れてからHot Reloadがほとんど機能せずとても苦労しました。
徐々に安定してくると思いますので、今後に期待したいです。

ロジックをJavaScriptで書かないといけない

これは完全に好みの問題なのですが、データを扱う部分や複雑な処理をJavaScriptで書くのに苦労しました。
もっとJavaScriptに慣れていれば違っていたのかもしれませんが、個人的にはやはりView以外はSwiftで書きたくなりました。
React Nativeがサポートしているのは主にView周りのみなので、ロジック部分にはやはり課題が残る印象でした。

【React Nativeが向いているアプリ】

・シンプルなアプリ

複雑な機能を使わないのであれば、驚くほどのスピードで開発出来ることでしょう。最近だとカンファレンスのためだけにアプリがリリースされることがありますが、そういったシンプルなアプリには最適だと思います。

・スピード重視

アプリの要件にもよりますが、多くの場合、ネイティブで作るよりも早くリリース出来ると思います。
「ユーザーの反応を見るためにとにかく早くMVPを出したい」などであればReact Nativeは選択肢に入るでしょう。
Hot ReloadやHot Code Pushがかなりスピードを早めてくれると思います。

・長期的な保守性をそれほど重要視していない

React Nativeはまだまだ激しくアップデートが繰り返されており、追従がなかなか大変です。
保守性を第一にするのであれば、React Nativeはあまり向かないかもしれません。

【最後に】

React Nativeに対して感じたネガティブな部分は、総じてReact Nativeがまだ未熟である部分から来るものでした。
つまりこれからどんどん存在感が高まっていくのでは無いかと思っています。
Swiftで書くアプリが無くなることはないと思いますが、React Nativeを採用する企業はどんどん増えていくと思います。

ここまで読んで「それでも自分はSwiftを書きたい！」「Swift最高！」「Swiftと心中したい！」という方に、どうしても伝えたいことがあります.....それは.....

FOLIOはSwiftエンジニアを絶賛募集中です！！！！！
採用ページはこちら

明日は弊社CTOである椎野さんの記事です。乞うご期待！