ウェブアプリをネイティブアプリにする3つの方法

すでに動いているウェブアプリがあります。これを App Store と Google Play にも出したい — プッシュ通知、生体認証ログイン、ホーム画面の本物のアプリアイコンまで。

方法は大きく3つあります。それぞれを、やさしい言葉で、本当に重要な違いを中心に整理します。

1. PWA（プログレッシブウェブアプリ）として出す

PWA（Progressive Web App）は、ウェブサイトをスマホにインストールされたアプリのように使えるようにする方法です。ホーム画面にアイコンを追加し、ブラウザとは別に起動することもできます。これには マニフェスト（manifest）や サービスワーカー（service worker）といったウェブ技術を使います。

• 良い点： 最も安く済みます。別のアプリを新しく作る必要がなく、既存のウェブコードもそのまま使えます。
• 難しい点： ネイティブアプリと比べると、使えるデバイス機能や動作の仕方に違いがあり、一般的なネイティブアプリのように App Store や Google Play に掲載する形でもありません。

iOS でも、ホーム画面に追加した PWA はウェブプッシュを使えます（iOS 16.4 以降）。ただしネイティブアプリと完全に同じ方式ではなく、ユーザーがまずウェブアプリをホーム画面に追加する必要があるなどの違いがあります。

ですから、ストア掲載が重要でなく、ウェブを中心にサービスを提供すれば十分なら、PWA が最もシンプルな方法です。

2. ネイティブアプリとして作り直す

2つ目の方法は、既存のウェブアプリとは別にモバイルアプリを新しく作ることです。iOS は Swift、Android は Kotlin でそれぞれ作ることもできますし、React Native や Flutter のような クロスプラットフォームのフレームワークを使うこともできます。クロスプラットフォームのフレームワークとは、1つのコードベースで iOS と Android のアプリを一緒に作る方式です。

• 良い点： デバイスの機能を幅広く使え、モバイル環境に合わせた最も自然なユーザー体験を作れます。
• 難しい点： 既存のウェブアプリに加えて、別のアプリのコードも開発・保守し続ける必要があります。

Swift と Kotlin でそれぞれ作ると、3つのコードベースを管理することになるかもしれません。

ウェブアプリ      iOS アプリ      Android アプリ

ウェブで新しい機能を作って終わり、ではなく、同じ機能をモバイルアプリにも作り直す必要が出てくることがあります。React Native や Flutter を使えば iOS と Android のコードを大部分共有できますが、既存のウェブアプリとは依然として別のアプリプロジェクトです。

アプリそのものが中核の製品で、ネイティブアプリを作り続け・保守し続けるチームがあるなら、この方法が最も向いています。

3. ウェブアプリをネイティブアプリの中で動かす（WebView + ネイティブブリッジ）

3つ目は、既存のウェブアプリをそのまま活かしながらネイティブアプリにする方法です。アプリの中に WebView を置き、その中で既存のウェブアプリを動かします。WebView は、アプリの中でウェブページを表示するブラウザの領域だと考えればよいでしょう。

ただし、WebView にウェブサイトを表示するだけで終わりではありません。ウェブから直接使いにくいスマホの機能をつなぐために、ネイティブブリッジ（native bridge）を使います — WebView の中の JavaScript と、スマホのネイティブ機能をつなぐ役割です。

たとえば、ウェブアプリの JavaScript から次のように呼び出すと：

requestBiometricAuth();

ブリッジがこれを iOS や Android の実際の生体認証機能につなぎます。これによって、既存のウェブアプリでも次のような機能が使えます。

• プッシュ通知
• カメラ
• 生体認証
• ファイル選択
• ネイティブ画面とナビゲーション
• アプリ内課金
• その他 iOS・Android のデバイス機能

良い点： 既存のウェブコードベースをできるだけそのまま使えます。ウェブで作った機能を iOS と Android でゼロから作り直す必要が減り、必要な部分だけネイティブ機能をつなげばよくなります。つまり、こういう構造です。

既存のウェブアプリ
   ↓
WebView
   ↕
ネイティブブリッジ
   ↓
iOS / Android の機能

注意点： WebView にウェブサイトを表示したからといって、自動的に良いネイティブアプリになるわけではありません。特に App Store では、ウェブサイトを単に再パッケージしただけのアプリは審査で問題になることがあります — Apple は、アプリが単なるウェブサイトのラッパーを超える機能・コンテンツ・UI と十分な有用性を提供することを求めています。ですから、単にウェブページを表示するより、アプリの目的に合わせてプッシュ通知・生体認証・ネイティブナビゲーション・カメラやファイル機能・アプリ内課金・アプリに合った画面の挙動といった機能をつなぎ、アプリとして意味のある体験を提供することが重要です。ネイティブブリッジは、ウェブアプリからこうしたデバイス機能を使えるようにつないでくれます。

すでに運用中のウェブアプリがあり、別のネイティブアプリをゼロから作り直さずに App Store と Google Play に出したいなら、この方法が向いているかもしれません。

すばやく選ぶには

あなたの状況	向いている方法
ストア掲載は重要でなく、ウェブ中心で十分	PWA
アプリが中核の製品で、ネイティブ開発チームがいる	ネイティブアプリを作り直す
既存のウェブアプリをできるだけ活かしてストアに出したい	WebView + ネイティブブリッジ

どの方法が無条件に優れている、ということはありません。大事なのは、今持っている製品とチーム、そしてアプリに必要な機能です。アプリそのものが製品の中心なら、作り直すほうが向いているかもしれません。一方、すでにウェブ製品を運用していて、既存のウェブコードを最大限に活かしたいなら、WebView とネイティブブリッジを使う方式が現実的な選択になり得ます。

問題はここからです

WebView を表示すること自体は難しくありません。しかし、実際にストアに配信できるアプリを作るには、次のような部分を自分で作る必要があります。

• iOS と Android のプロジェクト構成
• ネイティブ機能の接続
• JavaScript とアプリの間のブリッジ
• 権限の処理
• プッシュ通知
• 生体認証
• アプリ内課金
• アプリのアップデート
• App Store と Google Play への公開準備

ウェブアプリを作り直す手間は減りますが、ウェブとネイティブの間をつなぎ、保守し続ける作業は依然として残ります。

まさにこの部分を Unveily が助けます。既存のウェブアプリはそのまま保ちつつ、必要なネイティブ機能 — ストア公開、プッシュ通知、生体認証、アプリ内課金 — をつなげられます。ウェブアプリをゼロから作り直さずにネイティブアプリへ拡張したい、そんなときのためのものです。