【Kanmu × Nature】React Native Meetup レポート
2020/09/03 19:30 から開催された
「【Kanmu × Nature】React Native Meetup」のレポートです！
誤字脱字等あるとは思いますがご了承ください。。。！
内容に間違いがあればコメントいただけると助かります！
カンムでのReactNativeの歴史と現在
株式会社カンム 取締役CTO、伊藤 友気さんによる発表です！
歴史
- バンドルカードはReactNative
- iOS/Android両方ReactNative
- 4年ぐらいReactNative
- バンドルカードの前にやっていたプロダクトの反省から自分達でカードを発行すべきとかんがえた
- 開発者3人（内１人は兼デザイナー）
- 3人ともWebの開発経験はあったがネイティブ開発経験なし
- 2015/12 開発開始
- 2016/09 iOSリリース
- 2016/12 Androidリリース
2015/2にReactNativeが発表されたので、かなり早い採用をしている
「ネイティブ開発経験のない、少人数の開発者で、素早くアプリをそれなりのクオリティでリリースしたかった」
Cordvaとか候補はあったけど、結構ユーザー体験がわるかった（もっさりしていた）
3ヶ月ぐらいReactNativeの検証を行って、問題なさそうと感じ採用した。
直面した課題
Android版リリース
開発初期はiOSのみでリリース、
Android版もそこまで大きな変更は必要ないと見込んでいたけど、
実際にはアニメーション系などいくつかクラッシュする部分や、
iOSしか対応していないライブラリを導入していたりした。
- プラットフォームによる分岐、機能変更などにより、なんとかAndoirdリリース
- あとからアプリケーションレベルでのプラットフォームごとの分岐は解消した
Android4.4系の対応
4.4系は原因の特定が難しいクラッシュが発生しがち
Androidの64bit対応のためReactNativeのアップデートをしたが、4.4でクラッシュが爆増し断念
→ 4.4系のサポートを終了を決定
終了までの間 Multiple APK にして64bit対応版/非対応版を別ブランチで管理
64bitと32bit対応版を作っていた。別のブランチで対応していたので、かなり辛かった
サポート終了してブランチは1つに戻った
「結構Androidははまりがち」
「はまったときはネイティブの知見がないと厳しい戦い」
現在の構成
- ReactNative
- JavaScript
- Flow
- Redux
- Storybook
- Firebase
日常のほとんどの開発がReactの世界のエコシステムの範囲で済んでいる
Expoは使っていない（開発開始当時なかった）
リリースサイクルはおよそ週1回
- ビルド/リリースはfastlane
- CIはBitrise
- lint jestのテストは別プロジェクトと共有でCircleCI(JSの世界のもののみ)
- DeployGateで社内アプリとして配布
- Github Actionsでリリース周りのときにリリースノート更新しているかとかをDANGERで検証
- BitriseからDeployGateへ検証アプリ配布
- BItriseからバイナリ・メタ情報をStoreにアップロード、審査は手動
- JSON Hyper-SchemaからAPIクライアントの実装を自動生成している
- バックエンドはgo
- goでもスキーマからリクエスト/レスポンスの構造体やバリデーションを自動生成している
デバッグ
- react-native-debuggerつかっている
- react-devtools/redux-devtools相当の機能
- ネットワークのデバッグ
- ネイティブのエレメント検証
※ バージョンによってはつらいところがあったりするので↓
- Flipperに移行予定
- Storybook
- Sentry
- 当初よりエラートラッキングに利用
- Firebase Crashlytics
- クラッシュレポート
- Firebaseで記録しているイベントに紐付けられるので便利
- Analytics
- 行動ログはFirebase Analytics
- react-navigationの遷移イベントフックしている
- RemoteConfig
- 任意のタイミングで表示を切り替えたい場合 (ex. アドホックな文言の変更など
- A/Bテスト
これから
- FlowをTSに移行したい→変換ツールあるけど一筋縄ではいかない感じがする
- AtomicDesignベースとコンポーネントをデザイナーと共に認識を合わせながら整理している
まとめ
- Webの開発者なら基本的には開発にはすぐ入れる
- ハマったときはネイティブの知識がないとやはりしんどい
- 都度ハマりながら進んできた
NatureでのReact Nativeアプリの運用について
Nature株式会社、soh335さんによる発表です！
チーム紹介
アプリ自体は合計5人だけどそれぞれ兼任している
移行時の話
ネイティブからReactNativeに移行した
2018年 iOS,Androidを2人でアクティブに開発していくのが難しかった
当時
- ReactNative 0.52.0
- TypeScript 2.6.2
- 認証部分はマイグレーション処理を用意（ネイティブに）
- デザインの制約がある
- iOSにある文字の大きさを調整して詰めるやつとかAndoirdになかったり、逆もある
- View周りはほぼコードは共通化されている
アクティブに週1ぐらいでリリースできるようになった
共通化できなかったもの
困ったポイント
Today WidgetはReactNativeでは容量の問題で実質無理。なのでネイティブで実装。
放置されたissue
- テキスト周り
- CJK特有なもの
- ネイティブ側のビルドシステムが刷新されると大変
React NativeにPR送ってマージされるまでは、PRがマージされた状態のReact Nativeを持ってきてビルドしていた。
最近の開発の話
- VSC
- Xcode
- Android Studio
- Emulator
- 新しい画面の追加は、React Navigationを使っているのでScreen Componentを増やしていく
- 最近はhooksも使っている
- 複雑なデザインにするとしんどいのでシンプルに
- グラフ周りの計算はD3、描画はreact-native-svgみたいなこともしている
ReactNativeのバージョンを上げているタイミング
- メージャーアップデートが出たらその前の最後あたりを検討
- Expo SDKも参考にする
あえて使っていない
- Expo
Nativeのコードを書かないという選択肢がないので
Geofence, Siriとかアプリロジックそのまま書かないと無理 - OTA
react-nativeのversion依存があり、アップデートの足枷にしたくない
自分たちでコントロールできないものを増やしたくない 最近審査はやいし - Keychain周り
Keychainはちゃんと書くのが難しい
信頼しているライブラリを使いたいので
KeychainAccessをラップして、ReactNativeから使っている - Geofence
アプリロジックに密接
普通にネイティブで書く
あとは、
ネイティブに数行書けばいいようなものは自分たちで用意
オフィシャルがホストしていないライブラリは採用していない
最近かんがえていること
- 普通に作っていれば iOS Androidどのサイズでも動くのが良いなー
- Android深くわからんくてもアプリ普通に作れる
- 2人のリソースだと1,2週間でリリースできるのがよい
- TSがよい
- デザインiOSによりがち
- ネイティブのアップデートキャッチアップしないといけない
- セキュリティで権限周りが結構変わる
- ReactNativeのバージョンアップは本体がそんなに壊れる印象はない
- 周辺ライブラリが影響あることがおおい
- iOS,AndroidのOSバージョンが上がるタイミングが気になる
- メンバーが増えればネイティブでもよいかな
- さくっと書いて確認できる開発体験が良い
- Hermesどうなんだろう？
パネルディスカッション
最後にパネルディスカッションです！
- 株式会社カンム 取締役CTO、伊藤 友気さん
- Nature株式会社、soh335さん
- Nature株式会社、亀田 京介さん
の3名でいろいろな質問にお答えいただいていました！
React Nativeのメリット・デメリット
メリット
カンムさん
- Web経験しかないメンバーでさっとできる
- Androidつらいとかあったけど、それを差し引いてもリリース速度あげれる
- Reactわかればすぐ修正とかできる
Natureさん
デメリット
カンムさん
- つらいところはある
- Flowつらい→TS移行すれば解決するかも
Natureさん
- Nativeと比べれば多少プラットフォーム違うよねって感じ
- Today Widgetができない。プラットフォームの制約というものがある。
iOS/Androidのデザイン最適化をがんばったらViewに分岐がめっちゃ増えるのか？
カンムさん
Natureさん
カンムさんと同じく
- デザインで分岐しているところはない
- デザインで分岐するとReactNativeのメリットを損ねる
バージョンアップ大変？
カンムさん
- 本体のバージョンアップは大丈夫
- 周りのライブラリとかは大変
- 手動で確認していかないといけない場面もある
Natureさん
- ネイティブで開発するときでもチェックって発生するし、無コストでできるわけではない
- ライブラリは壊れるたびに捨てることはあったりする。自分で書いちゃったり
- 意外と大変じゃない
学習・教育コストについて
カンムさん
- React書いたことがあれば書けると思う
Natureさん
- 割と力技で動く、reactのお作法が一通りわかっていれば
ネイティブに切り替える可能性は？それはどんなときか？
カンムさん
Natureさん
- マイクロソフトもっとがんばって
- 結構Nativeもりもりなので、ネイティブのエンジニア増えてきてこのリリース速度だせるなら切り替えるかな
- ネイティブにするなら、iOS/Androidの開発者だけじゃなく、iOS/Androidのデザインも用意しないといけない。チーム全体で成長していかないとリリース速度だせないのでそこまでかんがえてからネイティブに切り替えるかな。
現時点でFlutterと比較すると？
カンムさん
- チームとかスキル次第だけど
- react nativeの経験がなかったらflutterを選ぶ可能性は大いにある
- webも同時に提供したいという話があると、そこまでスコープに入れるとどうなるか？が気になりポイント
- webまではコードで共通化する必要はないけど、webの開発者もってなると、react nativeのほうがスケールアウトしやすいなと思う
- そういうの全部とっぱらったらflutter選ぶかも
Natureさん
- Flutterは外野から眺めているのでわからない
- スキルとチームマッチをかんがえて、react強いチームならReactNativeだし、Dartよいと思うならFlutterで良さそう。
- もしReactNativeを触ったことなくて、ネイティブエンジニアからだったらFlutter使うかも
React Nativeエンジニア採用できてますか？どんな人がほしいか？
カンムさん
- どっちかというとwebの人のほうが多い、現状すんなり入ってもらっている
- はまったときにちゃんとネイティブを見れる人がいないと大変
- ↑を担保できていれば、日常の開発ではwebの経験があれば問題ない
Natureさん
- ネイティブよりからいくのかWEBよりからいくのか
- Natureではネイティブがわかる人がreact nativeにジャンプしてくれる方がやりやすい
- webよりの人にreact nativeを書いてもらったことがない
- ネイティブの機能を使ってデバッグとかもしているので、そこらへんWEBからの人だとどうなんだろう？
- ネイティブの経験がないと厳しいかなと思っていたけどwebの経験でもいけるかもしれない
- どこか一つ軸がある（reactなのかネイティブなのか）人が良い
今後React Nativeに期待すること
カンムさん
- Hermesまだ安心できない
- 移行してみたいけど、もうちょっと様子見かなぁ。。。
- 最近はだいぶ良くなってきているので不満はあまりない
- 開発当初のほうは周辺ツールとか大変だった
Natureさん
- AndroidのJSエンジンのHermesが今どれぐらいいけてるのか教えてほしい
- react nativeではjavascript coreというjsを動かすエンジンがある
- もとはwebkit系
- Androidの環境で最新に追従できていない
- そこでfacebookがHermesというエンジンを作っているが、それがどれぐらい信頼できるのかという情報が出ていないのでそこがもうちょっと出てくれるとよい
- Hermesこの間新しいバージョンでたけどまだ使えない
- アニメーション周り
- react nativeでオフィシャルでホストされているライブラリかreact-native-animatableか
- react-native-animatableはv1が難しい、v2で改善されてほしい
- アニメーションはこれ！と統一されてほしい
