Flutter Advent Calendar 2023 2日目の記事です。
(時間過ぎてるのですが、シリーズ２の２日目が空いてるのが気になったので埋めましたｗ)
この記事は、YOUTRUST x ゆめみ Flutter LT会@渋谷 #3でプレゼンした内容を元にしています。
はじめに
単一のコードベースでAndroid・iOSに対応でき、開発体験が良いこともあってFlutterの人気は高まり続けています。とはいえ全てのアプリをFlutterで作ればいいとはならず、Flutterに不向きな要件というのもあります。
今回ゆめみのFlutterテックリードチームのエンジニアにFlutterに不向きと感じる要件・その理由を聞き込みました。技術選定の際の参考にしていただければと思います🫡
この記事で取り上げた要件を１つでも満たせば、Flutterを採用すべきではないという話ではないです。
総合的な判断のための参考としていただければと思います。
Flutter導入時に警戒すべき要件
プラットフォームに強く依存する要件がある場合（ヘルスケア・カーナビ系）
理由：共通して使えるpluginがあったとしても、個別のプラットフォーム実装について理解が必要で、Flutter採用によるシングルコード故の開発効率化が図りづらいから。一方で、上記要件のある案件でも、UI部分のみFlutter適用するなどの方式は効果的
アプリサイズを可能な限り削減したい
理由：Flutter コアエンジンを含めないといけない関係上、どうしてもアプリサイズが一定増える（約4MB）ため
App Clipは15MBの容量制限があった（iOS 17からは50MBに緩和されたが、NFCタグなどの物理呼び出しだと15MBのままとか）
高度なグラフィックを要する時 (3Dグラフィックやマップ等の大容量かつ複雑なデータを扱い描画する場合)
理由：
Impeller Scene を用いることでFlutter側で3Dグラフィックを表示することは可能だが 安定していない
PlatformViewを用いることで、既存のAndroid・iOS向けの資産(Ex. Google MapやMapBox)を利用することができるが、MethodChannelにて大量のデータをやり取りすると、画面・やり取り自体が重くなってしまいUXが悪くなってしまう
解決するためには非常に多くの工数を割かなければならないため それならネイティブで実装した方が安心で早い場合がある(それでも、高度なグラフィックを必要としない部分の共通化・ロジックの共通化という観点でFlutterを選ぶのもありなのかも)
できる限り早くプラットフォームの新機能をアプリに組み込みたい
理由：Flutter 自体やプラグインの新プラットフォーム対応を待たざるを得ず、新機能を早く対応するためにはネイティブのみでの開発に劣るため
iOS、Android でまったく異なるデザインシステム・UI/UX にしたい
理由：場合によってはこれでも選ぶ可能性はあるが、Flutter の最大のメリットであるはずのデザインシステム・UI/UX の共通化をしないということになると、メリットよりデメリットのほうが上回ってしまう可能性が高いため
まとめ
ゆめみのFlutterエンジニアに聞いたFlutter向きでない要件を紹介しました