天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

【menu/リクルート/CROOZ】クロスプラットフォーム開発2022 -Flutter・React Nativeの導入と実践-に参加してきた

techplay.jp

こちらのイベントに参加してきたので、会の様子と感想を書いていきます。

会の概要

以下、イベントページから引用です。

今回はクロスプラットフォーム開発という大テーマで各社が取り組んだ「Flutter」「ReactNative」の導入検証をします!

CTOやPM・メンバークラスそれぞれの視点でクロスプラットフォームの導入経緯や技術選定プロセス、開発ノウハウや困ったこと、テスト手法、チームビルディングなど、クロスプラットフォームに関するtipsを得る勉強会です。

また当日は、Rubyの生みの親であるまつもとゆきひろ氏をモデレーターへお招きします!

会の様子

少なくとも2019年頃はFlutterではなくRNの方がいいよね*1、という話を社内で聴いたけれど、実際の所どうなのか?をRNを触り続けていた林さんが話してくれるました。

触ってみた正直な感想としては、学習コスト・書き方・開発体験・コミュニティの充実度合は両方ともそこまで変わらないように感じたそうですが、具体的に以下の点はFlutterの方がいいなと思ったそうです。

  • VSCodeのExtensionが素晴らしい
  • 公式が充実(日付管理、静的検証、テストライブラリ...が充実していて、安定択が取れる)

一方でRNの方がいいと思ったポイントとしては、

  • Reactであること(Webエンジニアなら堂々と書けて怖さもない)
  • GoogleっぽくないUIが作れる
  • ExpoのOTA updateがめちゃくちゃ便利*2

が挙げられるということでした。

年間300万人が利用するファッション通販アプリをFlutterでリプレイスした話

iOSAndroidそれぞれアプリ提供していた所、徐々にアプリの開発スピードが鈍化してきて*3クロスプラットフォーム言語としてFlutterの採用を決めたということでした。

導入にあたっては、開発効率が本当に向上することをPOCフェーズで確認しつつ、個人学習の時間を週に4時間取る&既存アプリ開発を止めて機能差分の実装に入ってもらう工夫を取ったそうで、リスクを最小限に抑えつつ移行を進めることができたそうです。

ただし、勿論WebView周りの不具合が起きたりキーボード入力直後のクラッシュ問題が起きたり、Widgetが豊富すぎて実現したいUIに対して取れる選択肢が多すぎるといった技術的な障壁や、0からの学習となるとキャッチアップにかかる時間が人によってかなり違って計画が立てにくいという課題ということでした。*4

機能開発速度という意味ではほぼ2倍になるものの、WebView問題*5やナレッジがまだ発展途上という問題もあるということで、導入時には注意が必要だとお話がありました。

大規模な「じゃらんnet」アプリを段階的にFlutter化している話

機能の増加に伴いビルドにかかる時間が膨大になってしまったことを経緯に、Flutterへのリプレイスを決めたということです。

とはいえ、Flutterでの本番アプリ実装の実績が乏しかった当時はフルリプレイスをいきなりするのは厳しいと判断されたそうで、まずはAdd-to-up*6からの導入を始めたということでした。

Add-to-upを導入した結果、開発効率の向上やクロスプラットフォーム言語としてFlutterが寄与することを実感できたそうで、次のステップとして、iOS/AndroidプロジェクトをFlutterプロジェクトに変更することを試み、最後にDartへの書き換えをしていったということです。

こうして段階的にリプレイスを進めることで、徐々に実績を積みながらリスクを抑えた移行ができたということでした。

パネルトーク

モバイルアプリ開発未経験がFlutterに入門するために

が挙げられていました。

今Flutterを使っていて早めに改善したい点は?

リグレッションテストに時間がかかるので、テストの充実&テスト速度の向上をしたいということでした。

サーバサイドはDartに移行することを検討した?

検討しなかったということでした。

海外端末で起きる問題とは?

WebView周りの問題が多い。テーブルタグがなぜか展開されない、アプリのメモリ使用量がなぜかOS側に依存してしまうなど...が挙げられていました。

プッシュ通知はFireBaseを使ったか?

使っているという話と、使っていないという方がそれぞれいらっしゃいました。

Flutterアプリのリリース時にキャッシュ移行は考慮していた?

基本的には引き継ぐようにしていた。MethodChannelを用いたり、移行時に一度だけ起動するプログラムを作ったりしていたということです。

OS固有の実装とは具体的に?

詳細を全て語ることは時間の都合上難しいが、メモリを使わなくなる工夫やパラメータ調整をしていたということでした。

ネイティブプロジェクトをFlutterに格納するとネイティブのビルドも走るのでは?

Flutterのビルドをしてもネイティブのビルドは起こらない。(逆は起こる)ただ、差分ビルドが働くので3秒くらいの増加だった。

Dartとネイティブのコミュニケーションは複雑化して大変そうに思えるが、実際どうだったか?

段階的に移行するという方法の副作用で確かにあったが、リスクを抑える判断だったのでやむを得ないというお話でした。

CI/CDサービスは利用しているか?

Jenkins、DeployGate、Bitriseを使用しているということでした。

メモリ管理に苦戦した場面はあったか?

そんなに困ったことがない*7という意見や、アプリ特性上の問題しかなかったということでした。

新規にFlutterに関わるメンバーはネイティブアプリの知識も必要か?

段階的な以降だと必要という意見と、移行しきっちゃった後はFlutter特化でもいいかもしれないという話がありました。*8

Flutter開発に関わる場合どういう風に採用をする?

言語に縛られずキャッチアップスピードが早い人、ということで一致していました。

全体を通した感想

パネルトークでは多数の質問が出ていたことからも分かるように、大盛り上がりの会でした。
自分よりも全然若い方々も非常にレベルの高い発表をしていて、刺激になる時間でした!

*1:UIがPixelっぽく、状態管理が難しい

*2:ストア申請のリードタイムが短くなる。包括的にサポートしてくれる

*3:影響範囲調査をする時に2倍の影響範囲調査が必要、単純に開発するのに2倍の時間がかかる

*4:これ以外にもリプレイス案件特有の問題(今動いているものが正、となってしまいあるべきの実装が分からない)や海外製端末問題などもあったということでした

*5:webview_flutterが怪しい、Flutter側とWebView内で表示するコンテンツのサーバ通信ではCookieを使わない方がいい

*6:独立したiOS/AndroidプロジェクトにFlutterの画面やDartのロジックをモジュールとして組み込む

*7:Google mapでメモリリークが起きたことはあった

*8:どちらかというとネイティブアプリよりサーバサイドも分かることを前提にしているということです