Skip to content

MS_NativeVsSPA

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

ネイティブ vs SPA（Single-page Application）

概要

基本的に、

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

すればイイかと思う。

補足（この 2 行が本ページの結論）: 一見あっさりしているが、
技術選定の議論で最も重要な区別を述べている。

【ユーザ（発注側・利用側）】
   要件に適合するかで選ぶ
     → 「この機能が必要だから、この方式」

【ベンダ（開発側）】
   事業スキームに適合するかで選ぶ
     → 「うちはこの技術で食っていくから、これを習得する」
     → 案件ごとに技術を変えると、【誰も熟達しない】★

この 2 つを混同すると議論が噛み合わなくなる。

・「ベンダが得意だから」で要件に合わない方式を選ぶ → 失敗する
・「要件に最適だから」で毎回違う技術を選ぶ → 保守できない

 → 【要件が許す範囲で、組織が習熟した技術を選ぶ】のが実務解

詳細

選択肢

ネイティブ（DNET_SmartphoneNative.md）

SPA（Single-page Application）

比較表

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

# 比較項目 ネイティブ SPA（Single-page Application）
1 クロスプラットフォーム性 △（クロスプラットフォーム系なら可能） ○
2 コスト ✕ ○
2-1 ・ エンジニア人数 ✕（Platform 毎に必要） ○
2-2 ・ Web 技術のノウハウの流用 △（ハイブリッド系なら可能） ○（とは言え、SPA は Node.js（DNET_NodeJs.md）系の文化）
3 コンテンツの同期 ✕（要更新※１） ○
4 パフォーマンス ○ ✕
5 描画速度 ○ ✕
6 デバイスの機能 ○ ✕
7 オフライン対応 ○ ✕（PWA（DNET_PWA.md）同様、Service Worker などを使えば可能）

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

移行メモ（セル結合の展開）: 元の表は PukiWiki のセル結合記法
（>）で「比較項目」の列を横結合していたが、
GitHub の表はセル結合に対応しないため、
空セルを補って展開した。

補足（この比較表の現在の評価）: 挙げられた 7 項目は妥当だが、
一部は現在の状況と乖離しているため、更新する。

# 項目 原文 現在の評価
3 コンテンツの同期 ネイティブ ✕ ✕ のまま。ストア審査があり、利用者の更新も強制できない ★
4 パフォーマンス SPA ✕ △～○。JIT の進化、Wasm、端末性能の向上で差は縮んだ
5 描画速度 SPA ✕ △。60fps を要する UI では依然ネイティブ有利
6 デバイスの機能 SPA ✕ △。Web API が大幅に増えた（後述）
7 オフライン対応 SPA ✕ ○。Service Worker + Cache API で実用的に 
【最も変化したのが 6（デバイスの機能）】★

 【現在ブラウザから使える主な機能】
    ・カメラ・マイク（getUserMedia / WebRTC）
    ・位置情報（Geolocation）
    ・生体認証（WebAuthn）← 原文も言及
    ・プッシュ通知（Push API）※ iOS も対応済み
    ・Bluetooth（Web Bluetooth）※ Safari 非対応
    ・USB / シリアル（Web USB / Web Serial）※ Chromium 系のみ
    ・NFC（Web NFC）※ Android Chrome のみ
    ・ファイル システム（File System Access API）
    ・共有（Web Share API）
    ・画面の常時点灯（Screen Wake Lock）

 【依然として使えない／制約が大きいもの】
    ・バックグラウンドでの常時実行 ★
    ・連絡先・カレンダーへのアクセス
    ・SMS の読み取り
    ・システム レベルの統合（ウィジェット、ショートカット）
    ・【iOS Safari の対応が遅い】（最大の実務上の制約）

「iOS の Safari で何ができるか」が実質的な上限になる、
というのが現在の実務的な理解である。

ネイティブ（DNET_SmartphoneNative.md）

  • ネイティブ・レベルの機能が必要な場合に使用する。
  • その他、ネイティブ実装のほうが性能が良い。

SPA（Single-page Application）

  • 機能的には、Web アプリ・レベルで、

    • デバイス機能にアクセスできない。

    • 一部、HTML5 JavaScript API（DNET_HTML5JavaScriptAPI.md）でサポートされる。

      • WebRTC：カメラ
      • WebAuthn：認証器
      • Geolocation：位置情報

  • その他、JavaScript 実装で性能が悪い。

コストについて

ケース・バイ・ケース

  • 基本的に、ネイティブを Platform 毎に開発するほうが高価。
  • ただ、実現したい要件が異なるので、単純なコスト比較にはならないハズ。

補足（原文の「単純なコスト比較にはならない」は重要）: 初期開発費だけを
比較する議論は誤りやすい。総保有コストで見る必要がある。

【ネイティブに固有のコスト】★ 見落とされやすい
   ・【ストアへの登録・審査対応】
       → 審査で数日～数週間。リジェクトの対応
   ・【OS のメジャー更新への追随】
       → 毎年。放置すると動かなくなる／ストアから消される
   ・年会費（Apple Developer Program 等）
   ・端末・OS バージョンの動作確認の組み合わせ爆発
   ・証明書・プロビジョニング プロファイルの管理

【SPA / Web に固有のコスト】
   ・ブラウザの差異対応（現在はかなり減った）
   ・フロントエンドの【エコシステムの変化の速さ】★
       → ライブラリの版上げ、ビルド ツールの移行
   ・SEO・初期表示速度の作り込み

【判断の目安】
   ・不特定多数向け／導線が Web から      → 【SPA / Web】
   ・社内・限定ユーザ／端末を配布する      → どちらでも
   ・カメラで連続スキャン、地図の常時追跡  → 【ネイティブ】
   ・オフラインが業務要件（現場作業）      → ネイティブ or PWA を検証
   ・プッシュ通知が業務の中核             → ネイティブが確実
   ・【ストア審査を通したくない】          → 【Web】★
     （業務アプリでは、これが決め手になることが多い）

原文の「コンテンツの同期」（項番 3）と関連するが、
ストアの存在そのものが業務システムでは障害になりやすい。

【業務システムでネイティブが敬遠される理由】
   ・緊急のバグ修正が【審査待ちで即日反映できない】★
   ・利用者が更新してくれない（古い版が残り続ける）
   ・MDM を入れないと配布を統制できない

 → Web なら【配置した瞬間に全員が新しい版になる】

参考

ネイティブ（DNET_SmartphoneNative.md）

SPA（Single-page Application）

補足（.NET 開発者にとっての第 3 の選択肢）: 本ページの二者択一に
収まらない選択肢が、現在は増えている。

手段 位置付け
PWA Web でありながらインストールでき、オフラインも可（DNET_PWA.md）
Blazor WebAssembly + PWA C# だけでオフライン対応アプリ（WebAssembly）
.NET MAUI C# でネイティブ（Xamarin の後継）
Uno Platform XAML で Web / ネイティブ双方
ハイブリッド（MAUI Blazor Hybrid） ネイティブの器に Web UI を載せる ★ 
【MAUI Blazor Hybrid が興味深い】
   ・ネイティブ アプリとして配布する（デバイス機能に完全アクセス）
   ・UI は【Blazor（C# + HTML/CSS）】で書く
   ・WebView 上で動くが、【Wasm ではなくネイティブの .NET】が動く
      → ダウンロード サイズ・起動速度の問題がない ★
      → Web 版とコンポーネントを共有できる

 → 「Web 技術のノウハウを流用しつつ、デバイス機能も使う」
   という、本ページの表の弱点を埋める構成

詳細は ネイティブ vs クロスプラットフォーム を参照。

Microsoft Learn

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

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

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally