はじめに
Flutterは、「モバイルアプリフレームワーク」という位置付けで紹介されることが多くなっています。「モバイルアプリフレームワーク」とは、「モバイル」つまり、AndroidとiOSを同じソースを共有して、同時に作成することができるもの。もちろん、厳密には100％同じソースとは言い切れない場合もあります。そこで、もう少し広義の意味では同じ言語でiOS／Androidのアプリ開発ができる場合であれば「モバイルフレームワーク」と呼ぶ場合もあります。
対象
筆者の主観が含まれてしまいますが、特にFlutterをおすすめしたい人は以下のような開発者です。
- モバイルアプリ開発をこれから本格的に始めたいWebアプリ開発者
- Androidアプリ開発者だが、iOSの開発も始めたい開発者
- React Nativeがなじめないと思っている開発者
- Apache Cordovaを卒業したいアプリ開発者
特に、上記に当てはまる方にはなじみやすいソリューションであり、もちろんそれ以外の方でも十分利用する価値があるフレームワークです。
Dartという言語
Flutterは、「Dart」という言語を使って開発をしていきます。多くの方にとって、少々聞き慣れない言語かもしれません。AndroidやiOSのためにJavaやSwiftなど別の新しい言語を覚えるのが大変なので、モバイルフレームワークを探している方にとっては良い印象を持ちづらいでしょう。できればすでに知っている言語でモバイルアプリ開発ができれば良いなと思っているところに、水を差されたような気持ちになった方もいるかもしれません。しかし、JavaScriptやJavaを知っている方であれば、Dartについてそれほど構える必要はありません。
これまで注目されてこなかったDart言語
もともと「Dart」は、JavaScriptの代替言語として2011年にリリースされました。そのため、TypeScriptと似ており、目的も同じのためおおよそ同等レベルの言語と捉えても良いです。また、Flutterを使ったモバイルアプリを作るために、Dartについて勉強していなくても大丈夫です。
Dart言語のメリット
TypeScriptは多くのソリューションにとって、バグなどが発生しにくいJavaScriptを書くための変換ツールにすぎません。筆者も以前はTypeScriptを使っていましたが、今では使わなくなってきました。その理由としては、TypeScriptで生成されたJavaScriptでの問題点を調査するということが発生するようになってきたからです。TypeScript自体の問題ではないのですが、TypeScriptを知っているけどJavaScriptを知らない開発者がいる状況が増えるなど、そういった問題が出てきたように思えます。
こういった中間ソリューションは、問題にぶつかったとき、その環境のネイティブ言語を扱っている場合に比べて問題が複雑になるため、解決方法が難しくなるケースがあります。そして、問題が解決できるくらいの知識がつくと、中間ソリューションがいらないほど、熟知してしまったということになります。
Dart言語も、TypeScriptのようにJavaScriptに変換するためのAltJSという利用方法もありますが、むしろ以下のようなメリットがあります。
- UIをブロックしない非同期処理や、UI定義もしやすいコレクション記述などUI処理を記述しやすい言語
- 開発しながら同時に動作を確認できるような生産性を考慮した開発環境
- AOTコンパイラによる幅広いプラットフォームにネイティブ対応が可能で、スマホ以外の利用も考慮
そして、DartはこのFlutterというモバイルフレームワークにとってはネイティブの言語であり、その利点がさまざまなところで生かされています。
モバイルアプリ開発の課題
Flutterの特徴や利点について紹介する前に、「モバイルアプリ開発」について説明しましょう。モバイルアプリについて開発したことがある方ならすでに知っているかもしれませんが、実際にWebアプリを作ったことはあるけどモバイルアプリはまだ無いという方も多数いると思います。
そのような方にとっては、いざモバイルフレームワークを採用して使って見ると、最初に重要と思っていた部分以外が実は重要であることに気がつくことでしょう。AndroidやiOS用のアプリを実際作ろうとすると、以下のようなさまざまな違いによる問題にぶつかります。
- 開発言語の違い
- 開発環境・ビルド環境の違い（iOSのアプリはMacでないと開発できないなど）
- APIの違い（端末のセキュリティや制約・方向性の違い）
- UIの違い（操作方法の違い）
モバイルフレームワークを選ぶ際に多くの方は、「開発言語の違い」に関心を持ちます。しかし、実際に開発を進めていけば「開発言語」の問題はそれ以外の問題に比べて大きくないことが分かります。特に、Macを使わない場合には、iOSの開発環境の違いなどを理解することが難しく、APIの違いも単に実装の違いから生じるものから、セキュリティや制約・方向性の違いがあります。
例えば、アプリがバックエンドになった場合に、Androidの場合では処理が動作していたのに、iOSでは処理が止まっていたということが発生します。また、プッシュ通知などではWiFi接続しているとiOSでは受信できるのに、Androidでは受信できないほか、iOSとAndroidでサポートされている画像や動画フォーマットの違いなど実際に使ってみないと気づきにくい部分もあります。
できることが同じであれば、APIの違いがあってもフレームワークが吸収してくれる場合もあります。しかし、各OSが持つセキュリティ制約などはフレームワークは吸収することはできません。また、内部で利用しているライブラリが違うために、異なる挙動になってしまうというケースもあります。もちろんフレームワーク側でできるだけ吸収しようとしますが、すべて対応しきれないのが現状です。実はこのように「言語の違い」以外にも、モバイルフレームワークがどの程度これらの違いを吸収できるのかも、大きな指標の1つです。
