MS_NativeVsCrossPlatform - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

ネイティブ vs クロスプラットフォーム

概要

基本的に、

  • ユーザ・サイドは特徴がシステムに適合する方を採用
  • ベンダ・サイドは事業スキームに適合する方を習得

すればイイかと思う。

詳細

選択肢

ネイティブ

クロスプラットフォーム

  • HTML5 ハイブリッド型

    • Cordova (PhoneGap)
    • Electron
    • PWA（Progressive Web Apps）

  • ネイティブ UI 型

  • 独自レンダラ型

    • Unity
    • Flutter
    • その他

補足（この 3 分類が本ページの最大の価値）: クロスプラットフォームを
**「ハイブリッド型 / ネイティブ UI 型 / 独自レンダラ型」**に分けた点が
秀逸で、現在もそのまま通用する分類である。仕組みの違いを明示する。

【① HTML5 ハイブリッド型】
   ネイティブの器（WebView）の中で【Web ページを動かす】

     ネイティブ アプリ
       └ WebView（ブラウザ エンジン）
            └ HTML / CSS / JavaScript
            └ プラグイン経由でデバイス機能を呼ぶ

   → 描画は【ブラウザ】。Web と同じ見た目・性能

【② ネイティブ UI 型】
   共通の記述から【OS 標準の UI 部品を生成する】★

     C# / JavaScript のコード
       └ ブリッジ
            └ iOS: UIButton / Android: android.widget.Button

   → 描画は【OS のネイティブ部品】。見た目は OS ごとに変わる

【③ 独自レンダラ型】
   OS の UI 部品を使わず、【自前で全部描く】

     アプリのコード
       └ 独自の描画エンジン（Skia / OpenGL 等）
            └ キャンバスに直接描画

   → 【全 OS で完全に同じ見た目】になる
   → OS の UI 更新に追随しない（良くも悪くも）

この違いが、後述の比較表の各項目を決めている。

例： 「Web 技術のノウハウの流用」
       ハイブリッド ◯ … そのまま HTML/CSS/JS
       ネイティブUI ✕ … XAML や JSX（Web とは別物）
       独自レンダラ ✕ … Dart / C#（まったく別）

例： 「描画速度」
       ハイブリッド ✕ … WebView のオーバーヘッド
       ネイティブUI △ … ブリッジの往復コスト
       独自レンダラ △ … 描画は速いが、初回の起動が重い

比較表

一般的に流布している比較項目

# 比較項目 ネイティブ ハイブリッド型 ネイティブUI型 独自レンダラ型
1 クロスプラットフォーム性 ✕ ◯ ◯ ◯
2 コスト ケース・バイ・ケース ケース・バイ・ケース ケース・バイ・ケース ケース・バイ・ケース
2-1 ・ エンジニア人数 ✕（プラットフォーム毎に必要） ◯ ◯ ◯
2-2 ・ Web 技術のノウハウの流用 ✕ ◯ ✕ ✕
2-3 ・ 技術調査、障害対応の容易さ ◯ △ ✕（採用したフレームワークの情報量による） ✕（採用したフレームワークの情報量による）
3 コンテンツの同期 ✕（要更新※１） ◯ ✕（要更新※１） ✕（要更新※１）
4 パフォーマンス ◯ ✕ △ △
5 描画速度 ◯ ✕ △ △
6 デバイスの機能 ◎ △（plugin 次第） ○（Platform 呼出機能あり） ○（Platform 呼出機能あり）
7 オフライン対応 ◯ △ ◯ ◯

※１ OTA アップデートで迅速化可能。

移行メモ（セル結合の展開）: 元の表は PukiWiki のセル結合記法
（> = 横結合、~ = 縦結合）を多用していたが、
GitHub の表はセル結合に対応しないため、
同じ値を展開して記載した。
元の表では「ネイティブUI型」と「独自レンダラ型」が
横結合されていた項目（1・2-3・3・4・5・6・7）は、
両方に同じ値を入れている。

補足（現在の評価と、各技術の現況）: 分類は今も有効だが、
具体的な製品の顔ぶれが大きく変わったため更新する。

① HTML5 ハイブリッド型

技術 現況
Cordova (PhoneGap) Apache Cordova は 2025 年にアーカイブ（PhoneGap は 2020 年終了）★
Capacitor Cordova の実質的な後継（Ionic 製）。現役
Electron 現役・広く使われる（VS Code、Slack、Teams）★
Tauri Electron の軽量な代替（Rust 製、OS の WebView を使う）
PWA 現役。インストール・オフライン・プッシュに対応

② ネイティブ UI 型

技術 現況
Xamarin 2024 年 5 月にサポート終了。.NET MAUI へ移行★
.NET MAUI Xamarin.Forms の後継。現行
React Native 現役・活発。New Architecture へ移行中

③ 独自レンダラ型

技術 現況
Flutter 現役・最も勢いがある（Impeller レンダラ）★
Unity ゲーム主体。業務アプリでは限定的
Uno Platform XAML で Web/デスクトップ/モバイル
Avalonia XAML。デスクトップに強い 
【.NET 開発者にとって最も重要な変化】★
   Xamarin → .NET MAUI
     ・Xamarin.Forms は【2024 年 5 月にサポート終了】
     ・.NET MAUI は【単一プロジェクト】構成に変わった
     ・iOS / Android / macOS / Windows を 1 つの csproj で
     → [Xamarin](MS_Xamarin) を使っている資産は移行の検討が必要

新たに加わった第 4 の分類:

【④ ハイブリッド（ネイティブ UI + Web UI）】
   ネイティブ アプリの中に WebView を置き、
   そこに【Blazor コンポーネント】を載せる
     → MAUI Blazor Hybrid ★

   ・器はネイティブ＝【デバイス機能に完全アクセス】
   ・UI は Blazor＝【Web のコンポーネントを共有できる】
   ・Wasm ではなく【ネイティブの .NET】が動く
      → ダウンロード サイズ・起動速度の問題がない

 → ①（Web 技術を流用できる）と ②（デバイス機能）の
   利点を両取りする構成

ネイティブ

  • 動作速度が求められる。
  • ネイティブ機能との密接な連携を必要とする。
  • オフラインでも容量の大きいコンテンツの閲覧ニーズがある。

クロスプラットフォーム（ハイブリッド

  • 動作速度は、それなりのスピードでいい。
  • ネイティブ機能との密接な連携を必要としない。
  • オフラインでの利用ニーズが無い or 低い。
  • OTA アップデートを使用せずコンテンツ差し替えが可能。

クロスプラットフォーム（ハイブリッド以外

  • ネイティブ・ハイブリッドの中間の性能
  • ネイティブ機能との連携も可能（プラグインは不要）
  • オフライン処理もネイティブ同様に可能。

補足（「OTA アップデートを使用せずコンテンツ差し替えが可能」）: この
ハイブリッド型の利点は実務で決定的に効くことがあるので補強する。

【ハイブリッド型の更新】
   HTML/CSS/JS を【サーバから読む】構成にすれば、
   アプリ本体を更新せずに画面を差し替えられる
     → 【ストア審査が不要】★
     → 緊急のバグ修正が即日反映できる

【ただし、ストアの規約に注意】★
   ・Apple は「アプリの主要な機能を後から変える」ことに厳しい
      → 審査を回避する目的の動的更新はリジェクト対象になりうる
   ・「バグ修正・コンテンツ更新」の範囲に留めるのが安全
   ・そもそも【App Store に出さない】業務アプリなら制約は緩い
      （MDM 配布、社内配布、あるいは Web で済ませる）

OTA アップデート（Over The Air）についての補足:

【React Native の CodePush】
   JS バンドルだけを差し替える仕組み
     → Microsoft の App Center で提供されていたが
       【App Center は 2025 年 3 月にサービス終了】★
     → 現在は Expo Updates 等の代替へ移行

 → [Visual Studio App Center](MS_VisualStudioAppCenter) も参照

コストについて

以下がトレードオフ関係があるので一概に言えない。

  • エンジニア人数
  • Web 技術のノウハウの流用
  • 技術調査、障害対応の容易さ

補足（「技術調査、障害対応の容易さ」が実は最大のコスト要因）: 原文が
3 番目に挙げているこの項目は、軽視されがちだが最も効く。

【なぜこれがコストになるのか】

 【ネイティブ】
    問題が起きたら、OS のドキュメント／Stack Overflow に
    【情報が大量にある】
      → 一次情報にたどり着ける

 【クロスプラットフォーム】
    問題が起きたら、
      ① フレームワークの問題か
      ② ブリッジ／プラグインの問題か
      ③ OS 側の問題か
    を【切り分けるところから始まる】★
      → 情報が少ない（フレームワーク × OS × 版の組み合わせ）
      → 最終的に【フレームワークの実装を読む】ことになる
      → 修正を待つか、自分でパッチを当てるか

【判断に効く問い】
   ・そのフレームワークの【GitHub の Issue 数と解決速度】は？
   ・日本語・英語の情報量は？
   ・【自社に読める人がいるか】（最後は実装を読むことになる）★
   ・ベンダーのサポート契約は取れるか
   ・5 年後も生きているか（Cordova / Xamarin の例）

本ページの技術一覧のうち、
Cordova・PhoneGap・Xamarin・App Center が
いずれも終了したという事実自体が、
この項目の重要性を裏付けている。

【教訓】
   クロスプラットフォームの選定では、
   【技術の寿命】もコストとして見積もる ★
     → 移行コストは、初期開発費に匹敵することがある
     → 「大手が出しているから安心」とは限らない

参考

スマホ - 開発基盤部会 Wiki

スマホネイティブ

クロスプラットフォーム開発ツール

Microsoft Learn

Tags: 移行, .NET開発, モバイル系開発

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️