iOS/Androidを15年以上ネイティブで作ってきて、それでもFlutterを選ぶ3つの場面

私がiOSとAndroidのアプリを作りはじめたのは、2009年です。iOSはObjective-CからSwiftへ、AndroidはJavaからKotlinへと言語は変わっていきましたが、ずっと”ネイティブ”——そのプラットフォームが本来サポートする言語——で作ってきました。iOSとAndroidを同時にリリースしたい案件では、SwiftのコードとKotlinのコードをエディター上で並べて、同じ画面遷移を同時通訳のように書き分ける。そういう作り方を、長くやってきたのです。

だから、私の中で「最高品質のアプリを作るなら、iOSはSwift、AndroidはKotlin」という結論は、いまも揺るぎません。ネイティブに勝るものはない、と本気で思っています。

それでも近ごろは、Flutter——iOSとAndroidを一つのコードで作れる、クロスプラットフォームのフレームワーク——を、あえて選ぶことがあります。今日は、その”どんなときに選ぶか”という判断の話です。

昔は、断っていました

実は、マルチプラットフォームに触れるのは初めてではありません。ずっと前、依頼を受けて Adobe AIR や React Native を試したことがあります。ただ、ネイティブで作り慣れた身からすると、当時はどうしても品質に満足できず、そういう依頼自体をお断りすることも多かった。正直に言えば、“避けていた”に近かったのかもしれません。

あれから何年も経ちました。次々と現れたマルチプラットフォームのフレームワークの多くが静かに姿を消していった中で、React Native と Flutter は生き残っています。それを見て、ふと考え直しました。これらの品質は、もう十分なところまで来ているのかもしれない、と。

「最高品質か」と「いま最高品質が要るか」は、別の問い

ここで大事だったのは、問いを分けることでした。「どちらが最高品質か」と、「この案件に、いま最高品質が要るか」は、まったく別の問いなのである。

ネイティブの本当の強みは、デバイスを”思いどおりに、タイミングまで”作り込めることです。たとえばBluetooth。1秒間にどれだけのデータが来て、そのすべてを取り込むのか、何ミリ秒に一度だけサンプリングするのか——こうしたシビアなタイミングの制御は、ネイティブでこそ、自分の思いどおりに書けます。カメラもGPSも同じで、iOSとAndroidで仕様の異なるデバイスを深く使う場面ほど、ネイティブの差が効いてくることは多々あります。

裏を返せば、そういう作り込みが要らないアプリなら、クロスプラットフォームで作っても、落とし穴に落ちるリスクはぐっと小さくなります。

クロスプラットフォームを選ぶ、3つの場面

では具体的に、私がクロスプラットフォームを選ぶ場面をまとめると、だいたい次の3つのケースに集約されます。

① まだ Product Market Fit が見えていない、アーリーステージのプロダクト。 使ってくれる人がいるかどうかも分からない段階で、iOSとAndroidの両方をネイティブで同時に作るのは、体力がいります。まずクロスプラットフォームで作って市場で検証すれば、もし外れても、ダメージは小さくて済む。初期投資額を抑えられる段階です。

② デバイスの高度な制御ではなく、UIでの情報提示が主のアプリ。 サーバーから情報を取ってきて画面に見せるニュースアプリ、写真を投稿・共有するアプリ——グラフィカルな表示が中心で、さきほどのBluetoothのようなシビアなデバイス制御がないもの。こういうアプリは、クロスプラットフォームが向いています。

③ 提供期間が限られたアプリ。 キャンペーンやイベント向けなど、期間限定のもの。②の条件（デバイスを深くは使わない）を満たしていれば、その後に長く進化させていく必要もありません。いまわかっている要件さえ実現できればいいので、見込みが狂いにくい。こういうときも、クロスプラットフォームの利点は大きいでしょう。

深く知っているからこそ、手放せる

この三つの線引きは、ネイティブコードでBluetoothやカメラ、GPS、各種センサー、外部デバイスとの接続といったプロジェクトを数多く担当してこなかったら、たぶん引けなかったと思います。

ネイティブで”何ができるか”を知っているからこそ、クロスプラットフォームにしたときに”何を手放すことになるか”が分かる。「ここは手放しても大丈夫」「ここは手放してはいけない」を、迷わずに線引きできるのである。深い経験は、こういう”引き算”の判断でこそ効いてきます。（この「深く広く知っている人ほど、判断が深くなる」という話は、別の記事にも書きました。）

だから、Flutterを学びはじめました

そういう場面で、お客さまに”クロスプラットフォームという選択肢”をきちんと出せるように——Flutter を選んで、実際に使いはじめました。

以前扱ったことのあるReact Nativeは選択しませんでした。React Nativeでは、サードパーティの依存関係のリンク周りに複雑な要素が絡む構造をそのとき目にして、これで作り続けることに未来はないと感じたからです。（ただ、その後React Nativeでイノベーションが起きている可能性はあります。）

正直に言えば、Flutterがどこまで使えて、どこで面倒が出るのかは、いま実際のプロジェクトのなかで見極めています。以前マルチプラットフォームで満足できなかった経験があるぶん、新しいツールを手放しで信じることはしません。ただ、長くネイティブをやってきた目だからこそ、その限界とちょうどいい使いどころを、早く正確に見抜けるはずだと思っています。見極めたことは、また追ってこのブログで書いていきます。

最後に

アプリを”どの技術で作るか”は、作り始めてしまう前の、いちばん効く判断のひとつです。最高品質のネイティブでいくのか、いまの目的にはクロスプラットフォームで十分なのか——そこは、案件ごとに変わります。

新しいアプリを考えていて、その入口の技術選定から相談したい、という方は、こちらからお気軽にどうぞ。