3つの選択肢と、それぞれの正体
スマホアプリを作ると決めた後、最初の分岐が「どの方式で作るか」です。選択肢は大きく3つあります。
① ネイティブ Swift (iOS) / Kotlin (Android)
→ OS純正の作り方。性能と機能の自由度が最大
② クロスプラットフォーム Flutter / React Native
→ 1つのコードで両OS。UI は独自描画 or ネイティブ部品
③ PWA HTML/CSS/JavaScript + Service Worker
→ 実体はWebサイト。ホーム画面に追加してアプリのように使うよくある誤解は「PWA＝安いネイティブの下位互換」というものです。実際はできることの種類が違うだけで、社内配布のツールならPWAのほうが運用が軽く、審査待ちもなく、更新も即時反映されるという明確な利点があります。逆に、通知を軸にした顧客向けアプリでPWAを選ぶと、後述の理由で施策が成立しません。
判断を分ける6つの軸
案件ごとに次の6項目を確認すれば、方式はほぼ自動的に決まります。
| 軸 | ネイティブ | クロスプラットフォーム | PWA |
|---|---|---|---|
| プッシュ通知 | ◎ 制約なし | ◎ 制約なし | △ iOSは条件付き |
| オフライン動作 | ◎ | ◎ | ○ 実装次第 |
| カメラ・センサー | ◎ 全機能 | ○ プラグイン依存 | △ 制限あり |
| Bluetooth・USB機器連携 | ◎ | ○ プラグイン依存 | × 実質不可 |
| 配布・更新 | △ 審査あり | △ 審査あり | ◎ URL・即時反映 |
| 開発費（両OS対応時） | 高（2つ作る） | 中 | 低 |
表を見ると、「Bluetooth機器とつなぐ」「センサーを細かく制御する」が要件に入った瞬間にPWAは落ちることが分かります。逆に、社内の入力フォームや一覧表示が中心で、配布の手軽さと更新の速さを優先するなら、PWAで十分どころか最適です。
つまずきポイント①：iOSのプッシュ通知
「PWAでも通知は送れます」——これは正しいのですが、iOSでは重要な前提が付きます。
iOS 16.4 以降:
✅ Web Push は使える
⚠️ ただし「ホーム画面に追加」したPWAに限られる
（Safariのタブで開いているだけでは通知が届かない）
Android:
✅ Chrome でそのまま Web Push が使える（ホーム画面追加は任意）つまりiPhoneユーザーには、「共有ボタンを押して、ホーム画面に追加してください」という操作を案内し、実行してもらう必要があります。社内向けで配布時に説明できるなら現実的ですが、一般ユーザー向けアプリでこの一手間を挟むと、通知を受け取れる人の割合は大きく落ちます。
判断基準はシンプルです。プッシュ通知が施策の中心（再来店促進、緊急連絡、リマインド）なら、ネイティブまたはクロスプラットフォームを選んでください。通知が「あれば便利」程度ならPWAで問題ありません。
つまずきポイント②：オフライン動作の実装コスト
倉庫・工場・地下・山間部など、通信が不安定な現場で使うアプリでは「圏外でも入力できる」が必須要件になります。ここで見落とされがちなのが、オフライン対応の本体はUIではなくデータ同期の設計だという点です。
方式を問わず、次の問題を必ず設計する必要があります。
- 競合の解決 — 同じデータをAさんとBさんが別々にオフライン編集したら、どちらを採用するか
- 送信の再試行 — 電波が戻ったときに未送信データを自動送信し、失敗時は再試行する
- 重複の防止 — 再試行で同じデータが二重登録されないよう、クライアント側で一意IDを持たせる
- ストレージ上限 — 端末に貯め込めるデータ量の上限と、古いデータの破棄ルール
この設計を省くと、「圏外で入力したデータが消えた」「同じ報告が2件登録される」といった、現場の信頼を一発で失う不具合が起きます。オフライン要件がある案件では、UIより先にこの部分を詰めてください。
// 二重登録を防ぐ: クライアントで一意IDを発行して送る
const record = {
clientId: crypto.randomUUID(), // 端末側で採番
inspectedAt: new Date().toISOString(),
items: [...],
};
await queue.enqueue(record); // まずローカルに保存
// オンライン復帰時にまとめて送信（サーバーは clientId で重複を弾く）
window.addEventListener('online', () => queue.flush());つまずきポイント③：配布方法と審査
意外と見落とされるのが配布です。とくに社内利用のアプリをApp Storeに公開したくないケースでは、方式選定に直結します。
| 配布方法 | 対象 | 特徴 |
|---|---|---|
| App Store / Google Play | 一般公開 | 誰でも入手可。審査に1〜2週間 |
| Apple Business Manager（カスタムApp） | iOS社内配布 | 指定組織にのみ配信。審査あり |
| MDM経由 | iOS/Android社内配布 | 端末管理と合わせて配布。MDM導入が前提 |
| Google Play 限定公開 / APK配布 | Android社内配布 | 比較的手軽 |
| PWA（URL配布） | 制限なし | 審査ゼロ・更新即時。ホーム画面追加を案内する |
審査は開発スケジュールに影響します。ネイティブ・クロスプラットフォームでは、リリース後の緊急修正にも審査が挟まります（Appleの迅速化申請はありますが確約ではありません）。頻繁に更新したい業務ツールほど、PWAの「即時反映」が効いてきます。
フローチャート：どれを選ぶか
実際の案件で使っている判断順です。上から順に見ていけば、だいたい迷わず決まります。
Q1. Bluetooth/USB機器やセンサーを細かく制御する？
YES → ネイティブ（or ネイティブ拡張を含むクロスプラットフォーム）
NO ↓
Q2. iOSユーザーへのプッシュ通知が施策の中心？
YES → ネイティブ / クロスプラットフォーム
NO ↓
Q3. App Store・Google Play で一般公開して露出を取りたい？
YES → ネイティブ / クロスプラットフォーム
NO ↓
Q4. 更新頻度が高い、または審査待ちを避けたい？
YES → PWA
NO ↓
Q5. 予算と期間を最小に抑えたい？
YES → PWA
NO → クロスプラットフォーム（両OS対応の費用対効果が最も高い）補足として、Q1でネイティブに倒れた場合でも「片方のOSだけ先に作る」という選択肢があります。社内配布ならAndroidだけ、店舗の貸与端末がiPadならiOSだけ、といった具合に対象端末を固定できるなら、開発費は半分近くに抑えられます。
後から乗り換えられる設計にしておく
技術選定でいちばん怖いのは「読み違えたときに全部作り直しになる」ことです。これは設計で相当程度、回避できます。
- 業務ロジックはサーバー側のAPIに置く — 端末側は表示と入力に徹する。移行時に作り直すのはUIだけで済みます
- データモデルを端末に依存させない — 端末固有の保存形式に業務データを直接書かない
- 認証は標準的な方式で — OAuth 2.0 / OIDC など、どの方式からでも使える形にしておく
- まずPWAで検証してからネイティブへ — 使われ方が読めない新規業務では、PWAで安く早く出して実際の利用状況を見る進め方が有効です
実際に弊社では、ブラウザだけで動く3Dアプリのように、Web技術でどこまでできるかを検証したうえで、必要な部分だけネイティブに寄せる進め方を採ることがあります。実際に動くデモも公開しているので、Web技術の到達点の参考にしてください。
よくある質問（FAQ）
Q. PWAでもiPhoneにプッシュ通知は送れますか？
送れます。iOS 16.4以降、ホーム画面に追加したPWAでWeb Pushが使えます。ただしホーム画面への追加操作が必須で、この一手間で到達率が落ちます。通知が中心の施策ならネイティブ系が確実です。
Q. FlutterとReact Nativeはどちらを選ぶべきですか？
既存チームがReact/TypeScriptに慣れているならReact Native、UIをiOS/Androidで完全に揃えたい・描画性能を重視するならFlutterです。特殊なハードウェア連携がある場合は、いずれもネイティブコードを書く前提で見積もってください。
Q. 業務アプリをストアに公開せず配布できますか？
できます。配布方法の比較のとおり、Apple Business Manager・MDM・Google Play限定公開などの手段があります。社内限定ならPWAでURL配布という選択肢も有力です。
Q. 後からネイティブに作り直せますか？
できますが、UIは作り直しになります。業務ロジックをサーバー側に寄せておくと、移行時の影響をUIだけに閉じ込められます。
まとめ
この記事のまとめ
- PWAは「安い下位互換」ではなく、配布の手軽さと更新の速さで優位に立つ選択肢
- Bluetooth・センサー制御が要件に入ったらPWAは選べない
- iOSのWeb Pushは「ホーム画面に追加」が前提。通知中心の施策ならネイティブ系
- オフライン対応の本体はUIではなく同期設計（競合解決・再試行・重複防止）
- 業務ロジックをサーバー側に寄せておけば、後から方式を乗り換えても影響はUIだけ
テクノスフィアでは、iOS/Androidネイティブ、Flutter・React Native、PWAのいずれにも対応し、機器側の組込み開発やサーバー・クラウド構築まで自社で行っています。「アプリにすべきか、Webで足りるか」の判断からご相談いただけます。