漸進式網頁應用程式：PWA 何時勝過原生

漸進式網頁應用程式開發，是英國買方在專案開始的頭十分鐘裡排除掉、又在十八個月後重新發現的方案，那時第二套原生程式碼庫已經悄悄吃光了預算。它之所以被排除，是因為關於它的文章幾乎都落在兩個陣營裡：跳過 iOS 拒絕做的那一部分的鼓吹，或者承襲自 2019 年、當時平台確實做不到的懷疑。

兩者現在都錯了，而且錯在會改變成本計算的地方。自 iOS 16.4 起，Safari 已支援加入主畫面的網頁應用程式發送推播通知。Chrome 取消了安裝對 Service Worker 的要求。英國主管機關在 2025 年 10 月認定 Apple 與 Google 在行動瀏覽器與瀏覽器引擎上具有策略市場地位。同時 iOS 仍然拒絕背景執行，會依你無法控制的規則清除已儲存的資料，而且永遠不會把網頁應用程式列進 App Store。

以下是我會交給正在一套程式碼庫與三套之間做選擇的客戶的版本。文中每一項功能主張，都在 2026 年 9 月對照廠商自己的文件核對過，因為這個題目裡的流行說法可靠地落後兩年。

PWA 什麼時候勝過原生應用程式？ 當你的使用者在 Android 和桌面上與在 iPhone 上一樣多時，當應用程式是伺服器而不是裝置的前端時，以及當人們透過搜尋而不是透過應用程式商店找到你時。如果你需要背景定位、主畫面小工具、iPhone 上的藍牙或商店內購結帳，PWA 就輸了。省下的是一套程式碼庫而不是三套，以英國的行情大約是 £40,000 到 £120,000 的建置費，以及此後每年明顯更小的帳單。

漸進式網頁應用程式究竟是什麼

這個名詞被用得夠寬鬆，同一場會議裡的兩個人可能指的是不同的東西。技術定義很窄，值得守住。

MDN 把漸進式網頁應用程式描述為以網頁平台技術打造、能給使用者帶來類似平台專屬應用程式體驗的應用程式。它從一套程式碼庫執行在多個平台上，可以被安裝、離線執行，並與作業系統整合。

在實務上這代表三項產物，缺少其中任何一項的網站，都只是有野心的網站，而不是 PWA。

網頁應用程式資訊清單

資訊清單是一個 JSON 檔，它告訴作業系統這個應用程式叫什麼、要用哪些圖示、啟動時開啟哪個網址，以及要在瀏覽器框架裡執行還是獨立執行。沒有它，瀏覽器就沒有可安裝的東西。它很小、是靜態的，也是整件事裡最便宜的部分。

Service Worker

Service Worker 是一段獨立於頁面執行的腳本，坐在應用程式與網路之間，能夠用快取回應請求。它讓離線行為成為可能，也是接收推播訊息的那一環。它同樣是容易出錯的一環，因為範圍劃錯的快取會連續好幾週把過期的程式碼送給使用者。

HTTPS

Service Worker、推播、地理位置與相機存取都被限制在安全內容中。在今天的主機環境裡這是免費且自動的，所以它是一項限制，而不是一筆成本。

已安裝這件事在各平台上的意義並不相同

買方以為安裝是一種行為。它其實是三種，而其中的差別與生意直接相關。

Android

Android 上的 Chrome 給出最接近對等的效果。應用程式得到一個主畫面圖示、在應用程式切換器裡有自己的項目、有自己的儲存空間，並且可以透過包裝殼列進 Play 商店。在瀏覽器觸發相應事件之後，你可以從自己的介面發起安裝提示，所以由你決定什麼時候開口。

iOS 與 iPadOS

Safari 透過分享表單與其中的「加入主畫面」來安裝。沒有你能主動觸發的頁面內安裝提示，沒有 Apple 會替你顯示的橫幅，也沒有可靠的方法偵測使用者是否已經這麼做了。這一處互動上的缺口，是各平台之間最大的實務差別，而它是設計問題而非工程問題：你必須教會使用者一個手勢。

桌面

Chrome、Edge 與 macOS 上的 Safari 都會把網頁應用程式安裝進 Dock 或工作列，並給它自己的視窗。桌面是 PWA 爭議最少、也最被浪費的地方，尤其是在內部工具上，那裡的替代方案是一套沒人願意維護的 Electron 建置。

Chrome 改了可安裝規則，多數指南卻沒有注意到

多年來每篇文章都重複同一份檢查表：資訊清單、圖示、HTTPS，以及一個實作了 fetch 處理常式的 Service Worker。最後這一項對從選單安裝的路徑已經不再成立。

Google 取消了從選單安裝時必須具備實作 fetch 的 Service Worker 的要求，行動端從版本 108 起，桌面端從 112 起，並且現在為沒有自備離線頁面的網站提供一個預設離線頁面。安裝提示的演算法仍然希望看到 fetch 處理常式，但可安裝性本身已經不再依賴它。

連鎖效應波及了工具鏈。Lighthouse 在 12.0.0 版中整個移除了 PWA 類別，那是 2024 年 4 月發布的版本，因為那些稽核存在的目的就是檢查一批已經不適用的條件。如果你的建置流程還會因為缺少 PWA 分數而失敗，它檢查的是 Google 已經退役的東西。

務實的讀法是：安裝與離線能力已經脫鉤。你可以發布一個完全沒有離線機制的可安裝應用程式，那往往正是正確的第一版，等你知道人們在沒有訊號時真正使用哪些畫面之後，再補上快取。

離線是一個帶著成本的設計決定

離線這個詞掩蓋了極大的範圍落差。一個顯示上次已知資料的快取外殼是一週的工作。一個真正離線優先、會把寫入排入佇列、解決衝突並在重新連線時對帳的應用程式，是另一個產品。

快取策略

Service Worker 的快取歸結為四種模式，以及針對每一類資源的一次判斷。快取優先直接回傳已存副本而從不查核，適合字型與帶雜湊的建置產物。網路優先先試伺服器再退回，適合必須保持最新的資料。stale while revalidate 立刻回傳快取並在背景更新，是內容的常規選擇。僅網路則用於任何絕不能由過期副本作答的東西，例如付款。

把這裡弄錯，是我看過最常見的 PWA 失敗。把快取優先用在應用程式外殼上，會一直把上個月的 JavaScript 送給回訪的使用者，直到有什麼東西強制更新為止，而收到的錯誤回報描述的症狀在你目前的程式碼裡並不存在。

背景同步

在離線時把寫入排入佇列、在連線恢復時送出，正是 Background Synchronization API 的用途。MDN 將它列為有限可用並明確指出它不屬於 Baseline，也就是說它在一些使用最廣泛的瀏覽器裡並不運作。

所以在 iOS 上你要自己寫退路：把佇列保存在 IndexedDB 裡，在應用程式下次被開啟時送出。這樣可行，使用者也接受，而它大約是三到五天的工程量，而不是這個 API 本來只要一個下午的份量。

推播通知決定的專案比任何其他因素都多

如果有一項功能能沉掉一份 PWA 提案，就是它，而且依據通常是 2022 年才成立的事實。

Android 與桌面

Android Chrome、桌面 Chrome、Edge 與 Firefox 上的網頁推播，靠 Push API、Notifications API 與 Service Worker 協同運作已經多年。傳遞由瀏覽器廠商的推播服務負責，授權是一個標準提示，在伺服器向已訂閱使用者送出訊息這個常見情境下，與原生應用程式沒有有意義的差距。

iOS 與 iPadOS

Apple 在 iOS 與 iPadOS 16.4 中加入了 Web Push。附帶的條件才是常被漏掉的部分：WebKit 說明該網頁應用程式必須已被加入主畫面，而且授權必須回應直接的使用者互動來請求，例如點一下訂閱按鈕。對停留在 Safari 分頁裡的網站，網頁推播不會運作。

資訊清單必須把 display 設為 standalone 或 fullscreen，此後通知的表現就和任何其他應用程式一樣：鎖定畫面、通知中心、配對的 Apple Watch，以及設定中依應用程式的開關。標記數字也可用。

Apple 後來又加了一條更簡單的路徑。宣告式網頁推播隨 Safari 18.4 到來，在 iOS 與 iPadOS 18.4 上對加入主畫面的網頁應用程式可用，它不需要 Service Worker 正在執行，就能依據一段標準化的 JSON 內容顯示通知。它減少了工作量，但沒有取消主畫面這個條件。

精確地陳述 iOS 上的落差

落差是真實的，也比它的名聲小。準確地把它說清楚，比抱怨它或假裝它已經消失都更有用。

儲存空間被清除

WebKit 依最近最少使用的原則清除網站資料，其中最後一次使用是從最後一次使用者互動或儲存操作起算。它的儲存政策文件訂出，瀏覽器類應用程式的單一來源配額最高為磁碟的 60%，其他應用程式最高為 15%，整體配額分別為 80% 與 20%，並確認獨立執行的主畫面網頁應用程式與瀏覽器享有相同配額。

由此得出兩點。儲存空間並不是人們想像中的那個限制，而清除是一種時機風險，不是容量風險。把裝置當作快取、把伺服器當作正本，清除就不再是產品缺陷。

背景執行

iOS 上沒有與原生背景工作對等的東西。沒有週期性抓取，沒有背景定位，應用程式關閉期間也沒有靜默處理。任何必須按排程發生的事都發生在你的伺服器上，再透過一則使用者看得見的推播訊息抵達裝置。

無法出現在 App Store

PWA 不能被列進 App Store。如果你有相當比例的顧客期待在商店裡搜尋你的品牌並找到你，那不是你能在網頁這一側解決的工程問題。

瀏覽器引擎、DMA 與 CMA

這一節裡報導跑在一手資料前面，所以值得只談真正被寫進文件的部分。

Apple 現在允許替代瀏覽器引擎，而且明確說明這只適用於歐盟，在 iOS 17.4 或更新版本以及 iPadOS 18 或更新版本上，透過授予符合已公布之安全性、隱私與測試套件標準的開發者的兩項權限來實現。Apple 要求通過 90% 的 Web Platform Tests 與 80% 的 Test262，要求在沒有 JIT 的情況下運作，並要求多數漏洞在 30 天內解決。

對英國企業來說，那些今天不會改變任何事。這些權限是依法域授予的，使用英國電信業者的英國使用者，無論按下哪個瀏覽器圖示，跑的都是 WebKit。

英國這邊在另外推進。2025 年 10 月 22 日，CMA 認定 Apple 與 Google 在其行動平台上具有策略市場地位，涵蓋作業系統、應用程式散布、瀏覽器與瀏覽器引擎，為期五年。認定是施加行為要求的權力，而不是要求本身。請依平台今天的行為做規劃，把任何鬆綁都當成額外收穫。

硬體與裝置 API，以查證取代假設

「網頁存取不了硬體」是我聽得最多的反對意見，也是在具體情境裡最常出錯的那一條。

幾乎到處都能用的功能

透過 getUserMedia 存取相機與麥克風在 MDN 上屬於 Baseline，自 2017 年起就跨瀏覽器可用。地理位置、裝置方向、包含行動端拍照在內的檔案上傳、剪貼簿存取、行動端的 Web Share API，以及透過 WebAuthn 以 Face ID 或指紋作為驗證器的密碼金鑰，在目前的行動瀏覽器裡都能用。用相機串流做條碼與 QR Code 掃描也是家常便飯。

對絕大多數商業應用程式來說，這份清單就是全部的硬體需求。

只在 Chromium 上、行動端實際只在 Android 上的功能

Web Bluetooth 被 Google 記載為在 ChromeOS、Chrome for Android 6.0、Chrome 56 起的 macOS 以及 Chrome 70 起的 Windows 10 上可用，沒有列出 iOS 支援，MDN 也把它標為有限可用而非 Baseline。Web NFC 的範圍更窄：Google 記載為在 Android 上隨 Chrome 89 可用。

用來讀寫使用者選定檔案的 File System Access API 同樣是 Chromium 的地盤，不過來源私有檔案系統在各瀏覽器上已經能涵蓋應用程式內部儲存的大部分需求。

應用程式商店散布是商業問題，不是技術問題

團隊爭論商店散布時，彷彿那是能力問題。它其實牽涉四個商業變數，其中只有一個明確對商店有利。

被找到是誠實的優勢。消費者確實會依品牌與類別在 App Store 與 Play 上搜尋，沒有商店存在感的企業就放棄了那條管道。對有辨識度名字的消費性產品，它極其重要；對一家公司裡兩百名員工使用的工具，它幾乎無關緊要。

信任是真實存在的，而且因受眾而不對稱。年長與技術上不熟悉的使用者會把商店頁面讀成安全訊號。年輕使用者越來越不這樣，同一個人會在同一支手機上安心使用銀行的網站。

相對地，商店在你和使用者之間加上一道審查佇列、一份因規則變動而被退件的風險，以及你在應用程式內販售任何東西時的抽成。PWA 一項都沒有。你決定什麼時候發布，而關鍵修正會在使用者下一次載入時抵達每個人，而不是等審查之後。

商店實際上抽走多少

抽成數字變動得夠頻繁，靠記憶報數並不明智。以下是廠商自己公布的條款，在 2026 年 9 月核對過。

Apple 對數位商品與服務收取 30% 的標準佣金。App Store Small Business Program 把這個比例降到 15%，適用於前一個曆年收益不超過 1,000,000 美元的開發者，新開發者也符合資格，而一旦你在某一年內越過該門檻，之後的銷售就恢復標準費率。

Google 公布了分級的 Google Play 服務費：每年開發者營收的前 100 萬美元為 15%，超過的部分為 30%，自動續訂的訂閱無論營收多少一律 15%。同一個頁面也列出自 2026 年 6 月 30 日起在歐洲經濟區、英國與美國生效的另一套結構，依安裝屬於新增或既有分別為 10% 或 20%，另加 5% 的帳務手續費。

兩家廠商都以美元公布。以 15% 透過商店銷售一份每月 £9.99 的訂閱，每位訂閱者每年約為 £18，以 30% 則約為 £36。在斷定商店是免費的之前，先乘上你的訂閱人數。

你依然可以透過 Google Play 發布 PWA

Android 同時給你兩個選項，這是平台比較中一處真實的不對稱，而且很少被提起。

Trusted Web Activity 是一個 Android 應用程式，它以全螢幕開啟你自己的 PWA，不帶瀏覽器介面，並透過 Digital Asset Links 驗證它屬於你。它需要 Android 上的 Chrome 72 或更新版本，而宿主應用程式無法存取網頁內容的 Cookie 或儲存空間。實務上它就是一層由你的資訊清單產生的薄殼，像任何其他應用程式一樣送交 Play。

所以在 Android 上，選擇不是商店或網頁。你發布 PWA，把它包起來，用同一套程式碼庫，花幾天的封裝工作與一年的開發者帳號費用，就同時拿到商店上架。

iOS 上沒有對等的做法。Apple 的審查指南長期認為，只是包裝一個網站本身並不足夠，所以走 iOS 商店這條路就代表做真正原生的東西。比起任何 API 落差，正是這處不對稱形塑了下面的成本表。

漸進式網頁應用程式開發成本與兩套原生程式碼庫的比較

人們會做的比較是建置成本，那是比較小的一半。決定結果的比較是三年總成本，因為原生的開銷是重複發生的。

請把這些讀成中等複雜度商業應用程式的英國代理商價格帶，而不是報價。這種形態的 PWA 通常是一支兩到三名工程師的團隊做三到五個月。兩套原生程式碼庫再加上網頁存在感，就是三支團隊、三條發布流程，以及每年三套平台升級。

第一列與第三列之間的差距，建置上大約 £75,000 到 £175,000，此後每年大約 £27,000 到 £60,000，就是你買原生時買到的東西。有時這筆錢花得很值。它應該是一個決定，而不是一個預設值。我們的網站開發與軟體開發頁面說明了我們如何為這兩條路線界定範圍。

維護的錢究竟花到哪裡去了

建置成本會被議價。維護成本是被發現的，也正是多程式碼庫專案安靜而非響亮地失敗的地方。

原生平台每年都強加工作給你。新的系統大版本淘汰 API，簽章與佈建設定變更，最低 SDK 等級提高，商店政策又添上隱私資訊清單與資料安全聲明之類的要求。這些都不會交付任何功能。在兩個平台上你要照別人訂的時程付兩遍。

接著是偏移。實作同一功能的兩套程式碼庫會分岔，而分岔會以只在一個平台上重現的支援案件形式浮現。每個產品決定都得做兩遍再對齊，而這份協調成本不會出現在任何一張發票上。

PWA 用瀏覽器的演進取代了上面這一切，而瀏覽器演進是連續的、向後相容的，幾乎不會弄壞正在運作的程式碼。重複發生的工作是你自己的相依套件更新、安全性修補與主機代管，這與任何客製化網頁應用程式本來就需要的維護完全相同。

真正要緊的比較不是提案上的兩個數字。它是一支團隊對三支團隊，年復一年，只要產品還活著。

PWA 的效能與 Core Web Vitals

已安裝的應用程式會被拿去和原生比，所以效能門檻比網站更高而不是更低。好消息是這些指標是公開的，門檻是固定的。

Core Web Vitals 目前由三項指標組成，每一項都在頁面載入的第 75 百分位上評估，並依行動端與桌面端分開。Largest Contentful Paint 在 2.5 秒以內為良好，超過 4.0 秒為差。Interaction to Next Paint 在 2024 年穩定後取代了 First Input Delay，在 200 毫秒以內為良好，超過 500 毫秒為差。Cumulative Layout Shift 在 0.1 以內為良好，超過 0.25 為差。

PWA 在這裡有一個結構性優勢。Service Worker 從快取提供外殼，會讓重複造訪接近瞬時，而這正是已安裝應用程式產生的模式，所以已安裝 PWA 的真實使用者資料，通常比同樣的程式碼在瀏覽器裡冷啟造訪時更好看。

它也有一個結構性風險。單頁框架把工作推給用戶端，而 INP 正是懲罰這一點的指標。如果你已經在和這些數字纏鬥，我們關於通過 Core Web Vitals 的指南對診斷的展開比本文更深。

SEO 是沒人計價的那項優勢

這是我在多數商業情境會第一個提出的論點，而它幾乎總是被整個漏掉。

PWA 就是網站。每個畫面都有網址，每個網址都可以被爬取、被索引、被連結、被分享，每一個都能取得排名。原生應用程式一項都沒有。應用程式商店的上架只被淺層索引，在一座圍牆花園裡依完全不同的訊號排名，而應用程式內部的內容對搜尋不可見。

後果會累積。投在原生應用程式上的行銷支出買到的是安裝量，支出停下的那天它也停下。同樣的支出投在 PWA 的內容與技術品質上，買到的是一個持續取得排名的頁面。放到三年來看，這個差額常常超過兩條路線中任何一條的全部建置成本。

只有在實作是可爬取的時候它才會兌現，而這正是用戶端渲染的應用程式出問題的地方：把一切都用 JavaScript 繪製、只有一個網址、沒有伺服器產生的 HTML，就等於完全放棄了這項優勢。對需要被索引的路由做伺服器渲染或預先渲染是解法，而上線前的一次技術 SEO 稽核，遠比半年後才發現什麼都沒被索引便宜得多。

會直接否決的需求

把這個決定寫成否決清單，比寫成好處清單更容易，因為否決項是客觀的。

如果下列任何一項是真實需求而不是願望，你就需要原生。應用程式關閉時的背景位置追蹤。主畫面小工具、手錶應用程式，或者 CarPlay 與 Android Auto 整合。iPhone 上的藍牙或 NFC。HealthKit、應用程式內 Apple Pay，或任何 Apple 尚未向網頁開放的深度系統整合。商店政策要求時的數位商品商店結帳。持續的重運算，例如即時影片處理或以原生影格率做 3D 繪製。作為你的事業真正仰賴之行銷條件的 App Store 存在感。

如果上面一項都不適用，PWA 很可能就是正確答案，而舉證責任落在想要三套程式碼庫的那一方。

還有兩點考量會進一步推動結論。如果你的使用者主要在桌面或 Android 上，iOS 上的缺口只影響你受眾中的少數。而如果應用程式是你自己伺服器的前端而不是裝置的前端，這描述的正是大多數商業軟體，那麼裝置功能幾乎無關緊要。

情境一，一家設施承包商的現場服務

兩百名工程師、工單、完工照片、簽名擷取，以及機房與地下室裡時斷時續的訊號。這是人們以為需要原生的情境，也是 PWA 贏得最清楚的情境。

每一項需求都被涵蓋。相機透過 getUserMedia 運作。簽名是一個 canvas 元素。工單資料快取在 IndexedDB 裡，寫入佇列在重新連線時送出，因為 Background Sync 跨瀏覽器並不可靠，所以這部分是手寫的。派工提醒以網頁推播送出，在 Android 上可用，在 iOS 上對已把應用程式加入主畫面的工程師可用，而安裝是到職訓練裡五分鐘的一個項目，不是使用者取得問題。

沒有商店曝光的需求，因為使用者就是員工。沒有結帳，所以抽成無關。裝置是 Android 與 iOS 混用，而這正是最狠地懲罰兩套原生程式碼庫的情況。

用 £45,000 到 £70,000 建一個 PWA，而不是用 £120,000 到 £200,000 做兩個原生應用程式，當天下午就能發布修正而不必等審查，再把差額花在真正決定這東西好不好用的派工後端上。

情境二，一家想要預約與提醒的美髮連鎖

十四家門市、面向消費者、預約排程、提醒、集點方案，付款在櫃檯而不是應用程式內完成。直覺反應是做個原生應用程式，因為競爭對手有一個。

需求清單平淡無奇：預約表單、行事曆、提醒、帳戶區。只有提醒有點意思，而在這個市場裡簡訊與電子郵件比推播更合適，因為一年預約兩次的顧客不會安裝任何東西。

決定性因素是被找到，而它壓倒性地偏向網頁。人們透過搜尋與地圖找美髮店，而不是靠翻應用程式商店，所以介紹服務並接受預約的頁面需要取得排名。原生應用程式在那裡完全看不見。網站本身的成本才是真正的預算項目，應用程式這一層是以可安裝性的形式加在上面的。

把預約網站認真做好，讓它可安裝，好讓常客把它留在主畫面上，再為願意開啟的少數人加上網頁推播。這裡做原生要花 £80,000 以上，觸及的顧客卻比網站已經觸及的更少。

情境三，一項訂閱制健身產品

有教練帶的訓練、影片內容、穿戴裝置整合、每月 £12.99、直接面向消費者、靠付費獲客成長。這個情境的結論走向相反，值得說明原因。

商店曝光在這裡是有效的，因為健身是一個人們會瀏覽的類別，上架是一條真實的獲客管道。穿戴裝置整合代表 HealthKit，網頁碰不到。訓練過程中的背景音訊與螢幕恆亮行為在原生上更好。大規模的離線影片下載在網頁上可行，但並不舒服。

有意思的是結帳。每月 £12.99 的商店抽成，以 15% 計每位訂閱者每年約 £23，以 30% 計約 £47，在 20,000 名訂閱者的規模上就是每年 £460,000 到 £940,000。這是一個有力的論據，支持在網頁上收款、把應用程式當成用戶端，好幾家大型訂閱產品現在正是這麼做的。

答案是：產品本身用原生應用程式，註冊、計費與內容行銷用 PWA 或一般的網頁應用程式。兩者都存在，而這種切分是刻意的，不是偶然的。

如何在一個下午做出決定

這個決定不需要一個探索階段。它需要四個寫下來的答案。

第一，列出你真正需要的裝置功能，然後逐條對照廠商自己的文件查證，而不是對照某份摘要。多數清單在這一步會急遽變短。第二，弄清楚你的使用者從哪裡來：如果答案是搜尋，網頁已經占優；如果是在商店裡瀏覽，那就不占優。

第三，以三年而不是一年為所有三條路線定價，把上面的維護數字算進去，也把你打算銷售之物的商店抽成算進去。第四，對自己的團隊誠實一點。三名工程師維護一套程式碼庫交付的東西，每一次都比三名工程師維護三套程式碼庫更多。

如果這樣之後答案仍然模糊，先做 PWA。它是比較便宜的那個可逆選項。日後從 PWA 走向原生，代表針對一套已經存在並被驗證過的 API 去寫原生用戶端，反過來則代表從頭再來。這處不對稱，比上面絕大多數功能比較都更值錢。

這把你帶到哪裡

漸進式網頁應用程式開發不是給買不起原生的人的將就，也不是萬用答案。它是一大類可界定產品的正確架構：商業軟體、內部工具、預約與帳戶系統、內容產品，以及任何顧客經由搜尋而來的東西。

iOS 上的缺口是真實的、具體的，而且多半可以繞過而不是致命的。只要使用者安裝了，推播就能用。儲存空間很充裕但會被清除。背景執行不存在，而它本來就屬於你的伺服器。藍牙與 NFC 在 iPhone 上不會運作，多少工程投入也改變不了這一點。

Mecanik 兩條路線都做，並且會在答案是原生時直說。如果你想讓這場比較跑在你真實的需求上而不是一份通用清單上，我們的網站開發與軟體開發頁面描述了我們如何界定範圍，而我們關於在 2026 年打造網頁應用程式的指南，談的是隨之而來的技術堆疊決策。

常見問題

什麼是漸進式網頁應用程式？ 漸進式網頁應用程式是用網頁技術打造、行為上像平台專屬應用程式的應用程式。技術上它是一個透過 HTTPS 提供的網頁應用程式，配有描述名稱、圖示與啟動行為的網頁應用程式資訊清單，以及一個能用快取回應請求並接收推播訊息的 Service Worker。MDN 把它定義為從一套程式碼庫執行在多個平台上、同時保持可安裝並能離線運作的軟體。

PWA 能在 iPhone 上發送推播通知嗎？ 可以，但有一個條件。Apple 在 iOS 與 iPadOS 16.4 中加入了 Web Push，但 WebKit 要求該網頁應用程式必須先被加入主畫面，而且授權必須回應直接的使用者互動來請求，例如點一下訂閱按鈕。對執行在 Safari 分頁裡的網站，推播不會運作。iOS 與 iPadOS 18.4 中加入的宣告式網頁推播簡化了實作，但保留了同樣的主畫面條件。

在英國做漸進式網頁應用程式開發要花多少錢？ 對於中等複雜度的商業應用程式，建置單一 PWA 程式碼庫預計 £35,000 到 £75,000，每年維護 £8,000 到 £20,000。與之相當的原生路線，也就是分別做 iOS 與 Android 應用程式再加一個行銷網站，建置為 £110,000 到 £250,000，此後每年 £35,000 到 £80,000。這些是英國代理商的價格帶而不是報價，而重複發生的差額通常比建置差額更要緊。

可以把 PWA 放進 App Store 或 Google Play 嗎？ Google Play 可以，App Store 不行。在 Android 上，Trusted Web Activity 用一層薄薄的原生外殼包住你的 PWA，並透過 Digital Asset Links 驗證，於是同一套程式碼庫只要幾天的封裝工作就能拿到 Play 上架。Apple 沒有對等做法，其審查指南認為只是包裝一個網站並不足夠，所以 App Store 存在感代表做真正原生的東西。

什麼時候應該選原生應用程式而不是 PWA？ 當你需要應用程式關閉時的背景定位、主畫面小工具、手錶或車機整合、iPhone 上的藍牙或 NFC、HealthKit 或應用程式內 Apple Pay、即時影片處理這類持續的重運算，或者把 App Store 存在感當成一條真實獲客管道時，就選原生。如果這些都不適用，PWA 很可能是正確的，舉證責任落在想維護三套程式碼庫的那一方。