さまざまなモバイルフレームワークの特徴
現在、すでに「モバイルフレームワーク」がほかにもあるので、それらとFlutterを比較するとより特徴が分かります。
Flutterとそれ以外のモバイルフレームワーク
Flutter以外のモバイルフレームークには、主に表1のようなものがあります。
| モバイルフレームワーク | 概要 |
|---|---|
| Apache Cordova | スマホ内のブラウザエンジンを利用したオープンソースのフレームワーク |
| React Native | Facebookが開発したJavaScriptで開発できるオープンソースのフレームワーク |
| Xamarin | Microsoftが提供しているフレームワークであり、VisualStudioに統合 |
上記以外にもありますが、これらを利用した拡張フレームワークであったり、同様な技術基盤であったりします。従って、上記のフレームワークの特徴から生じるメリットやデメリットが分かれば、自分たちにとってどのようなモバイルフレームワークが向いているのかが分かるはずです。
Web文化とモバイルネイティブ文化の違い
モバイルフレームワークには、「既存の開発者」をどうやって取り込むかという考えがあります。「既存」とは、具体的にはどのような技術や経験を持っている開発者を想定しているかということです。その違いで、モバイルフレームワークで大きく特徴が変わります。各フレームワークが、どのようなほかの文化背景を持つターゲットにとって移行しやすいかを示したものが図1です。
Apache Cordovaは、Webアプリ開発者を対象にしており、スマホ専用の文化をあまり知らなくても良いように考えられています。従って、スマホアプリを作っているというよりは、Webアプリがそのままスマホアプリになるといった感じです。
XamarinはC#開発者向けのモバイルフレームワークです。ほかのフレームワークに比べると「開発言語の違い」に重点を置いており、C#でネイティブアプリとほぼ同じことができます。この2つのフレームワークはある意味大きく割り切っているので、対象とその適用範囲が分かりやすいフレームワークです。
そして、最近非常にモバイルフレームワークとして大きな候補になっているのが、React Nativeです。ReactというWebアプリでも使えるフレームワークをそのまま引き継いでいます。しかも、アプリにも適用でき、かつ、スマホ特有の問題に対してもある程度の対応が可能です。Reactは、Web開発でも広く使われつつあるので、そのようなターゲットに対しては大きなアドバンテージがあります。また、Web技術を使いつつ、ネイティブと同じようなUIが提供できるので、Apache Cordovaでは少々物足りなく、しかしネイティブ言語まではやりたくないという方にとってはちょうど良いソリューションです。
Flutterは、React Nativeを強く意識した後発のフレームワークです。そのため、React Nativeを検討したい開発者にとっては、Flutterも検討する価値があります。
アーキテクチャーから見たモバイルフレームワークの違い
各モバイルフレームワークをアーキテクチャーから違いを見てみましょう。Flutter以外の3つのフレームワークのアーキテクチャーを、UIとその他の処理をどのように処理しているかを記述したものが図2です。ただし、これらの図は特徴を分かりやすく記述したものなので、すべての処理がこの通りに動作していることを示しているわけではありません。
Apache Cordovaを見ると、WebViewというスマホ内のブラウザエンジン上で動いています。そのため、Webアプリと同じ知識でアプリを作成できます。一方で、スマホ内のブラウザエンジンは同じではなく、特に古いAndroidのバージョンは現在のものと制限などが異なるので、Webアプリと同じブラウザの差異を意識する必要があります。つまり、スマホアプリにもかかわらず、Webアプリと同じようにブラウザの挙動の違いで苦しむ場合もあります。
そして、アプリといっても実際にはWebアプリと同じブラウザ上で動作するのでネイティブアプリならではのUIが作れないという問題があります。そのような問題点を回避しつつ、Webテクノロジーを使っているのが、React Nativeです。React Nativeは、ネイティブUIをラップしたコンポーネントを用意し、それらのコントロールをJavaScriptエンジンで行います。そのため、UI部分での表現力や表示速度などもネイティブアプリと遜色なく開発が可能です。Apache CordovaやReact Nativeも、JavaScriptでコードを記述できるものの実現方法が全く違うため、特性は異なります。言語だけで判断してしまうと、このような違いが見えません。
一方、XamarinはUIだけではなく、OSが提供しているさまざまなAPIをC#でラップしたAPIを提供しています。そのため、iOSやAndroidが提供しているAPIをC#から実行可能です。また、各種OSに依存しない処理は、Monoという.Netのランタイム技術を使って動作することもできます。
Xamarinは、Apache CordovaやReact Nativeに比べれば、ネイティブアプリを開発するための言語をJavaやSwiftなどからC#に置き換えることができるといったイメージに近いです。そのため、共通フレームワークというよりは言語の共通化の特性が強くなります。ただし、Xamarinもそのような問題点を解決するために、Xamarin.Formsというより抽象度の高いAPIも提供しているため、それらを使うことで共通フレームワークとして利用することも可能です。
それぞれのフレームワークで苦手な部分を補うためのソリューションなどはほかにもあります。実現性の有無だけに注目するとより違いが少ないように見えてしまいますが、何を得意としているかなどアーキテクチャーを見て判断できれば、より自分にあったフレームワークを選択することができるでしょう。
そして、Flutterのアーキテクチャーを示したものが、図3（左）です。参考までに、Androidのアーキテクチャーも図3（右）に示しました。
これらを見ると、ほかのフレームワークに比べて、内部で他の技術を利用していないことが明確であるほか、Androidと同じようなアーキテクチャー構造であることも分かります。つまり、このような構造は、OS以外の制限を受けないようにしています。
筆者は、このようなアーキテクチャーを見て、「モバイルフレームワーク」というよりは、新しいAndroidアプリのSDKを目指していると感じました。そして、Android用にアプリを作るとそのアプリがiOS上でも動かすことができます。
DartVMは、Windows上でもMacOSやLinuxでも動作しますので、Flutterは将来、デスクトップ版やスマホよりも小さい組み込み機器にも利用できるようになるはずです。そして、Googleはそういった目的のためにFuchsiaというOSも開発しており、そこで利用できる言語としてDart／Flutterがあります。このようにFlutterは、現時点ではモバイルフレームワークという位置付けですが、目指す将来はほかのモバイルフレームワークとは異なっています。
