FlutterとSwiftどちらを選ぶ？両方で作って分けた基準

Swiftは言語で、その上にAppleが用意したSwiftUIというUIの仕組みがあります。Apple製の端末向けに作るための組み合わせです。

Flutterは、Googleが作っている開発の枠組みです。Dartという言語を使い、1つのコードからiPhoneとAndroidの両方を作れます。画面はFlutterが自分で描くので、どちらのOSでも同じ見た目になります。

違いはここで、同じ見た目になることは長所にも短所にもなります。そのOSらしさが薄れる面があるからです。利用者はそのOSの標準的な動きに慣れているので、少しの違いが「作りが荒い」と受け取られることがあります。逆に、両OSで同じ説明ができるのは運営する側の利点です。

もう一つ、実際に効いてくる違いがあります。OSの機能へ届くまでに何枚挟まるかです。SwiftUIならAppleの仕組みを直接呼びます。Flutterからは、間をつなぐ部品を通します。普通の画面を作るぶんには関係ありませんが、端末の機能を触るところで差が出ます。

一般論を書くより、実際の選択を並べるほうが早いので表にしました。難しさや流行では選んでいません。

下の表を見ると傾向が出ています。両OSに出すならFlutter、片方でよくてOSの機能を深く触るならSwiftUI。難しさで選んではいません。

選び方を言語の好みで決めていたころは、あとから困りました。書きやすさは慣れれば追いつきますが、出せないOSがあることは、あとから追いつけません。

下の表で一番下の行だけ、他と性質が違います。1本のアプリの中で分けた例です。次の節から順に説明します。

一番の理由は、AndroidとiPhoneの両方に出す予定があることです。1つ書けば両方に出せるので、画面を2回作らずに済みます。個人でやっていると、この差がそのまま作れる本数になります。

もう一つは、画面の数が多いアプリのときです。一覧、詳細、設定、投稿フォーム。こういう普通の画面が並ぶアプリは、Flutterで素直に組めます。

逆に、片方のOSにしか出さないなら、Flutterを選ぶ理由はかなり弱くなります。両方に出せる利点を使わないのに、間に1枚挟まる不便だけ受け取ることになるからです。

ここでいう不便は、主に端末の機能を使うときに出ます。OSが新しい機能を出しても、間をつなぐ部品が対応するまで使えないことがある。対応を待つか、自分でつなぐ層を書くかの選択になります。

⚠️ 「1つのコードで両方出せる」と「一度の確認で両方終わる」は別のことです。権限のダイアログ、通知の許可、課金、ストアの登録と審査はOSごとに残ります。この見積もりはiOSとAndroidどちらから作る？個人開発で見る六つの判断材料に分けて書きました。

iPhoneだけに出すと決めているときです。私はランニングのアプリをこれにしました。地図と位置情報が中心で、Apple側の仕組みをそのまま使えるほうが早いと判断したからです。

もう一つ、OSの機能に深く触る必要があるとき。返信アプリは本体をFlutterで作っていますが、キーボードの拡張だけはSwiftUIで書いています。キーボードはOS側の仕組みに深く入るので、間に枠組みを挟まないほうが素直でした。

このとき、本体と拡張で設定を共有する仕組みを別に用意することになりました。手間は増えますが、キーボード全体を無理に1つの枠組みへ寄せるより、結果的に楽でした。キーボード拡張で実際に詰まった点は「フルアクセスを許可」が怖い。Resuruのキーボードが何をするかに残しています。

1つのアプリの中で混ぜられるのは、知っておくと選択肢が増えます。全部をどちらかに寄せる必要はありません。混ぜる線は、OSの仕組みに深く入る境目に引くとうまくいきました。

ただ、SwiftUIを選んでもOSの機能が素直に使えるとは限りません。地図の部品を入れたら、こちらのコードには一行も書いていないのに既定で位置情報を分析目的へ送っていたことがあります。入れた部品の既定値は、どちらを選んでも読むことになります。

両方で作ってみて、まず分かったのは作る速さが思ったほど変わらなかったことです。差が出たのは、OSの機能に触る場面だけです。

Flutterから端末の機能を使うときは、間をつなぐ部品を探すことになります。良いものがあれば速いのですが、無ければ自分でつなぐ層を書くことになる。この「探して、無ければ書く」の往復が、地味に効きました。

逆に、画面をたくさん作る作業はFlutterのほうが速かった。同じ部品を使い回しやすく、両OSで確認する手間も減ります。

もう一つ、どちらを選んでも避けられない作業があると分かりました。ストアの審査、法務の文面、課金の設定、公開後の確認。ここは言語と関係なく発生します。作る部分だけを見て選ぶと、全体の見積もりを外します。

実感として、1本のアプリで言語を書いている時間は思ったより短い。設定画面を埋める、スクリーンショットを撮り直す、規約を実装と突き合わせる。こうした作業のほうが長く、そこはどちらを選んでも同じでした。

最後に、選ぶ前に書き出している順番を並べます。この五つを埋めると、選択肢はほとんど残りません。書けないなら、まだ作るものが決まっていないということでもあります。

1. 01　出すOSを決める。「いつか」は数えない

   ここが最初です。iPhoneだけでよいのか、Androidにも出すのか。「いつかAndroidにも」は決めたことになりません。半年以内に出さないなら、出さないものとして扱うほうが判断がぶれません。

2. 02　触るOSの機能を先に書き出す

   位置情報、カメラ、通知、キーボード拡張、ウィジェット、ウォッチ。OS側に深く入るものが多いほど、そのOSの標準で書く利点が出ます。

3. 03　自分が読める言語かどうかを見る

   個人開発では、書けるかより読めるかが効きます。動かなくなったときに、他人のコードや公式の説明を読んで直せるか。ここが詰まると止まります。

4. 04　外部サービスが対応しているか見る

   使う予定の認証、課金、地図、分析が、その組み合わせで動くか。ここは先に調べておかないと、途中で分かると作り直しになります。

5. 05　一番不安なところだけ先に作る

   地図が中心なら地図を、キーボードが要るならキーボードを。全体を作ってから詰まるのが一番高くつきます。

個人開発ならFlutterとSwift、どちらがおすすめですか？

出すOSで決まります。iPhoneだけならSwiftUI、Androidにも出すならFlutter。どちらが優れているかでは決まりませんでした。私は両方で作っていますが、選び分けの基準はこの一点です。

将来Androidにも出すかもしれない場合は？

出す時期が決まっていないなら、いまはiPhoneだけと考えて選ぶほうが進みます。決まっていない将来のために、いまの不便を引き受けると、そのまま止まることがあります。半年以内に出さないなら、出さないものとして扱っています。

途中で乗り換えられますか？

画面は書き直しになります。ただ、サーバー側やデータの構造は残るので、全部が無駄にはなりません。私は片方のアプリで、本体はそのままに一部だけ別の書き方にしました。

1つのアプリの中で混ぜても大丈夫ですか？

できます。返信アプリは本体がFlutter、キーボード拡張がSwiftUIです。線を引く場所は、OSの仕組みに深く入る境目にしました。代わりに、本体と拡張で設定を共有する仕組みを別に用意することになります。

両方できるようになるべきですか？

最初から両方は要りません。私は1本目をFlutterで作って、必要が出たところでSwiftUIを足しました。片方で一通り公開まで通すと、二本目の学習はかなり楽になります。審査も課金も公開後の確認も、言語と関係なく同じだからです。

どちらが学習しやすいですか？

どちらも一人で始められます。ただ、困ったときに読む資料の量は、作りたいものによって変わります。地図や位置情報ならAppleの資料が厚く、画面の組み方ならFlutterの情報が見つけやすい印象でした。作りたいものを先に決めてから選ぶと外しません。

SwiftUIのほうがOSの機能を安全に使えますか？

素直に呼べますが、安全かどうかは別です。地図の部品を入れたら、既定で位置情報を分析目的へ送っていたことがありました。入れた部品の既定値を読む作業は、どちらを選んでも残ります。

React NativeやKotlin Multiplatformはどうですか？

使っていないので書きません。使っていないものについては書かないと決めています。この記事で比べているのは、自分が実際に公開まで通した二つだけです。

比較記事を読んで決めようとすると、だいたい迷ったままになります。どちらにも良いところがあるからです。私が毎回やっているのは、比較を読むより先に出すOSと触る機能を書き出すことです。順番を変えるだけで、迷っている時間が短くなりました。

この記事では、性能の比較を書いていません。測っていないからです。体感では、私が作った範囲のアプリではどちらも差を感じませんでしたが、測っていないことを速いと書かないようにしています。

もう一つ書いていないのは、他の枠組みとの比較です。使っていないので、並べて語れる立場にありません。作る前の整理の全体像は個人でアプリを作るには？企画から公開までの七段階と止まる場所にまとめています。