以前の記事ではスマートフォンアプリ開発手法の一つとしてハイブリッドアプリを紹介いたしました。
今回の記事ではネイティブアプリの不利な点を軽減する開発手法、クロスプラットフォームフレームワークを紹介いたします。
| ハイブリットアプリ | ネイティブアプリ | Webアプリ | PWA | |
|---|---|---|---|---|
| コスト | 〇 | × → ※△～〇 | ◎ | △ |
| 機能性 | 〇 | ◎ | × | △ |
| インストールしやすさ | △ | △ | ― ※インストール不要 | 〇 |
| プラットフォーム依存リスクの回避 | 〇 | × → ※×～△ | 〇 | △ |
iOS, Android, Windowsなどの複数のOSに対して横断的（クロスプラットフォーム）に開発できる環境（フレームワーク）を指します。
従来の開発ではOSごとに開発に適した言語が異なるため(※1)、同じ処理内容をOSごとに別の言語で記述する必要があり、そのためにコストが増大していました。クロスプラットフォームフレームワークを利用することで多くの部分をOSによらず同じ言語で記述することが可能になり開発コストを削減することができます。
フレームワークが提供する範囲を越える機能が必要になる場合（外部のICタグリーダー機器との接続など）は、ハイブリッドアプリと同様に部分的にOSネイティブの言語で開発を行う必要があります。
2022現在では以下のものなどがあります。
・Flutter
・React Native
・Unity 3D ※2
・.Net Multi-platform App UI (.NET MAUI)
・Kotlin Multiplatform Mobile (KMM)
※1 iOSではSwift/Objective-C、AndroidではKotlin/Java、WindowsではC#/C++/Cが一般的です。
※2 本記事はスマートフォン向けの業務アプリ開発を主軸に据えるため、以降の本文ではUnityは扱いません。ゲーム開発向けフレームワーク(ゲームエンジン)であるUnityは、音声再生の遅延の少なさや画面描画の素早さ、UI操作に対するレスポンスの速さなどに定評があります。
| Flutter | React Native | .Net MAUI | KMM | |
| 開発会社 | Microsoft | JetBrains | ||
| コスト | 〇 | 〇～△ | △ | △ |
| 言語 | Dart | JavaScript, TypeScript | C# | Kotlin |
| 言語に対する開発者の多さ | △ | ◎ | 〇 | 〇～△ |
| 開発者コスト・習得難易度 | 〇 | JavaScript:◎ TypeScript:〇～△ | 〇～△ | △～× |
| UI作成コスト | ◎ | 〇～△ | 〇～△ | × |
DartというJavaScriptとJavaの長所を組み合わせた言語を使用します。比較的習得が容易ですが、スマートフォンアプリ以外の開発では利用されない言語のため開発者が少ない傾向があります。
UI部分まで独自に提供しているためOSごとの差分が必要な個所が少なくコストが抑えられます。その反面、各OSのUIの一般的な操作感とは、ずれが出ることがあります。
他の開発環境との共通点が少ない（既存のコード資産を利用できない）という特徴がありますが習得難易度が低いことから新規に手早く開始するのに向いています。小規模アプリ、プロトタイプ開発、サーバー-クライアント系でクライアント実装が薄いものに向いていると考えられます。
JavaScriptやTypeScriptというWebアプリの開発で一般的な言語を使用します。開発者の母数が多く、日本語による技術情報も豊富に見つかります。
UI部分は、フレームワークとしてはOSごとに記述する必要があります。ですが豊富に公開されているオープンソースのUIコンポーネントを利用することで処理を共通化してコスト削減が可能です。
開発者の確保が容易なことが最大の長所です。その反面、成果物の品質にばらつきが出やすいため、コード規模が増大する前にTypeScriptを導入することをお勧めします。
XAMARINというフレームワークの後継です。
C#というWindowsアプリ開発で一般的な言語を使用します。
UI部分は、独自に提供しているUI部品とOSごとに作成が可能な仕組みとの両方が提供されています。
スマートフォンだけではなくWindowsデスクトップアプリも開発する案件にお勧めです。Microsoft社が開発元のため、突然フレームワークの開発が終了するなどの長期サポートリスクが低いと考えられます。
2022年10月にベータ版が公開されたばかりのフレームワークです。
ロジック部分はKotlinというAndroid開発で一般的な言語を使用します。
UI部分は、iOSではSwift、AndroidではKotlinというようにOSごとに別に作成する必要があります。
ベータ版の段階のため判断が難しいです。Kotlinという言語は熟練した開発者にとっては開発効率が高いですが、習得難易度が相対的に高いです。このため交代要員や増員の確保に困る場合があります。また、定番と言える設計モデルや適したライブラリが確立していないため初期コストは高めと考えられます。
現段階では、どのプラットフォームもそれぞれに長所があり、会社の状況により適したフレームワークが変わります。
このため自社の既存コード資産や開発者の得意言語に応じて選択することになります。
元資料: Stack Overflow Developer Survey 2019～2022
注目ポイント
Flutter/Dartは開発者からの評価が高い(※)が、主要なクロスプラットフォーム/言語の中では給与が最も安い。給与水準は習得難易度の低さを表しており、上昇率が高いことは十分な品質の製品を開発できることを示していると考えられる。
※ 項目 Technology – Most loved, dreaded, and wanted より
※本項の表はフレームワークと言語で抽出したものであり、スマートフォンアプリ開発者に限定したものではありません。例えばC#はデスクトップアプリ開発にも利用されます。
| 開発者割合(%) ※1 | 開発者給与（米ドル） ※2 | |||||
| フレームワーク | 2019 | 2020 | 2021 | 2022 | 2021 | 2022 |
| Flutter | 3.2 | 6.6 | 13.35 | 12.56 | 32,429 | 42,657 (31.5%増) |
| React Native | 10.8 | 11.8 | 16.48 | 13.62 | 44,160 | 54,000 (22.3%増) |
| Xamarin | 6.5 | 6.0 | 4.17 ※3 | 5.54 | 51,704 | 63,384 (22.6%増) |
| Cordova | 7.4 | 6.4 | 8.67 | 4.72 | 39,192 | 49,232 (25.6%増) |
| Unity 3D | 9.1 | 8.7 | 7.03 ※3 | 8.19 ※3 | 45,396 | 59,327 (30.7%増) |
| 開発者割合(%) ※1 | 開発者給与（米ドル） ※2 | |||||
| 言語 | 2019 | 2020 | 2021 | 2022 | 2021 | 2022 |
| Dart | 1.8 | 3.7 | 5.97 | 6.67 | 32,986 | 43,724 (32.6%増) |
| JavaScript | 69.7 | 69.7 | 68.62 | 67.9 | 54,049 | 65,580 (21.3%増) |
| TypeScript | 23.5 | 28.3 | 36.42 | 40.08 | 59,172 | 70,276 (18.8%増) |
| C# | 31.9 | 32.3 | 29.81 | 29.72 | 58,368 | 69,516 (19.1%増) |
| Kotlin | 6.6 | 8.0 | 9.09 | 9.92 | 55,071 | 69,318 (25.9%増) |
| Java | 39.2 | 38.4 | 34.51 | 33.4 | 51,888 | 64,572 (24.4%増) |
| Swift | 6.8 | 6.1 | 5.64 | 5.18 | 58,910 | 78,468 (33.2%増) |
| Objective-C | 5.2 | – | 3.33 | 2.69 | 64,859 | 83,165 (28.2%増) |
Kotlin言語はAndroid開発における標準的な言語であるため、Android開発を主に行ってきた会社では導入しやすいと考えられます。
近年AndroidやiOSのネイティブ開発ではJetpack ComposeやSwiftUIという宣言型UI部品が出てきてUI開発が容易になりました。特にAndroidでは公式にMVVMという設計モデルに適した部品(ViewModelクラス)も用意されています。しかしJetpack Composeの ViewModelクラスはKMMフレームワークを使う場合は同じ部品が使えず、また、宣言型UI部品を使う場合はViewModelクラスは適切ではないとの意見もあり、まだ定番と言える設計モデル及び対応ライブラリが出ていません。（とは言え独自に設計を練って導入を行った会社もあります）
推奨される設計モデルがどう変わってゆくかと合わせて今後の動向が気になるフレームワークです。
JavaScriptの代替としてWebAssemblyという技術が出てきています。スクリプトデータからバイナリデータに変わることにより、処理性能が向上し、転送データサイズが縮小されています。また、近年はLLVMというコンパイラのおかげで多くの言語でWebAssembly開発ができます。
性能が上がり開発言語の自由度が広がったことから、今までよりもWebアプリが選択肢に入りやすくなったと考えられます。
この記事を見ているあなたに
オススメの記事
前の記事へ
