はじめに

クロスプラットフォーム開発フレームワークの比較はとかく技術要素の議論になりがちですが、星取表での比較が正しい評価に繋がっていないように感じます。設計コンセプトや開発コンセプトがより重要で、それが非機能による現時点の使い勝手や機能・非機能の将来性に多大な影響を与えていると感じるからです。

本ブログでは各フレームワークの開発動機やコンセプトを中心にFlutter、React Native、Xamarinを比較したいと思います。

比較・検討

フレームワーク開発の究極の動機

Flutter	React Native	Xaamrin
技術力誇示・企業ブランド向上	技術力誇示・企業ブランド向上	技術力誇示・企業ブランド向上
フレームワークデバッグリソースの外部調達	フレームワークデバッグリソースの外部調達
社内アプリ開発の効率化	社内アプリ開発の効率化
モバイルアプリ開発業界の活性化

ここはReact Native vs Flutter - Which to Learn? - YouTubeを参考にプラスアルファしています。

XamarinのXamarin社にとっての存在意義はフレームワーク販売による直接的収益でした。
Xamarin社をマイクロソフトが買収したのはXamarinかなり成熟してからだったので、買収時点のマイクロソフトにとってのXamarinの存在意義は企業ブランド向上がメインだと感じてます。

FacebookがReact Nativeの開発に着手した直接の動機は「InfoQ: Facebook:「HTML5に賭けたのは間違い」発言の技術的な理由と反応」でしょう。それをわざわざOSSで公開するのは、アプリ開発者コミュニティーによるReact Nativeのデバッグと技術力誇示による企業ブランド向上が目的だと思います。

GoogleがFlutterの開発に着手した最初の動機も社内開発の効率化でしょう。特に、Material Designの実装を素のAndroid SDKで行うのは大変なものと想像します。実際、AndroidにおけるMaterial Designの実装はAndroid SDK版よりもFlutter版の方が進んでいるそうです。また、Googleの事業にとって最もクリティカルな外部向けモバイルアプリであるAdWordsの広告主向けアプリでFlutterをいち早く採用していることからも、その動機が見て取れます。
Flutterに特有の開発動機はモバイルアプリ開発業界を活性化したいというところでしょう。モバイルを含めたネット広告ビジネスに収益の基盤を持つGoogleならではの動機ではないでしょうか。これはアプリ開発者にとっては好都合です。Flutterに直接の見返りを求めず、アプリ開発者ファーストで開発を進めていることが、ツールチェーンやライブラリの整合性確保、ドキュメントの整備等に良い影響を与えているようです。

Widgetの捉え方

Flutter	React Native	Xamarin
Widgetの再発明	OEM Widgetの抽象化	(OEM Widgetの抽象化)
		OEM Widgetの活用

XamarinではOEM Widgetの有効活用を重視しているため、クロスプラットフォーム開発フレームワークではないと言われることがあります。
なお、Xamarin FormではOEM Widgetの抽象化も行っています。

React NativeはOEM WidgetをHTMLコンポーネント相当に抽象化していると言えばよいでしょうか。

FlutterにおけるWidgetの捉え方はかなり異なっています。先述のMaterial Designやアプリ固有ブランドUIを容易に構築するために、提供するWidgetのカスタマイズ性を重視しています。そのために深いクラス継承を避け、目的別の小さなコンポジットの合成によってWidgetが成り立っています。また、Widgetの配置・構成が動的に変化するMaterial Designやアプリ固有ブランドUIを容易に実現することも重視しています。そのために、JSXのような静的で宣言的なUIドメイン固有言語(DSL)を用いること無く、全てをDartで表現する道を選んでいます。加えて、Reactiveパターンを当初から念頭においたBuildパターン指向のWidgetにもなっています。これらを捉えて上記の表ではWidgetの再発明と表現しました。

対象アプリアーキテクチャ

Flutter	React Native	Xamarin
Reactive	Reactive	MVVM

React Nativeは当然ながらReactで一斉を風靡したReactiveパターンを採用しています。

FlutterもReactをリスペクトしてReactiveパターンを採用しています。
モバイルアプリ開発フレームワークの再発明ともいえます(ReactiveパターンはFacebookの発明ですが)。

(移行)ターゲット開発者 (プラットフォーム)

Flutter	React Native	Xamarin
Webフロントエンド	Webフロントエンド	Webバックエンド
モバイル
その他

C#の最大の利用シーンはWebバックエンドでしょうか。Xamarinでは、ともかくC#が好きな人がモバイルアプリもC#で開発できるようにした、というように感じます。

React Nativeはその名の通り、ReactでWebフロントエンドを開発していた人が、そのままモバイルアプリも開発できるようにした、ということでしょう。

Flutterはより野心的で、既存のモバイルアプリ開発者、Webフロントエンド開発者を中心に、Webバックエンドを含んだ開発リソースを広くモバイルアプリ開発に動員しようという気概を感じます。ちなみに、Flutterプロジェクト開始された時点で、DartはWebフロントエンドとWebバックエンドを主なターゲットとしていました。

(移行)ターゲット開発者 (プログラミング言語)

Flutter	React Native	Xamarin
Javascript	Javascript	C#
Java
Objective-C
(Kotlin)
(Swift)

繰り返しになりますが、XamarinにおけるC#採用の動機は、C#利用者をモバイルアプリ開発に動員することでしょう。
C#愛を感じます。

React NativeによるJavascript採用の動機も、Javascrip利用者をモバイルアプリ開発に動員することでしょう。
Javascriptの影響力を感じます。
もっとも、Javascriptの採用は副次的で、より重要なのは先述のWebフロントエンド開発者を動員することだと思いますが。

FlutterにおけるDart採用の動機は、オブジェクト指向言語全般の利用者をモバイルアプリ開発に動員することでしょう。
特に、Webフロントエンド開発、React Native、Cordova、Ionic等によるモバイル開発でJavascriptを利用している開発者、まだJava、Objective-Cを利用しているモバイルアプリ開発者にとって、よりモダンなDartが魅力になると考えているようです。Dartでは奇抜な構文を避け、あえて平凡な言語にしているのもそのためです。
ちなみに、現在FlutterのPMを行っているHixieさんは以前はHTML5の仕様取りまとめを行っていた人です。そのためか、Web開発者のFlutterへの移行容易性にはDart言語レベルで非常に気を使っているようです。
当然ながら、KotlinやSwiftの利用者にも訴求したいところですが、現状のDartの実力はそこまではないでしょう。ともかく、移行のハードルが低ければそれで良い、という感じです。とかくDartはKotlinやSwiftとの比較において、その言語機能について批判されがちですが、Flutterチームはそこまで言語機能を気にしている様子はありません。むしろ非機能(JIT+AOTコンパイル、高速なオブジェクトメモリアロケーション&GC)を重視してDartを採用したそうです。DartチームはData Classや非NULL型の導入に邁進していますが。

さいごに

既に筆者がFlutter押しであることを感じていると思いますが、それは主に宗教(Google教)的理由からです。
ともあれ、機能要素の星取表の比較ではないコンセプトベースの比較をすると違った景色が見えてくると思いますので、試してみてください。