iOS Web Push 通知完整指南：Safari、PWA 設定與網頁推播教學

從 iOS／iPadOS 16.4 起，iPhone 與 iPad 已支援標準化的 iOS Web Push 通知。不過，它和桌面版 Safari 或 Android 瀏覽器的使用方式不同：網站必須先被加入主畫面，使用者再從主畫面開啟 Web App，並主動點擊訂閱按鈕，系統才會顯示通知權限要求。

本文將介紹 iOS Web Push、Safari Web Push 與 PWA 推播通知的支援條件，並提供使用者端啟用步驟、開發者串接清單、透過 EngageLab 設定 iOS 網頁推播通知的流程及常見問題排查方法。

iOS Web Push 支援條件與限制

Apple 的 Web Push 採用跨瀏覽器標準，包括 Push API、Notifications API、Badging API 與 Web App 技術。通知透過 Apple Push Notification service（APNs）傳送，但採用標準 Web Push 時，網站不需要加入 Apple Developer Program，也不需要為 iPhone Web Push 申請傳統 APNs 憑證。

iOS 與 iPadOS 的關鍵限制是：通知只提供給已加入主畫面的 Web App。使用者在一般 Safari 分頁瀏覽網站時，不能直接完成 iOS Web Push 訂閱。

iOS Safari 通知可以顯示哪些內容？

不同作業系統與瀏覽器支援的通知欄位不完全相同。iOS／iPadOS 可使用通知標題、文字、點擊後開啟的 URL 與站點圖示，但不應把圖片、GIF 或操作按鈕列為 iOS Safari 的必要設計。

Apple 也已為 iOS／iPadOS 18.4 以上的主畫面 Web App 提供 聲明式 Web Push。它使用標準化 JSON 描述通知，並可和既有 Web Push 實作保留相容路徑。若要採用，應先確認 EngageLab SDK 與目前專案版本的支援狀態，不要直接替換既有正式環境設定。

如何在 iPhone／iPad 啟用 Web Push 通知

網站完成技術串接後，仍需要使用者完成加入主畫面與授權。建議在頁面上先說明通知價值，再引導操作；不要一進站就顯示沒有上下文的系統權限要求。

1. 確認系統版本

前往「設定」查看 iOS 或 iPadOS 版本，裝置需為 16.4 或以上。

2. 將網站加入主畫面

在 Safari 開啟網站，點選分享按鈕，再選擇「加入主畫面」。若使用其他瀏覽器，是否顯示此入口取決於瀏覽器與系統版本。

3. 從主畫面開啟 Web App

離開瀏覽器，點擊剛加入的網站圖示。不要留在原本的 Safari 分頁中進行訂閱。

4. 點擊網站內的訂閱按鈕

點選「開啟通知」或相同用途的按鈕。權限要求必須緊接著這次使用者操作觸發。

5. 允許通知並完成測試

在系統視窗選擇「允許」，再發送一則測試通知，確認鎖定畫面、通知中心與點擊跳轉均正常。

開發者串接 iOS Web Push 的前置條件

控制台可以讓營運人員在完成串接後無程式碼建立推播活動，但網站第一次啟用 Web Push 仍需要開發設定。開始前請確認以下條件：

• 網站使用有效的 HTTPS 網域，並能在真實裝置上存取。
• 頁面正確引用 Web App Manifest，並設定 display、start_url、名稱與圖示。
• 已整合 EngageLab Web SDK，並正確部署接收訊息所需的 Service Worker。
• Service Worker 的路徑與 scope 能控制需要訂閱的頁面，且不會和既有 PWA Service Worker 衝突。
• 權限要求由使用者點擊觸發，不在頁面載入時自動執行。
• 後端可安全保存訂閱 endpoint 與加密金鑰，並處理失效或取消的訂閱。
• 若企業網路限制外部連線，允許連往 *.push.apple.com。

如何使用 EngageLab 設定 iOS Web Push

EngageLab WebPush 提供 Web SDK、推播控制台、分眾、排程與成效分析。正確流程可分成「一次性的技術接入」與「後續無程式碼發送」兩個階段。

1. 建立 WebPush 應用程式

   登入 EngageLab 控制台並建立應用程式，取得用於識別應用的 AppKey。Master Secret 僅供需要的伺服器端 API 流程使用，不應公開在文章或前端程式碼中。

2. 設定 HTTPS 網域

   在 WebPush 的整合設定中填寫正式 HTTPS 網域。測試頁面必須能從 iPhone／iPad 實際開啟。

   

3. 部署 SDK、Manifest 與 Service Worker

   依最新 Web SDK 串接文件下載並部署檔案，設定 Manifest 與 Service Worker 路徑，再完成 SDK 初始化。不要從舊文章複製固定版本號。

   

4. 設計訂閱提示與使用者識別

   先用自訂提示解釋通知價值，再由按鈕觸發系統權限。若要做分眾或跨裝置管理，依隱私政策設計穩定且合規的使用者識別方式。

   

5. 用真實裝置完成端對端測試

   測試加入主畫面、訂閱、背景接收、鎖定畫面顯示、通知中心、點擊跳轉、取消權限與重新安裝等情境。

   

6. 在控制台建立推播活動

   技術接入完成後，營運人員即可在控制台建立通知，設定標題、內容、發送時間與受眾，預覽後再發送。

   

如何提升 iOS Web Push 訂閱率與轉換率

iOS Web Push 能協助網站重新觸達訪客，但使用者必須先將網站加入主畫面，再從 Web App 允許通知。因此，優化時不能只關注推播文案，還需要改善安裝、授權、發送與轉換的完整流程。

• 1

  提升加入主畫面的完成率

  iOS 比其他平台多了一個「加入主畫面」步驟。請根據使用者的瀏覽器與裝置顯示對應說明，搭配清楚的截圖或動畫指出分享按鈕及「加入主畫面」的位置。

  完成安裝後，應繼續引導使用者從主畫面開啟 Web App，再進入通知訂閱流程，避免使用者停留在原本的瀏覽器分頁中。

• 2

  在要求權限前說明通知價值

  不要在使用者首次開啟網站時立即顯示系統權限視窗。建議先用自訂提示說明會收到什麼內容、發送頻率以及如何取消。

  例如「商品補貨與降價時通知，每週最多兩則」，會比單純顯示「允許通知」更容易讓使用者理解訂閱價值並做出知情選擇。系統權限要求則必須緊接著使用者點擊按鈕等明確操作觸發。

• 3

  依行為、偏好與階段進行分眾

  不同使用者關注的內容與可接受的通知頻率並不相同。可依瀏覽內容、購買階段、地區、語言、互動紀錄及使用者主動選擇的主題建立分眾，並持續更新標籤。

  個人化不應只是加入姓名，而是讓通知內容與當下需求相關。例如，向瀏覽過特定商品的使用者發送補貨通知，或向已購買用戶提供使用提醒，通常比向所有人發送相同促銷更有效。

  避免使用缺乏來源的「開啟率提升數倍」等承諾，應以實際測試數據驗證不同分眾與個人化策略的效果。

• 4

  控制發送頻率並選擇合適時機

  通知過多是使用者關閉權限或取消訂閱的常見原因。應為促銷、交易、內容更新及服務提醒等不同通知類型設定頻率上限，避免在短時間內重複觸達。

  可根據使用者過往開啟 Web App、點擊通知和完成轉換的時間安排發送，並透過 A/B 測試比較不同時段。若缺乏足夠數據，可先從符合使用者當地作息的合理時間開始測試。

  除了系統通知設定，網站內也應提供通知主題、發送頻率與取消訂閱入口，讓使用者能自行調整偏好。

• 5

  用簡短文案完成單一目的

  每則通知應聚焦一個目的。標題先說明事件，內文再補充利益、時效或下一步，點擊後直接前往對應頁面。

  例如「您關注的商品已補貨」搭配「庫存有限，點擊查看可選尺寸」，會比「快來看看最新優惠」更具體，也更容易促成點擊與轉換。

  可適度使用表情符號，但不要依賴 GIF、大圖或通知操作按鈕傳達關鍵資訊，因為不同 iOS、Safari 及 Web Push 通道的顯示能力可能不同。重要內容必須只靠標題、內文與點擊跳轉也能被完整理解。

• 6

  衡量完整的 Web Push 轉換漏斗

  只看通知點擊率，無法判斷整體策略是否有效。建議同時追蹤以下指標：

  • 加入主畫面完成率： 看到安裝引導後，完成加入主畫面的使用者比例。
  • 通知授權率： 從主畫面開啟 Web App 後，同意接收通知的使用者比例。
  • 送達率： 成功送達的通知占有效目標訂閱數的比例。
  • 點擊率： 點擊通知的使用者占成功送達通知的比例。
  • 最終轉換率： 使用者點擊後完成購買、註冊、回訪或其他核心行為的比例。
  • 退訂與停用率： 用來判斷發送頻率、內容或分眾策略是否造成通知疲勞。

  建議定期比較不同分眾、發送時間、文案與落地頁的表現，保留能提升最終轉換且不增加停用率的方案。

若要了解更多跨瀏覽器的策略與測試方法，可延伸閱讀 企業用瀏覽器推播提升轉換率的完整指南；需要進一步了解 PWA 的運作方式，可參考 PWA 推播通知：定義、範例及好處。

iOS Web Push 常見問題

iPhone Safari 支援 Web Push 通知嗎？

支援。裝置需使用 iOS 16.4 或以上，而且網站必須先加入主畫面。使用者要從主畫面開啟 Web App，才能在網站內透過點擊觸發通知權限要求。

一定要把網站加入主畫面嗎？

是。iPhone 與 iPad 的標準 Web Push 目前以主畫面 Web App 為使用情境，一般 Safari 分頁不能直接完成訂閱。

需要 Apple Developer 帳號或 APNs 憑證嗎？

標準化的 iOS Web Push 不需要加入 Apple Developer Program。舊版 macOS Safari 的傳統 Safari Push 憑證流程是另一套機制，不應和 iPhone／iPad 16.4+ 的標準 Web Push 混為一談。

Safari 關閉後還能收到通知嗎？

完成有效訂閱後可以。Safari Web Push 由系統層級傳送可見通知，不要求瀏覽器視窗保持開啟。

為什麼點擊訂閱後沒有出現權限要求？

先確認是否從主畫面 Web App 開啟、系統版本是否達 16.4、網站是否為 HTTPS，以及權限是否曾被拒絕。開發端還要檢查 Manifest、Service Worker、SDK 初始化與按鈕觸發時機。

iOS Web Push 支援圖片和操作按鈕嗎？

依 EngageLab 目前的 Safari 功能表，iOS／iPadOS 不支援通知圖片與操作按鈕。因此，通知必須在純文字與單一點擊跳轉的情況下仍能傳達完整訊息。

結論

iOS Web Push 能讓網站在沒有原生 App 的情況下重新觸及 iPhone 與 iPad 使用者，但它的成功關鍵不只在發送內容。網站必須先符合 HTTPS、Manifest 與 Web Push 串接要求，使用者也必須完成加入主畫面和主動授權。

EngageLab 可協助企業完成 Web Push 串接、受眾分群、排程發送與成效分析。建議先以一個真實情境完成端對端測試，再逐步優化安裝率、授權率、送達率、點擊率與最終轉換。