はじめに

リンクラフトでモバイルアプリエンジニアとして働いている工藤です！
ありがたいことに今年は初めてテックリード的な立ち位置として、新規開発の Flutter プロジェクトに参画する機会をいただけました。
そこでこの記事では、業務で Flutter アプリを新規開発するときに、最初の基盤作りで行うことの列挙と概要をまとめます。

リンクラフトアドベントカレンダーの4日目を担当します。

コーディング規約 & lint 設定

多くのプロジェクトで Effective Dart という Dart 公式推奨のコーディング規約が採用されています。
Flutter では新しくプロジェクトを作成すると、ルート直下にanalysis_options.yamlというファイルが配置され、これが lint の設定ファイルになります。
デフォルトで flutter_lints という、Effective Dart の内容の多くを反映した設定が適用されています。

flutter_lintsの中身を確認した上で、追加したいルールがあれば analysis_options.yaml に追記しましょう。

# analysis_options.yaml のサンプル
include: package:flutter_lints/flutter.yaml

analyzer:
  exclude:
    # 自動生成ファイルは対象外
    - "**/*.g.dart"
    - "**/*.freezed.dart"

linter:
  rules:
    # 絶対パスでのimportを推奨
    - always_use_package_imports
    # import順序指定
    - directives_ordering
    # 文字列ではシングルクォートを推奨
    - prefer_single_quotes
    # コンストラクタ記載位置統一
    - sort_constructors_first
    # 変数が再割り当てされない場合はfinalを推奨
    - prefer_final_locals
    # 1行の80文字制限
    - lines_longer_than_80_chars
    # 等々...

アーキテクチャ & ディレクトリ構成決め

Flutter では MVVM や Clean Architecture がよく採用されますが、これといった「正解」があるわけではなく、その構成がプロジェクトにとって好ましいかどうかもケースバイケースです。
そのため、本記事では私が採用した具体的なアーキテクチャやディレクトリ構成の詳細は割愛します。
個人的には、開発メンバー全員が「なぜその構成にしたのか」を理解していることが一番大事だと考えています。

フレーバー分け

開発環境、検証環境、本番環境などを分ける対応になります。

私は自前でビルドコマンドから環境を切り替えるよう対応しましたが、flutter_flavorizr という諸々の設定を自動でやってくれるライブラリもあるようです。
フレーバー設定周りはかなり面倒だったため、次に新規開発に携わるときには採用したいと思います。

状態管理

Flutter は setState だけでもある程度までは開発できますが、画面数や機能が増えてくると必ず限界がきます。
状態管理の方法はプロジェクトの保守性やテスト容易性に直結するので、新規開発の最初の段階で決めておくことをおすすめします。
代表的なライブラリにprovider、flutter_riverpod、flutter_blocなどがあります。

私は flutter_riverpod を採用しました。
immutable なクラスを定義する freezed を併用することにより、状態を不変オブジェクトとして安全に扱いつつ copyWith による差分更新が行えるようになります。

ルーティング

画面遷移の制御方法を決定します。
Flutterでは go_router か auto_route のどちらかのライブラリを使用するのがメジャーですが、小規模アプリであれば Flutter 標準の Navigator を採用しても良いかと思います。

私は go_router + go_router_builder を採用しました。

導入検討の段階で auto_route に DeepLink 周りの不具合が含まれていたため go_router を採用しましたが、現在は解消されているようです。

APIクライアント

API通信の実装方針を決定します。
私は dio + retrofit を採用しました。

自動生成により記述量をかなり抑えつつAPIクライアント処理を実装できます。
競合として http が挙げられることが多いですが、こちらはシンプルな呼び出しに特化したものなので、エラーのラップやトークンのリフレッシュといった共通インターセプタを実装したい場合は dio を選ぶことになるかと思います。

多言語対応

複数の言語に対応する場合には必要になります。
後から対応する場合はかなり骨が折れるので、将来的に多言語に対応する可能性があるのであれば、導入しておいて損はないと思います。
単に翻訳のためだけでなく、「文字列の一元管理」という観点でもメリットがあります。
私は intl + flutter_localizations(FlutterSDK同梱) を採用しました。

レスポンシブ対応

要件にもよりますが、モバイルアプリ開発は iPhone、Galaxy、タブレットなど、様々な画面比の端末での使用が想定されます。

単純に画面比に合わせて Widget の拡大縮小を行うのであれば、flutter_screenutil で簡単に実現できます。
基準として設定した画面比との差異を検知して、Widgetのサイズを調整してくれます。

これも後から設定すると手間なので、最初に導入しておきましょう。
基準となる画面比は、デザインに合わせるのが一般的かと思います。

CI/CD

テストやビルド、配信の自動化についての方針を決めます。
私は GitHub Actions のワークフローから、iOS は TestFlight 経由、Android は Firebase App Distribution 経由でテスター向けに配信できるようにしました。

どちらも Firebase 経由にしなかった理由は、通常の Apple Developer Program に加入している場合、iOS アプリを Firebase App Distribution で配布するには Ad Hoc などのプロビジョニングプロファイルを使う必要があり、配布先デバイスの UDID を管理し続けないといけないためです。
テスターが多い場合や頻繁に入れ替わる場合、この運用がかなり面倒になります。

Apple Developer Enterprise Program に加入している組織であれば、Enterprise プロファイルを利用することで UDID 登録なしに Firebase 経由で配信することも可能なようなので、その場合は iOS / Android 両方とも Firebase に統一するのが良さそうです。
（ただし Enterprise Programは利用条件がかなり厳しくなっているようで、新規登録は難しい状態のようです。）

さいごに

今回は、業務で Flutter アプリを新規開発するときに、
自分が最初の基盤作りで意識しているポイントをざっくり列挙しました！

どれも「これが絶対の正解」というものではなく、
チームやプロジェクトの性質によってベストな選択は変わってくると思います。
この記事が、これから Flutter で業務アプリの新規開発に携わる方の
チェックリストのように機能することがあれば嬉しく思います！

一緒に働く仲間を募集中です！

リンクラフト株式会社では、組織拡大に伴い積極的な採用活動を行っています。
少しでも興味がある方はぜひご連絡ください。

▽会社ホームページ
https://lincraft.co.jp/
▽Instagram
https://www.instagram.com/lincraft.inc/
▽ご応募はこちらより
https://lincraft.co.jp/recruit

※カジュアル面談も受付中です。ご希望の方はHPのお問い合わせフォームよりご連絡ください。