Slide 1

Slide 1 text

cookpad.apk 最近風当たりの強いReact Native for Androidについて

Slide 2

Slide 2 text

自己紹介 - 吉田万輝(かずき) - 2014年度クックパッド新卒入社 - 所属: 投稿開発部(10名) - Android エンジニア - Github: @kazy1991 - Twitter: @101kaz

Slide 3

Slide 3 text

「クックパッドMYキッチン」で検索

Slide 4

Slide 4 text

マルチプラットフォーム展開

Slide 5

Slide 5 text

ReactNativeを採用して後悔しているか?

Slide 6

Slide 6 text

No. 今のチームにはマッチしていて満足度が高い です。 ※チーム構成や目的に応じて RNの評価は大きく異なると思われます。

Slide 7

Slide 7 text

RNの評価が分かれそうなポイント - チームのメンバー構成 - 開発チームの規模 - 対象のユーザーの規模 - フルRNアプリ or ハイブリッドアプリ

Slide 8

Slide 8 text

ReactNativeがマッチする環境 - チームのメンバー構成 - Android, iOS, (出来ればJavaScriptも)に詳しい人がいる - 開発チームの規模 - 小さいチーム(2~6人程度) - 対象のユーザーの規模 - そこそこ(MAU数十~百万の単位になってくるとかなり厳しそう ) - フルRNアプリ or ハイブリッドアプリ - フルRNアプリを強く推奨

Slide 9

Slide 9 text

なぜか

Slide 10

Slide 10 text

チームメンバー構成について - ReactNativeはiOS,Androidエコシステムを上手く抽象化していますが、 よくわからない事象で嵌まる事があるのでiOS,Androidの専門性が必要 - リリースは通常の開発と同じなので安全で正しいリリースをするためにも iOS,Androidの知識が必要 - そのためiOS,Androidに詳しいエンジニアは必須

Slide 11

Slide 11 text

開発チーム規模と対象ユーザーの規模 - ReactNativeがそこまで安定したエコシステムではないので、チームメンバーの サポートを考えると一人が変更を常に追っていける規模感でないと厳しい - RN起因のどうしても解決できないクラッシュも多々起きる。ユーザーの規模が大 きくなると無視できないレベルになりそう

Slide 12

Slide 12 text

フルRNアプリを推す理由 - ReactNative自体が安定してないので出来る限りレールに乗った方が、 嵌まることが少ない - ReactNativeを導入するとプロジェクトがかなり汚染するので、 ネイティブ画面の開発する際に開発体験(DX)を著しく下げる

Slide 13

Slide 13 text

投稿開発部の開発メンバー - iOS: 2名 - Android: 1名 - rails: 1名 - デザイナー: 1名 - JavaScript: 1名(部長)

Slide 14

Slide 14 text

MYキッチンアプリ - 目的: - レシピ投稿者向けたクックパッドアプリのリデザイン - Chrome Canaryのようなベータ版アプリとしての役割も担っている - 機能 - 多くの画面がAPIレスポンスをViewにマッピングしている程度で、センサーなど ハードウェア機能をほとんど利用しない - 対象: - 小規模:ベータユーザー(DAUで数百人程度)

Slide 15

Slide 15 text

MYキッチンアプリの技術面 - プラットフォーム: - iOS and Android - コードベース: - 100% React Native App (with native-module) - 言語: - JavaScript -> TypeScript

Slide 16

Slide 16 text

RN製アプリのメリット

Slide 17

Slide 17 text

快適なリリース - CodePushを利用した高速なリリース - 多い時には月20回以上のデプロイ - 問題が起きてもすぐ直せる心理的 な安心感

Slide 18

Slide 18 text

すぐれた開発環境 - ホットリロードを利用した高速な開発 - 少しコードの書けるデザイナーの方ならガンガン実装まで出来る - 小さいチームなのでみんなが実装できるのはとても重要 - そこそこのクオリティでマルチプラットフォーム対応が可能 - ネイティブ実装と遷移のアニメーションが異なるなどの差異は諦める

Slide 19

Slide 19 text

RN製アプリのデメリット

Slide 20

Slide 20 text

クラッシュレポート - Sentryを利用しているが、捕捉出来てないクラッシュがありそう(要出典) - スタックトレースがJava(kotlin)ほど見やすくない - ReactNative内のNPEなども観測しているがどうしようも出来ない

Slide 21

Slide 21 text

まとめ(ReactNativeが向いている環境) - チームのメンバー構成 - Android, iOS, JavaScriptに詳しい人間がいる - 開発チームの規模 - 小さいチーム(2~6人)程度 - 対象のユーザーの規模 - そこそこ(数十~百万の単位になってくると厳しそう ) - フルRNアプリ or ハイブリッドアプリ - フルRNアプリを強く推奨 ReactNativeは組織にマッチするととても強力なツールになるのでぜひ検討してみて下さい!

Slide 22

Slide 22 text

ありがとうございました!!

Slide 23

Slide 23 text

ReactNative開発FAQ

Slide 24

Slide 24 text

バージョンアップについて - ReactNativeのバージョンアップが辛いという話をたまに聞きますが、 追従は全く辛くないです - OSSのネイティブモジュールなどが入っているとハマるかも..? - 前提としてOSSのネイティブモジュールは基本利用しないほうが良いです

Slide 25

Slide 25 text

マルチプラットフォーム辛くないですか? - 確認は大変ですが、実装コストを考えると対応する価値が十分にあります - リリース前はiOSとAndroid両プラットフォームでの確認を必須にしています