はじめに
約4年前（2021年頃）、動画配信サービスのモバイルアプリをFlutterで開発しました。動画ストリーミング、アプリ内課金、プッシュ通知など、商用サービスとして必要な機能を一通り実装したアプリです。
TODOアプリやサンプルではなく、実際にユーザーが課金するサービスをFlutterで作ってみてどうだったのか。当時の判断と、4年経った今の振り返りを交えてまとめます。Flutterを検討している方、クロスプラットフォーム開発で悩んでいる方の参考になれば幸いです。
プロジェクト概要（商用動画配信アプリ）
映画・ドラマ・アニメをストリーミング配信するVODアプリを、iOS/Androidの両プラットフォームで提供しました。
ユーザーは、
- ポイント購入による個別作品レンタル
- 月額の定期購読プラン
■ 規模感
- 画面数: 約30画面
- 主要機能:
- 動画ストリーミング再生（DASH/HLS）
- アプリ内課金（ポイント購入・定期購読）
- 検索
- ユーザー認証
- プッシュ通知
- ペアレンタルコントロール
- デバイス管理
「ちょっとしたアプリ」ではなく、課金・認証・動画再生を含む商用サービスです。この規模のアプリをFlutterで開発するとどうなるのか、実際の経験をもとに紹介します。
Flutterを採用した理由（当時の判断）
当時の状況は以下の通りでした。
- iOS/Android両方にアプリを出す必要がある
- 開発チームは少人数
- 短期間でのリリースが求められていた
同じUIとビジネスロジックを2つのネイティブコードベースで維持するのは、この体制では現実的ではありませんでした。単一のコードベースで両プラットフォームに対応できるFlutterが、最も効率的な選択肢でした。
また、ダークテーマベースのメディアリッチなUIが特徴のアプリだったため、ピクセル単位で描画を制御できるFlutterのレンダリングエンジンは相性が良いと判断しました。
【今振り返ると】
この判断は正しかったと思います。少人数チームでiOS/Android両対応を実現する、という要件に対してFlutterは今でも最も現実的な選択肢の一つです。
Flutterで開発して感じたメリット
実際に開発してみると、Flutterのメリットは想像していたよりもはっきりしていました。特に印象に残っているのは次のような点です。
■ プラットフォーム固有処理は思ったより少ない
クロスプラットフォーム開発で一番心配だったのが「結局プラットフォームごとに書くことになるのでは？」という点です。
結果として、プラットフォーム分岐が必要だったのは主に3箇所でした。
- 動画フォーマット: iOSではHLSが標準、AndroidではDASHまたはHLSが使われる
- 課金の商品ID: iOS/Androidで体系が異なる
- デバイス情報ヘッダー: 端末の識別方法がOS間で違う
たとえば動画フォーマットの差異は、たった2行で対応できました。
// iOS用にDASH→HLSに変換
url = url.replaceAll("dash", "hls");
url = url.replaceAll(".mpd", ".m3u8");デバイス情報も、1つのメソッド内でPlatform.isAndroidを分岐するだけで完結します。ネイティブなら同じロジックを2箇所に書くところが、1箇所で済むのは大きなメリットでした。
【今振り返ると】
この「プラットフォーム分岐が数箇所で収まる」という感覚は、今のFlutterでも変わりません。むしろパッケージの成熟により、当時より楽になっている部分もあります。
■ Atomic DesignとWidgetの相性が良い
UIをAtomic Design（atoms / molecules / organisms / pages）で整理しました。
小さなWidgetを組み合わせてUIを構築していくFlutterの思想と自然にフィットしました。
【今振り返ると】
UIの設計手法としてAtomic Designが最適かは議論がありますが、「コンポーネントを階層的に整理する」というアプローチ自体はFlutterと相性が良く、今でも有効だと感じています。
苦労した点
■ 動画プレイヤーの安定性
動画再生にはbetter_playerを採用しましたが、当時はまだ1.0未満の段階で不安定でした。ネイティブのAVPlayer / ExoPlayerをラップしたパッケージのため、プラットフォーム固有のエッジケースに悩まされました。
動画再生はアプリの中核機能です。これをサードパーティパッケージに強く依存させたことは、大きなリスクでした。
【今振り返ると】
現在はvideo_playerをベースに独自UIを構築する方法や、media_kitなど選択肢が増えています。ただし、「動画再生の品質がアプリの評価に直結する場合、Platform Channelでネイティブプレイヤーを直接制御する選択肢を持っておくべき」という教訓は今でも有効です。メディア系アプリを作る人は、ここが一番の検討ポイントになるはずです。
■ アプリ内課金のプラットフォーム差異
最も苦労したのが課金処理です。iOS（StoreKit）とAndroid（Google Play Billing）で商品IDの体系が異なり、レシート検証もそれぞれ別ロジックが必要でした。
// 同じポイント商品でもプラットフォームでIDが異なる
final List<String> _consumableIds = <String>[
Platform.isAndroid ? 'cp9120050' : 'cp9119050',
Platform.isAndroid ? 'cp9120100' : 'cp9119100',
// ...
];クロスプラットフォーム」と言いつつ、課金に関しては両プラットフォームの仕様を深く理解する必要がありました。
公平に言えば、この複雑さはFlutterの問題ではなく、iOS/Androidの課金システムそのものの差異に起因します。ただし、ネイティブ開発なら各プラットフォームの公式サンプルがそのまま使える分、ハマりどころは少なかったかもしれません。
【今振り返ると】
アプリ内課金のプラットフォーム差異は4年経っても本質的に変わっていません。
RevenueCatのようなサービスを使う選択肢もありますが、課金はFlutterに限らずクロスプラットフォーム開発で最も注意すべきポイントです。これからFlutterで課金を実装する人は、ここに一番時間を取られることを覚悟しておいた方がよいです。
■ テスト・CI/CDへの投資不足
少人数で短期リリースを優先した結果、テストとCI/CDが後回しになりました。課金や認証というクリティカルな機能を持つアプリでありながら、テストカバレッジが不十分だったのは反省点です。
【今振り返ると】
これはFlutterの問題ではなくプロジェクト運営の問題ですが、「少人数で速く出す」ことを理由にテストを省くと、後で必ず痛い目にあいます。Flutterはflutter testやインテグレーションテストの仕組みが整っているので、次にやるなら最初から活用します。
Flutterはどんな案件に向いているか
4年間の経験と現在のエコシステムを踏まえた所感です。
■ 向いている案件
- iOS/AndroidでUIがほぼ同一のアプリ: 動画配信、EC、ニュースなどコンテンツ消費型は最適。
- カスタムデザインのアプリ: ダークテーマや独自ブランドデザインではFlutterの描画自由度が活きる。OSのデフォルトUIに従うアプリでは逆にこの利点は薄い。
- 少人数チームでの開発: 1〜3名でiOS/Android両対応するなら、最も現実的な選択肢。
■ 慎重に検討すべき案件
- ネイティブ機能に深く依存するアプリ: AR、高度なカメラ制御、OS固有UI多用の場合。
- メディア再生品質が最重要なアプリ: Platform Channel併用かネイティブ開発を視野に入れるべき。
他の技術と比較した印象
■ vs React Native
Flutterは独自レンダリングエンジンで描画するため、ネイティブUIコンポーネントに依存せず、iOS/Androidで完全に同じ見た目を再現できます。デザインの一貫性が重要なアプリでは大きなアドバンテージです。
また、Dartの型安全性はエラーハンドリングやAPIレスポンスの処理で安心感があります。
一方で、React NativeはJavaScriptの広大なエコシステムを活用でき、Web開発者の参入障壁が低いです。チームの技術スタックに合わせて選ぶのがいいと思います。
【今振り返ると】
React Nativeも新アーキテクチャ（Fabric, TurboModules）で大きく進化しています。4年前と比べて両者の差は縮まっていますが、「UI一貫性」と「描画性能」ではFlutterに依然として分があると感じます。
■ vs ネイティブ（Swift / Kotlin）
ネイティブなら動画プレイヤーや課金で苦労した部分は軽減されていたはずです。AVPlayer / ExoPlayerを直接使え、公式サンプルもそのまま適用できます。
ただし、約30画面のUIとビジネスロジックを2つのコードベースで維持するコストは無視できません。少人数チームにとって、2倍の開発・保守コストは現実的ではありませんでした。
「プラットフォーム固有機能の深さ」と「開発リソースの制約」のトレードオフです。
今後Flutterを使うか
結論として、同種のプロジェクトでは引き続きFlutterを選択すると思います。
ただし次にやるなら、テスト基盤やCI/CDは初期段階から整備します。また、動画再生のようなアプリの中核機能については、サードパーティパッケージだけに頼らずPlatform Channelでネイティブプレイヤーを直接制御する選択肢も最初から持っておくべきだと感じました。
まとめ
実際にFlutterで商用アプリを作ってみると、「どんなアプリにも万能」というわけではありませんでした。動画プレイヤーの安定性や課金処理では確実に苦労しますし、プラットフォーム固有の知識が不要になるわけでもありません。
しかし、少人数チームでiOS/Android両対応を実現するという現実的な課題に対しては、非常に強力な選択肢だと感じています。
4年前のプロジェクトを振り返ってみても、「Flutterを選んだこと自体」は間違っていなかったと思います。技術選定の判断基準、苦労ポイント、改善点は4年経っても通用するものばかりでした。
この記事が、Flutterで商用アプリを開発する際の参考になれば幸いです。
システムデザイン開発は、北海道の地で創業40年を迎えます。企業向けのシステム設計～開発・構築～保守運用までワンストップサービスを提供するシステム開発会社です。豊富な開発実績と高い技術力を強みとして、北海道から全国へ幅広い分野・業種へトータルにサポートいたします。
システムの導入やご検討、お困りごとがありましたら、お気軽にご相談・お問合せください。
