本篇文章更新時間：2026/01/02
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
蘋果終於鬆綁？日本限定的替代瀏覽器引擎政策深度解析
副標題：這不是「自由上路」，而是蘋果精細控管下的有限開放
編輯前言：這篇文章源自蘋果官方文件：Using alternative browser engines in Japan。蘋果首次允許在 iOS 上使用非 WebKit 的瀏覽器引擎，但僅限日本，且條件嚴苛。這篇讀後筆記試著整理核心規範，並談談這對開發者與網路生態代表什麼意義。
核心觀點 (Key Takeaways)
- 蘋果在 iOS 26.2 允許日本的兩類 App 使用替代引擎：完整瀏覽器 App、以及由「引擎維護者」所提供的嵌入式瀏覽器體驗。
- 要獲得授權，開發者必須通過嚴格的測試標準（例如 90% Web Platform Tests、80% Test262）、遵守高水準安全與供應鏈管理要求。
- 這並非全面開放，而是高度技術化、重度審查的「有限鬆綁」策略，用以兼顧生態控制與監管壓力。
深入解析
這份文件非常長、規範極細，但核心精神其實很一致：蘋果願意開放 WebKit 以外的引擎，但不是讓你「隨意玩」，而是要確保安全、隱私與品質能維持在蘋果標準之上。
文件明確指出：
browser engines are constantly exposed to untrusted and potentially malicious content
因此，蘋果將使用替代瀏覽器視為高風險活動，並設置大量門檻。
一、兩種授權：Web Browser Engine 與 Embedded Browser Engine
蘋果定義了兩種類型：
- Web Browser Engine Entitlement：給完整瀏覽器使用（Chrome、Firefox 這類）。App 必須能成為預設瀏覽器。
- Embedded Browser Engine Entitlement：給 App 內嵌瀏覽功能用，但申請者必須是「引擎維護者」本身，而不是一般 App 開發者。
兩者都限定「只在日本」使用，是明顯的區域性政策實驗。
二、技術門檻高到近乎「只剩大型瀏覽器可申請」
功能測試要求包括：
- 90% Web Platform Tests
- 80% Test262（ECMAScript 標準測試）
- Lockdown Mode 無 JIT 時也要能通過
換句話說，只有 Chromium、Gecko 這等級的成熟引擎才有可能達標。個人或小團隊自製引擎幾乎不可能通過如此大規模的測試與審查。
三、極度嚴苛的安全要求（重點在持續更新）
蘋果要求開發者必須：
- 使用 memory-safe 語言或安全特性（例如 Swift、或 C++ 的安全 API）
- 採用 PAC、MIE 這些 iOS 的低階安全機制
- 30 天內修補已被利用的漏洞
- 公開漏洞揭露政策與更新紀錄
從文件語氣感受得到，蘋果希望：如果讓你用自己的引擎，你必須做到跟 WebKit 團隊同級別的安全維運品質。
四、隱私規範同樣超嚴格
瀏覽器預設必須：
- 阻擋第三方 Cookie
- 資料隔離以網站為單位
- 禁止在不同 app 間同步 Cookie（除非用戶明確允許）
- 標記所有網路連線供 App Privacy Report 使用
這些條件與 Safari「強化隱私」的方向一致，可看出蘋果強烈希望即便引擎換了，使用者的隱私體驗不能變差。
筆者心得與啟發
這篇文件讓我最大震撼的不是「蘋果開放非 WebKit」，而是：原來蘋果可以透過大量安全、隱私與品質的規範，把開放做到「幾乎只有大廠玩得起」。
我會把這解讀為：
- 這是一種策略性的監管回應，而不是市場競爭導向的開放。 地方法規壓力（尤其來自日本公取委與全球反壟斷環境）讓蘋果必須做出調整，但蘋果仍掌握生態底層規則。
- 短期內，日本 iOS 的瀏覽器仍不會有大變化。 想像「電池續航更好、效能更快的 Chrome iOS」也許還很遙遠，因為蘋果仍掌控 JIT、系統 API、引擎安全標準。
- 長期來看，這可能是蘋果全球政策的前兆。 如果日本的效果良好、監管壓力持續，未來可能擴大到更多地區。
對開發者來說，這是一個重要訊號：瀏覽器引擎正在回到競爭舞台，而不只是 Safari 一家獨大。如果你關注 Web 技術，這會是一場值得追蹤的長期變革。