Zenn
🚀

【Flutter個人開発】最初にやって良かった・やっておけば良かった事などリリース後の振り返り

に公開
個人開発
メモ
idea

掲題通り、アプリをリリースした後の振り返りをします。
これから個人開発を始める方の参考になれば幸いです。

最初にやっておけば良かったこと

1. ローカライズ対応（多言語化）

後から追加するのは非常に工数がかかります。
最初から組み込んでおくべきでした。
私は今まさしくこの現実にぶち当たり、大変なので記事の執筆に逃げています。

  • flutter_localizations
  • easy_localization
  • intl

基本何でも良いですが、拘りなければflutter_localizationsが公式パッケージで最も一般的かと思うのでこれで良いかと思われます！

2. 強制アップデート

最初の頃はどうしても細かなバグや機能追加などバージョンアップが多いかと思います。
例えば、↓みたいな感じの「お知らせ機能」作って、バージョンアップしてね〜って促しても良いんですが、アップデートしないユーザーも一定数はいると思うので！
遅かれ早かれ必要なら先にやるべきでした。


3. CDによる自動ビルド

手動ビルドめんどくさいっす！！
ヒューマンエラーの防止にも繋がるし自動化したい！
CIしか入れてない！

  • Codemagic
  • bitrise

とかあるけど、基本GitHub Actionsで良いかな〜って思います！

4. 広告の導入

リワード入れておけば良かったかな〜。と。
サブスクリプションは後でで良いけど、こっちは先に入れて1円でもお金にしておく仕組みを作っておくべきでした。

先にやって良かったこと

1. MVPで早期リリース

機能を最小限に絞り込むことで、早期リリースしました。
開発期間は2ヶ月です。

作ってくと「あれもこれも」となりますよね。
でも最初は機能を詰め込まず、コア機能に集中してリリースすべきです！
必要なら後でアプデしましょ。

2. 共通のデザインシステムの構築

開発速度の向上をはじめ、一貫したデザイン、デザイン変更時の効率的な対応が可能になります。
↓こういうやつ。
TextStyles の例

abstract final class TextStyles {
  static const String _notoSans = 'NotoSansJP';
  static const String _roboto = 'Roboto';
  const TextStyles._();

  // 見出し（18px, Medium）
  static const TextStyle h1Med18 = TextStyle(
    fontWeight: FontWeight.w500,
    fontSize: 18,
    height: 1.33, // 24/18 = 1.33
    fontFamily: _notoSans,
  );

Color の例

abstract final class Colors {
  const Colors._();
  // メインカラー（白）
  static const Color mainColor = Color(0xFFFFFFFF);

  // メインテキストカラー（濃いグレー）
  static const Color mainTextColor = Color(0xFF575756);

3. 静的解析ルールの設定（analysis_options.yaml）

コード品質を保ち、バグを未然に防ぐために大事っす。
個人開発でも、後から見返した時にコードの品質が保たれていると助かります。
あと、const とかも自動付与出来るのでシンプルに効率良いです。
↓こういうやつ。

# Lintルールの設定
linter:
  rules:
    # スタイル関連
    prefer_single_quotes: true # シングルクォートでないと警告が出る
    require_trailing_commas: true # 末尾カンマを必須に
    always_use_package_imports: true # インポートは絶対パスにする（相対パスでインポートすると警告が出る）
    directives_ordering: true # インポート順序を強制
    sort_child_properties_last: true # Widgetのchildを最後に配置

    # エラー防止
    avoid_annotating_with_dynamic: true # dynamicで型をつけると警告が出る（dynamicアノテーションを禁止）

    # パフォーマンス
    avoid_unnecessary_containers: true # 不要なContainerを禁止
    prefer_const_constructors: true # 可能な場合はconstを使用
    prefer_const_declarations: true # 定数宣言にconstを使用

4. バックエンドサービスの選定・一元管理

若干が話それますが、Twitter 徘徊していると下記の記事を見つけました。

https://x.com/dshukertjrjp/status/1923256239707828267

SupabaseをただのPostgres DBとしてと使っている..???
なるほど！それも一意見として良いと思います！

でも私はBaaSとして使いたいです！

  • 認証
  • DB
  • ストレージ

全部をSupabaseで使いたいです。
例えばストレージだけS3（AWS）使っても同様の機能を提供出来るでしょう。
しかしその場合、AWSアカウントの作成、IAMの設定やパスワードポリシーの設定、budgetの設定などAWSのアカウント初期設定は結構多いです。
ユーザーからすれば、これらの技術選定はどうでも良い部分です。
正味、大半は我々のエゴです。

であれば、まずはMVPでやってるので出来ることは1つにまとめたい。というのが指針です。

落ち着いたらやること

1. 監視・分析ツール

下記の2つは入れたいな〜と思ってます。

  • Firebase Analytics
  • Firebase Crashlytics

チケットは切ってます！
やれたらやります！（行けたら行きます論）

2. サブスクリプション

絶対にやりたいです。
アプリで得たお金で肉食いたいです。

まとめ

個人開発では「完璧を目指さず、まずはリリース」が重要ですが、最低限の基盤は整えておくと後が楽になります。
特にデザインシステムとCIは、早期に導入することで効率が大幅に向上しました。
一方で、ローカライズ対応は後から追加すると工数がかかるため、初期段階で検討すべきでした。あとCDも。

次回の個人開発では、これらの経験を活かしてより効率的に進められそうです。
失敗は成功の元！

Discussion