R blog

2020/09/03 19:30 から開催された
「【Kanmu × Nature】React Native Meetup」のレポートです！

kanmu-nature.connpass.com

誤字脱字等あるとは思いますがご了承ください。。。！
内容に間違いがあればコメントいただけると助かります！

カンムでのReactNativeの歴史と現在
NatureでのReact Nativeアプリの運用について
パネルディスカッション

カンムでのReactNativeの歴史と現在

株式会社カンム取締役CTO、伊藤友気さんによる発表です！

twitter.com

歴史

バンドルカードは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に移行予定
- JSで簡単にプラグイン書ける
- SDKが提供されているので簡単にデバッグを表示できたりする
Storybook
- UIコンポーネントカタログ的にはなっていないけど開発時にコンポーネントのみを確認するような用途で利用する
- ほぼすべてのコンポーネント/ページをStorybook化
- StoryshotsでSnapshot testingを行っている
Sentry
- 当初よりエラートラッキングに利用
Firebase Crashlytics
- クラッシュレポート
- Firebaseで記録しているイベントに紐付けられるので便利
Analytics
- 行動ログはFirebase Analytics
- react-navigationの遷移イベントフックしている
RemoteConfig
- 任意のタイミングで表示を切り替えたい場合 (ex. アドホックな文言の変更など
- A/Bテスト

これから

FlowをTSに移行したい→変換ツールあるけど一筋縄ではいかない感じがする
AtomicDesignベースとコンポーネントをデザイナーと共に認識を合わせながら整理している

まとめ

Webの開発者なら基本的には開発にはすぐ入れる
ハマったときはネイティブの知識がないとやはりしんどい
都度ハマりながら進んできた

NatureでのReact Nativeアプリの運用について

Nature株式会社、soh335さんによる発表です！

twitter.com

チーム紹介

アプリ: 2
バックエンド: 3
ファームウェア: 2 (C言語)

アプリ自体は合計5人だけどそれぞれ兼任している

移行時の話

ネイティブからReactNativeに移行した

2018年 iOS,Androidを2人でアクティブに開発していくのが難しかった

当時

ReactNative 0.52.0
TypeScript 2.6.2
認証部分はマイグレーション処理を用意（ネイティブに）
デザインの制約がある
- iOSにある文字の大きさを調整して詰めるやつとかAndoirdになかったり、逆もある
View周りはほぼコードは共通化されている

アクティブに週1ぐらいでリリースできるようになった

共通化できなかったもの

ネイティブの挙動に関連するもの
パーミッション周り
Geofence周り(距離測るやつ)
メーラ開くところとか
Bluetooth周り
どちらかだけ挙動がおかしく回避策を入れている場合

困ったポイント

デバイスのセットアップ時にデバイス自身のネットワークにスマートフォンを繋ぐ必要がある
- マシンに起動しているデバッガとの接続が切れる...

Today WidgetはReactNativeでは容量の問題で実質無理。なのでネイティブで実装。

放置されたissue

テキスト周り
CJK特有なもの
ネイティブ側のビルドシステムが刷新されると大変

React NativeにPR送ってマージされるまでは、PRがマージされた状態のReact Nativeを持ってきてビルドしていた。

最近かんがえていること

普通に作っていれば iOS Androidどのサイズでも動くのが良いなー
Android深くわからんくてもアプリ普通に作れる
2人のリソースだと1,2週間でリリースできるのがよい
TSがよい
デザインiOSによりがち
ネイティブのアップデートキャッチアップしないといけない
セキュリティで権限周りが結構変わる
ReactNativeのバージョンアップは本体がそんなに壊れる印象はない
周辺ライブラリが影響あることがおおい
iOS,AndroidのOSバージョンが上がるタイミングが気になる
メンバーが増えればネイティブでもよいかな
さくっと書いて確認できる開発体験が良い
Hermesどうなんだろう？

パネルディスカッション

最後にパネルディスカッションです！

株式会社カンム取締役CTO、伊藤友気さん
Nature株式会社、soh335さん
Nature株式会社、亀田京介さん

の3名でいろいろな質問にお答えいただいていました！

React Nativeのメリット・デメリット

メリット

カンムさん

Web経験しかないメンバーでさっとできる
- Androidつらいとかあったけど、それを差し引いてもリリース速度あげれる
- Reactわかればすぐ修正とかできる

Natureさん

すくない人数でiOS/Androidが同時にリリースできる
DXが良い

デメリット

カンムさん

つらいところはある
- Flowつらい→TS移行すれば解決するかも

Natureさん

Nativeと比べれば多少プラットフォーム違うよねって感じ
Today Widgetができない。プラットフォームの制約というものがある。

iOS/Androidのデザイン最適化をがんばったらViewに分岐がめっちゃ増えるのか？

カンムさん

バンドルカードの場合はほぼ分岐していない
- iOSのデザインに寄せている
- こだわっていったら分岐が増えていく
- トレードオフ

Natureさん

カンムさんと同じく

デザインで分岐しているところはない
デザインで分岐するとReactNativeのメリットを損ねる

バージョンアップ大変？

カンムさん

本体のバージョンアップは大丈夫
周りのライブラリとかは大変
手動で確認していかないといけない場面もある

Natureさん

ネイティブで開発するときでもチェックって発生するし、無コストでできるわけではない
ライブラリは壊れるたびに捨てることはあったりする。自分で書いちゃったり
意外と大変じゃない

学習・教育コストについて

カンムさん

React書いたことがあれば書けると思う

Natureさん

割と力技で動く、reactのお作法が一通りわかっていれば

ネイティブに切り替える可能性は？それはどんなときか？

カンムさん

貧者のツールというのは一定同意
- iOS/Androidの開発者が数人ずついれば採用しなくてもよいと思う
Facebookがやる気失ったら → 今のところまだ大丈夫
ネイティブの開発者が集まったら

Natureさん

マイクロソフトもっとがんばって
結構Nativeもりもりなので、ネイティブのエンジニア増えてきてこのリリース速度だせるなら切り替えるかな
ネイティブにするなら、iOS/Androidの開発者だけじゃなく、iOS/Androidのデザインも用意しないといけない。チーム全体で成長していかないとリリース速度だせないのでそこまでかんがえてからネイティブに切り替えるかな。

現時点でFlutterと比較すると？

カンムさん

チームとかスキル次第だけど
react nativeの経験がなかったらflutterを選ぶ可能性は大いにある
webも同時に提供したいという話があると、そこまでスコープに入れるとどうなるか？が気になりポイント
webまではコードで共通化する必要はないけど、webの開発者もってなると、react nativeのほうがスケールアウトしやすいなと思う
そういうの全部とっぱらったらflutter選ぶかも

Natureさん

Flutterは外野から眺めているのでわからない
スキルとチームマッチをかんがえて、react強いチームならReactNativeだし、Dartよいと思うならFlutterで良さそう。
もしReactNativeを触ったことなくて、ネイティブエンジニアからだったらFlutter使うかも
- ReactNativeで困っているのUIコンポーネントのところで、iOSっぽいものをreact nativeで作り上げている
- Flutterだとマテリアルデザインにのっとって作れるので、考えることが一つ減るので、機能開発に集中できそうな気がする
- 結構iOSユーザーでもマテリアルデザインのアプリを触っている（Google系のアプリ）ので、マテリアルデザインでも困らないのではないか？という感覚

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で改善されてほしい
- アニメーションはこれ！と統一されてほしい