2024.10.25 フレームワーク

FlutterとReact Nativeの違いと選び方｜Flutterとは何かから2026年の判断基準まで

FlutterとReact Nativeは、どちらも1つのコードでiOSとAndroidのアプリを作るための道具です。ただし両者は同じ問題を別の方法で解いており、比べるべきなのは機能の多さではありません。決定的に違うのは「画面のピクセルを誰が描くか」という1点で、言語の違いも、UIの再現性も、性能の議論も、すべてここから派生します。この記事ではまずFlutterとは何かを読み方・言語・構造の3点で押さえ、そのうえで2026年9月時点の仕様を一次情報で確認しながら選定の判断基準までを整理します。

まとめ

React NativeはMetaが開発するフレームワークで、OSが持つネイティブUI部品をJavaScript側から操作します。FlutterはGoogleが開発し、Dartで書いたコードを自前のレンダリングエンジンImpellerで描きます。読み方は「フラッター」、言語はDart、描画はエンジン内蔵。この3点がFlutterの正体です。

この違いから、既存のWeb・Reactの資産とチームをそのまま生かしたいならReact Native、OS間で寸分違わぬ同一デザインを再現したいならFlutter。選定はここでほぼ決まります。

2026年に注意すべきなのは、数年前の比較記事がほぼ使えなくなっている点です。React Nativeは0.82でレガシーアーキテクチャへの後戻りができなくなり、0.87ではStrict TypeScript APIが全プロジェクトの既定になりました。Flutterは3.27以降Impellerが既定で、3.47ではmacOS・Windows・Linuxにも既定が広がっています。旧来の「Skiaのシェーダコンパイルによるカクつき」を前提にした議論は、もう成り立ちません。

Flutterとは何か：Dartで書き独自エンジンが全画面を描くSDK

Flutterとは、Googleが開発しているオープンソースのUIツールキットです。1つのコードからiOS・Android・Web・Windows・macOS・Linux向けのアプリを作れます。2018年12月に1.0が安定版となり、ライセンスはBSD-3-Clauseです。2026年9月9日にリリースされた3.47.3が、本記事の確認時点の安定版になります。

Flutterの読み方は「フラッター」で、指す範囲は3層ある

読み方は「フラッター」です。flutterは「羽ばたく」「小刻みに揺れる」という意味の英単語で、日本語の記事やドキュメントでもこの表記が使われます。「フラター」と書かれることもありますが、指しているものは同じです。

ややこしいのは、Flutterという語が指す範囲が1つに決まっていない点にあります。Flutter公式のアーキテクチャ解説では、Flutterは階層化されたシステムとして説明されています。上からDartで書かれたフレームワーク層（MaterialやCupertinoなどのウィジェット群）、C++で書かれたエンジン層（描画・テキストレイアウト・プラットフォームチャネル）、OSごとの埋め込み層（Embedder）という3層構造です。

「Flutterの言語はDart」というときに指しているのは最上層のフレームワークで、「Flutterは自前で描画する」というときに指しているのは中間のエンジン層。同じ「Flutter」でも層が違います。この区別を先に付けておくと、後述するReact Nativeとの比較がぶれません。

Flutterの構造：ウィジェットツリーからImpellerの描画まで

実装者から見たFlutterの構造は、ウィジェットを入れ子にしたツリーです。画面はすべてウィジェットで、余白を作るPaddingも横並びにするRowも、状態を持つStatefulWidgetも同じ土俵に並びます。ウィジェット自体は画面の設定値を束ねた不変のオブジェクトで、実体を持ちません。

このウィジェットツリーから、フレームワークがエレメントツリー（画面上の実体と寿命を管理する層）とレンダーオブジェクトツリー（大きさと位置を計算して描画命令を出す層）を組み立てます。状態が変わるとウィジェットツリーは作り直されるものの、エレメント側は差分だけ更新されるため、毎回まるごと組み直す書き方でも破綻しません。この使い分けはStatelessWidgetとStatefulWidgetの違いと判定基準で整理しています。

最後に描画命令を受け取るのがImpellerです。ここまでの流れがFlutterの内側で完結するため、OSのUI部品は一度も登場しません。この「登場しない」ことが、次章で扱うReact Nativeとの根本差になります。

Flutterの言語がDartである理由と現行のDart 3.13系

Flutterの言語はDartです。Googleが開発した言語で、型が明示的なクラスベースの文法であり、TypeScriptやJavaの経験があれば読み書きの習得に難所は少ないほうです。FlutterがDartを選んでいる理由は、同じ言語で2通りのコンパイル経路を持てる点にあります。開発中はJITで動かして画面を書き換えたまま反映するhot reloadを効かせ、リリースビルドはAOTでネイティブコードへ落とす、という使い分けです。

Dartの版はFlutterに同梱される形で決まります。2026年9月9日の安定版Flutter 3.47.3に入っているのはDart 3.13.3です。言語単体の特性と開発会社を選ぶ観点はDartとは？Flutterとの関係・将来性と開発会社を選ぶ判断軸にまとめました。SwiftやKotlinを含めた言語選定そのものを迷っているなら、アプリ開発の言語選定：Swift・Kotlin・Dartの分岐条件を先に読むほうが遠回りになりません。

flutter doctorで採用可否の前提条件を確かめる最小手順

Flutterを採用できる環境かどうかは、手を動かして確かめるのが早い。公式のインストール手順に従ってSDKを入れたあと、次の2コマンドで版と不足物が分かります。

$ flutter --version
Flutter 3.47.3 (channel stable) / Dart 3.13.3

$ flutter doctor
[OK] Flutter (Channel stable, 3.47.3)
[OK] Android toolchain - develop for Android devices
[!] Xcode - develop for iOS and macOS
[!] Android Studio (not installed)

doctorは足りないコンポーネントを1行ずつ並べるので、iOSビルドまで必要ならXcode、Androidだけで足りるならAndroid SDKと、そろえる範囲を切り分けられます。OS別の詰まりどころはFlutterの環境構築とflutter doctor診断で扱いました。なお3.47でmacOSの最小サポートが12（Monterey）へ上がり、Intel Mac環境ではdoctorが警告を出します。公式のサポート対象プラットフォーム一覧では、macOSはMonterey（12）からTahoe（26）までが対象です。開発機の世代は採用前に確認しておく条件です。

UIを誰が描くかという根本差：ネイティブ部品の操作か、自前描画か

ここから比較に入ります。React Nativeは2015年3月にFacebook（現Meta）がオープンソース公開したフレームワークで、ライセンスはMITです。FlutterはGoogleが開発し、前章のとおり2018年12月に1.0が安定版となりました。どちらも開発元が自社プロダクトで使い続けている点は後述します。

React Nativeの描画：OSのUI部品をJavaScriptから動かす

React Nativeで書いた<Text>や<View>は、実行時にiOSならUIView、Androidならandroid.view.View系の実物へ対応づけられます。画面に出ているのはOSが用意した本物のUI部品です。

この設計の利点は、OSがバージョンアップしてデザインや操作感を変えたとき、アプリ側が何もしなくても追随することにあります。文字選択の挙動、アクセシビリティ、日本語入力の変換候補の出方といった、自前で再実装すると必ず粗が出る領域をOSに任せられるわけです。裏返せば、iOSとAndroidで見た目が完全には揃いません。揃えたい場合はプラットフォームごとの分岐を書くことになります。

Flutterの描画：Impellerが全ピクセルを自前で描く仕組み

FlutterはOSのUI部品を使いません。キャンバスを1枚もらい、ボタンもテキストも自前で描きます。描画を担うのがImpellerで、Impellerの公式ドキュメントによればFlutter 3.27以降、iOSとAndroid API 29以上で既定のレンダリングエンジンです。iOSではImpellerのみが提供され、Skiaへの切り替えはできません。AndroidではAPI 29以上かつVulkan対応の端末でImpellerが動き、それ以外は従来のOpenGLレンダラへ自動的にフォールバックします。Web向けビルドは現在もSkiaを使う点が例外です。

全部自前で描くので、iOSでもAndroidでも同じ見た目になります。デザイン確認をOSごとに二重で行う必要がなくなる点は、実務での確認負担を軽くする利点です。一方、OS側の新しいUI仕様に追随するのはFlutterチームの実装待ちになります。

「FlutterはReactに似ている」と言われる理由と、似ていない部分

似ているのは記述モデルです。どちらも状態から画面を組み立てる宣言的UIで、小さな部品を入れ子にして画面を作ります。ReactのコンポーネントとFlutterのウィジェットは、役割としてはほぼ同じものだと考えて差し支えありません。最小のコードを並べると構造の近さが分かります。

// React Native
<View style={styles.box}>
  <Text>Hello</Text>
</View>

// Flutter
Container(
  child: Text('Hello'),
)

似ていないのは、その下の層です。Reactは「何を描くか」を宣言してレンダラ（DOMやネイティブ部品）に委ねますが、Flutterは宣言の下に描画エンジンまで自分で抱えています。前節の根本差がここに効いてきます。したがって「似ている」からといってReact Nativeの知見がFlutterへそのまま移るわけではありません。移るのは設計の考え方で、移らないのはライブラリ・ツール・デバッグ手法です。状態管理も別物で、Flutter側の定番はRiverpodをはじめとする状態管理ライブラリになります。

使用言語とReact資産の引き継ぎやすさ：DartとTypeScriptの差

React NativeのTypeScriptとFlutterのDart 3.13系

React NativeはJavaScriptとTypeScriptで書きます。実務ではTypeScriptが標準で、@types配下の型定義もESLint設定もテストの書き方も、Web側で使っているものをほぼそのまま持ち込めます。FlutterはDart専用で、同梱されるのは前述のDart 3.13.3です。言語そのものの習得コストは、TypeScript経験者にとって大きな壁になりません。

差が出るのは言語の難易度ではなく、周辺資産の量です。npmのエコシステムをそのまま使えるReact Nativeに対し、Flutterはpub.devのパッケージ群でそろえ直すことになります。社内にWebフロントエンドの蓄積があるほど、この差が移行コストとして効いてきます。

ReactとReact Nativeの違い：共通するのは記述モデルだけ

ReactとReact Nativeを同じものだと考えると見積もりを外します。共通なのはコンポーネント・フック・状態管理といった記述モデルで、画面を構成する部品は別物です。Webの<div>や<span>はReact Nativeには存在せず、<View>と<Text>に置き換わります。CSSも使えず、スタイルはJavaScriptのオブジェクトで書きます。

そのため、既存のReact WebアプリをReact Nativeへ持っていくとき、再利用できるのはビジネスロジック・API通信・状態管理・型定義までで、画面は作り直しです。逆にいえばロジック層の共通化には確かな効果があり、ここを設計で分離してあるかどうかが移植コストを大きく変える要因です。ロジックをWebと共通化しておけば、React Compilerによる自動メモ化のようなWeb側の性能改善の知見もそのまま効いてきます。4つの層で両者を突き合わせた整理はReactとReact Nativeの違いを描画・部品・スタイル・画面遷移で比較にあります。

2026年9月時点で古い比較記事が使えなくなった5つの変化と現行版

FlutterとReact Nativeの比較記事は数が多い一方、前提が古いまま残っているものが目立ちます。判断を誤らせやすい変化を5つ挙げます。

New Architecture必須化でBridgeの議論が終わった経緯

React Nativeの弱点として長く語られてきたのが、JavaScript側とネイティブ側を非同期のJSONでやり取りする「Bridge」の存在でした。これはNew Architecture（JSI・TurboModules・Fabric）への移行で置き換え済みです。React Nativeの新アーキテクチャ作業部会のDiscussion #309によれば、0.82でnewArchEnabledをfalseにしても効果がなくなり、レガシーアーキテクチャへ戻す選択肢自体が消えました。0.83からはレガシーアーキテクチャのクラス削除も始まっています（既存ライブラリのためのinterop層は当面残ります）。

つまり「React NativeはBridgeがボトルネックだからFlutterが速い」という比較軸は、2026年時点では成立しません。この一文を根拠にしている比較記事は、それだけで内容が古いと判断してよい記述です。

Strict TypeScript API既定化で型の書き方と逃げ道が変わった

2026年8月11日のReact Native 0.87で、0.80ではopt-inのプレビューだったStrict TypeScript APIが既定のJavaScript APIになりました。react-native/Libraries配下へ直接importしていたコードは型エラーになり、refの型もプラットフォーム固有の専用型を使う形へ変わります。同時に最小要件も上がり、Node.js 22系・Android Gradle Plugin 9・Kotlin 2.0以上が必要です。

逃げ道も一時的に用意されました。tsconfig.jsonのcustomConditionsにreact-native-legacy-deep-importsを足せば従来の型へ戻せます。ただし公式は「この退避策は0.88までは使える」と明記し、その次のリリースで旧型定義を削除する意向を示しています。したがって0.86以前を前提に「型定義は自前で書き足すもの」と説明している記事は、いまのプロジェクトに当てはめないほうが安全です。

React Nativeの標準的な始め方がフレームワーク前提になった

React Nativeの公式のGet Startedは、新規アプリを作る場合にフレームワークの利用を推奨しています。「フレームワークなしでも使えるが、新しいアプリを作るならフレームワークを推奨する」と明記され、フレームワークを使わない場合は中核機能を自作するか既存ライブラリを寄せ集めることになる、と理由まで書かれています。

実質的な標準はExpoです。したがって「React Nativeはビルド環境の構築が大変」という評価も現状に合いません。比較するなら素のReact NativeではなくExpoを含めた状態で見るべきで、バージョン対応関係はExpo SDK 56の新機能と変更点まとめが参考になります。ネイティブUIをそのまま描画するExpo UI（@expo/ui）のような選択肢も増えました。

Impellerの既定化範囲がデスクトップ3種まで広がった経緯

Flutter側で古くなっているのは、Skia時代に起きていた初回アニメーション時のカクつき（シェーダコンパイルジャンク）を前提にした指摘です。Impellerはシェーダをビルド時に事前コンパイルする方式で、3.27以降は対象プラットフォームで既定になりました。対象端末がAndroid API 29以上かつVulkan対応であれば、「Flutterは初回だけ引っかかるので事前ウォームアップが必要」という運用ノウハウはもう要りません。

Impellerが既定となる対象範囲は、さらに広がった状態です。公式ドキュメントによれば、macOS・Linux・WindowsではFlutter 3.47からImpellerが既定で、将来のリリースでは無効化する手段そのものを削除する方針が示されています。逆に、想定ユーザーの端末分布が古くVulkan非対応機が多く残るAndroid案件では、OpenGLへのフォールバックが働いて挙動が変わりえます。バージョンごとの改善内容はFlutter 3.41が2026年2月安定版で示した開発者体験の改善ポイントにまとめました。

material_ui分離は安定版に未反映で改修を急ぐ段階ではない

2026年に入ってから、MaterialとCupertinoのウィジェット群をmaterial_ui・cupertino_uiという独立パッケージへ切り出す計画が話題になりました。ここは断定を避けるべき箇所です。Flutter公式の破壊的変更一覧では、この移行は2026年9月11日時点でも「Not yet released to stable」の側に置かれています。3.47で実際に安定版へ入った破壊的変更は、OpenGL ESのrender-to-texture、セマンティクスのheadingLevel挙動、describeEnumの削除の3件です。

ブログ記事の見出しだけを読むと分離が完了したように見えるため、「UIのimportを書き換える改修が必要」と判断してしまう例が出ています。現行の安定版でビルドが通っているなら、いま慌てて手を入れる段階ではない。移行時期は破壊的変更一覧の見出しがどちら側にあるかで見極めるのが確実です。

選定の判断基準：Flutter vs React Nativeを決める条件

観点 React Native Flutter
開発元 Meta Google
画面の実体 OSのネイティブUI部品 Impellerによる自前描画
言語 TypeScript / JavaScript Dart 3.13.3
OS間の見た目 OSごとに差が出る 実装どおりに統一できる
OS更新への追随 自動で追随 Flutterの実装待ち
既存Web資産 npm・型定義を流用可 pub.devで再構築
最新安定版 0.87.1（2026-08-26） 3.47.3（2026-09-09）

上から6行目までは独立した判断材料ではなく、上から順に効きます。画面の実体をどちらにするかを決めれば、残りはほぼ自動的に決まります。最終行は本記事の確認時点の版です。そもそもクロスプラットフォームを選ぶかどうかから整理したい場合は、クロスプラットフォームアプリ開発とは｜主要フレームワークの選び方が前段になります。

React Nativeが有利な条件：人とWeb資産から決まる場面

社内にReactまたはTypeScriptの開発者がいる場合、React Nativeを選ぶ理由が最も強くなります。人を採り直さずに始められ、Web側のロジックとテスト資産を持ち込めるからです。加えて、フォームやリスト中心の業務アプリのようにOS標準の操作感をそのまま出したいアプリ、OSの新機能へ早く追随したいアプリもReact Native向きになります。仕組みと採用判断の詳細はReact Nativeとは？New Architectureの構造と採用判断で扱いました。

Flutterが有利な条件：デザインの再現性が要件になる場面

デザインの再現性が要件になっているなら、Flutterを選びます。ブランドのデザインシステムをiOSとAndroidで差なく出したい、あるいはアニメーションやカスタム描画が体験の中心にあるアプリでは、全ピクセルを自分で描ける利点が他の要素を上回るためです。設計方針はFlutterにおけるアーキテクチャ設計の基本と重要性で整理しています。

どちらも選ぶべきでない場面：ネイティブで作るほうが安く済む条件

次の条件に当てはまるなら、クロスプラットフォームは採用しないほうが結果的に安く済みます。

  • 対応するのが片方のOSだけで、当面もう一方を出す予定がない
  • カメラ・センサー・Bluetooth・バックグラウンド処理など、OS固有APIの深い制御がアプリの中心機能である
  • OSのベータ版が出た初日に対応する必要がある
  • アプリ本体が小さく、クロスプラットフォーム層の学習と保守コストのほうが実装量を上回る

特に1つ目は判断を誤りやすいところです。「将来Androidも出すかもしれない」という不確定な予定のためにクロスプラットフォームを選ぶと、結局iOSしか出さないまま抽象化のコストだけを払い続けることになります。もう一方のOSの計画が具体化していないなら、素直にネイティブで作るほうが速い。ここは要件定義の段階で潰しておくべき論点です。

要件がこの4条件のどこに当たるか自社だけで切り分けにくい場合は、一創のFlutter / React Native開発で要件と体制を前提に判断材料を出しています。

FlutterとReact Nativeの弱点：採用後に効いてくる制約

Flutterの弱点：エンジン同梱によるサイズとOS追随の遅れ

最大の弱点は、OSのUI部品を使わないことの裏返しです。OSが新しいUIコンポーネントや挙動を追加したとき、Flutter側で再実装されるまで使えません。アプリサイズにも下限があります。Flutter公式FAQによれば、Materialコンポーネントを使わない最小構成のリリースAPKでARM32が約4.3MB、ARM64が約4.8MBで、うちコアエンジンがARM32で約3.4MBを占めます（いずれも2021年3月の計測値）。iOSのIPAはダウンロードサイズ10.9MB（iPhone X、App Store Connect報告値）です。小さなユーティリティアプリでは、この下限が相対的に重くなります。

Web向けビルドが今もSkiaを使う点にも注意が要ります。モバイルでの性能特性はそのままWebに当てはまりません。SEOを含むWeb側の制約はFlutter Webとは？描画差とSEO制約・採用条件で扱っています。

React Nativeの弱点：UI分岐とバージョン追随の運用負荷

OS間でUIが揃わないため、両OSで同じデザインを厳密に求められると分岐コードが増えます。ネイティブモジュールに依存する箇所は結局SwiftやKotlinを書くことになり、チームに両OSの知識が要ります。

運用コストとして具体的に効くのはリリース間隔です。React Nativeのリリース一覧のタグ日付では、0.84.0が2026年2月11日、0.85.0が2026年4月8日、0.86.0が2026年6月11日、0.87.0が2026年8月11日と、おおむね2か月間隔で出ています。0.82・0.83のアーキテクチャ変更や0.87の型API変更のように、追随を怠ると後からまとめて負債を払う形になるため、四半期ごとにバージョンアップ工数を確保しておく前提で見積もるのが安全です。

Flutterの将来性とReact Nativeの継続性を測る判断材料

「React Nativeはオワコンか」「Flutterの将来性は」といった問いは、求人数のような外形的な数字で測ろうとすると当てになりません。数字の出どころが調査ごとに違い、時期によって逆転するためです。判断材料として確実なのは、開発体制と採用実績が実際に動いているかどうかになります。

リリースの実績では、両者とも活発です。React Nativeは前述のとおり約2か月間隔でマイナー版を出し、New Architectureへの移行という数年がかりの作業を0.82・0.83で完了段階まで進めました。Flutterは3.47.3が2026年9月9日の安定版で、Impellerの適用範囲をデスクトップまで広げています。どちらも保守モードには入っていません。国内案件数まで含めた数値の見方はFlutterの将来性を数値で判断するにまとめました。

採用実績を確認する際の参照先も、各フレームワークの公式ショーケースです。React NativeのショーケースにはInstagram、Microsoft Office、Amazon Shopping、Shopifyが挙がり、FlutterのショーケースにはGoogle Pay、Google Earth、Toyota、BMW、Alibaba Group、Nubank、Supercellが並びます。開発元が自社の主力プロダクトで使っている点は、どちらにも共通します。数年で開発が止まる心配より、バージョン追随の運用体制を作れるかどうかのほうが現実的な課題です。

よくある質問

Flutterとは何ですか？読み方も教えてください。

Flutterとは、Googleが開発しているオープンソースのUIツールキットで、1つのコードからiOS・Android・Web・デスクトップ向けのアプリを作れます。読み方は「フラッター」で、英単語のflutterには「羽ばたく」「小刻みに揺れる」という意味があります。特徴は、OSのUI部品を借りずにImpellerという自前のレンダリングエンジンで画面全体を描く点です。

Flutterは何の言語で書きますか？

Dartで書きます。Googleが開発した型の明示的な言語で、Flutter本体に同梱される形で版が決まります。2026年9月9日の安定版Flutter 3.47.3に入っているのはDart 3.13.3です。開発中はJITで動かしてhot reloadを効かせ、リリース時はAOTでネイティブコードへコンパイルする、という2通りの経路を1つの言語で賄えることがDart採用の理由になっています。

React NativeとFlutterの違いは何ですか？

開発元と描画方式が違います。React NativeはMetaが開発し、OSのネイティブUI部品をJavaScript／TypeScriptから操作する仕組みです。FlutterはGoogleが開発し、Dartで書いたコードをImpellerという自前のレンダリングエンジンで描画します。ここから、React NativeはOS標準の見た目と挙動に自動で追随し、Flutterは両OSで同じ見た目を実装どおりに再現できる、という差が生まれます。

React Nativeで開発できる言語は何ですか？

アプリ本体を書くために使う言語は、JavaScriptまたはTypeScriptです。ただしカメラやBluetoothなどOS固有の機能を呼ぶネイティブモジュールを自作する場合は、iOS側でSwiftまたはObjective-C、Android側でKotlinまたはJavaを書くことになります。多くのアプリは既存ライブラリで足りるため、TypeScriptだけで完結することも十分あります。

Flutterの弱点は何ですか？

OSの新しいUI部品がFlutter側で再実装されるまで使えない点、描画エンジンを同梱するためアプリサイズに下限がある点（最小構成のAPKでARM32約4.3MB）、そしてWeb向けビルドが今もSkiaを使うためモバイルの性能特性がWebに当てはまらない点です。日本語の技術情報がReact系ほど蓄積されていないため、詰まったときは英語の公式ドキュメントやissueを読む前提になります。

既存のReact WebアプリをReact Nativeへ移植できますか？

画面部分はそのままでは動きません。<div>などのHTML要素とCSSがReact Nativeには存在しないためです。移植できるのはAPI通信・状態管理・バリデーション・型定義といったロジック層で、ここを画面から分離して書いてあるプロジェクトほど再利用率が上がります。移植計画を立てるときは、まずロジックと画面の結合度を確認してください。

FlutterのWeb対応はReactの代わりになりますか？

一般的なWebサイトの用途では代わりになりません。Flutter Webはキャンバスへ描画する方式で、通常のDOMを組み立てるReactとは出力が異なり、検索エンジン向けの評価や既存のWeb資産との相性で不利になります。社内管理画面やモバイルアプリと同一UIを配りたいケースなど、用途を限定すれば選択肢になります。Web中心のプロダクトであればReactを使うのが妥当です。逆に、既存のWebアプリをそのままiOS・Androidアプリとして配りたい場合は、WebViewを土台にするCapacitorという選択肢もあります。モバイル向けのUI部品まで揃えたいなら、UIツールキットのIonicを併用する構成です。

「Material UI」と「Dart」を比較する意味はありますか？

この2つは比較対象になりません。Material UI（MUI）はReact向けのWeb用UIコンポーネントライブラリで、Dartはプログラミング言語です。層が違います。比べるとすれば、言語同士ならDartとTypeScript、UI部品同士ならFlutterのMaterialウィジェットとMUIという組み合わせになります。FlutterはMaterial Designの実装を標準で内蔵しているため、MUIに相当するものを別途入れる必要はありません。

初心者が先に学ぶならどちらですか？

JavaScriptやReactに触れたことがあるならReact Nativeから始めるほうが立ち上がりが速く、公式が推奨するExpo経由なら環境構築でつまずきにくくなっています。プログラミング自体がはじめてで、モバイルアプリを作ること自体が目的ならFlutterを勧めます。Dartは型が明示的で、UIの組み立てからデバッグまでツールが一式そろっているため、学ぶ対象が分散しにくいためです。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る