iOS App 本地提醒怎麼做？2026 學生入門教學

症狀：待辦 App 有任務，卻不知道怎樣在指定時間提醒使用者。
最快解法：先請求通知授權，再設定通知內容和觸發條件，最後測試允許、拒絕及 App 前台時的處理方式。

這篇適合正在製作課程表、待辦或學習計畫 App 的學生，跟著完成一次本地提醒練習。
剛開始學 Swift 的你，可以藉此分清授權、通知內容和觸發條件的先後次序。
如果你主要使用 Windows，也能據此判斷何時需要可執行 Xcode 的 Mac 環境來建置與驗收。

iOS App 本地提醒怎麼做：先選本機排程，不要混成推送

課程作業的提醒若可在使用者裝置上預先安排，就從本地通知開始。先向使用者取得通知授權，建立標題、內文及觸發條件，再把通知請求交給系統排程；這和伺服器收到新事件後發送推送通知，是兩種不同做法。Apple 的 User Notifications 說明涵蓋通知的建立與處理方式。

先拿「明天下午交作業」當例子：提醒文字告訴使用者要做什麼，觸發條件描述何時讓系統處理這個請求。UserNotifications 是通知功能的框架名稱，UNUserNotificationCenter 則是你管理通知授權、排程及相關互動時會用到的介面。

不要先加權限，再想通知要解決什麼問題。沒有明確提醒需求的課程專案，可能只會多出一次打斷使用者的授權請求，卻沒有帶來相應功能。

排程前先比較本地通知與伺服器推送

兩種通知的分別，先看提醒所需的資料是否已在使用者裝置上。課程截止時間已知、只需預先提醒，通常先評估本地通知；如果觸發依賴伺服器上的新事件，才評估推送。

這個評分是按練習範圍和依賴項目作的實作判斷，不是送達速度或可靠度的測試結果。兩種方式都不要承諾通知必定在指定秒數出現；驗收時應以實際執行環境和課程要求為準。

先取得授權，再把拒絕當成正常狀態處理

通知授權代表使用者是否同意 App 透過系統通知呈現提醒。先用簡短文字解釋通知用途，再按功能需要請求授權；Apple 的授權流程說明和 requestAuthorization API 文件可用來核對請求方式。

import UserNotifications

let center = UNUserNotificationCenter.current()

center.requestAuthorization(options: [.alert, .sound, .badge]) {
    granted, error in

    if let error {
        print("授權請求發生錯誤：\(error)")
        return
    }

    print("使用者是否允許通知：\(granted)")
}

這段程式只處理授權請求，不代表提醒已建立，也不代表使用者一定會看到通知。收到結果後，要讓 App 根據狀態回應：允許時才繼續提供通知功能；拒絕時，待辦清單和作業資料仍應可用，並清楚說明提醒無法透過系統通知呈現。

不要只保存第一次請求的結果，之後就當成永久狀態。使用者可能在系統設定中更改選項；要顯示目前通知設定時，可用 getNotificationSettings API讀取狀態，再更新 App 內的提示。

設定通知內容與觸發條件，再交給系統排程

通知內容和時間條件分開設定，較容易查錯。內容可放入標題與內文；觸發條件則描述系統何時處理請求。Apple 的本地通知排程文件說明，App 可建立通知請求並交由系統安排。

以下例子用相隔 60 秒的觸發條件測試「作業提醒」流程；這是示範用的測試設定，不是準時送達保證。UNTimeIntervalNotificationTrigger 的參數用途可對照初始化方法文件。

let content = UNMutableNotificationContent()
content.title = "作業提醒"
content.body = "檢查課程作業是否已完成。"
content.sound = .default

let trigger = UNTimeIntervalNotificationTrigger(
    timeInterval: 60,
    repeats: false
)

let request = UNNotificationRequest(
    identifier: "assignment-reminder",
    content: content,
    trigger: trigger
)

UNUserNotificationCenter.current().add(request) { error in
    if let error {
        print("加入通知請求失敗：\(error)")
    }
}

範例中的 add 是把請求交給系統，不應把它當成「通知已在畫面出現」的驗收證據。若要改成按課程日期安排，應按需求選擇相應觸發條件，並確認提醒時機符合專案規格。

按條件分流：先測哪條路，再決定要不要切換環境

依照你目前的課程要求選擇，不要為了測通知功能就先增加不必要的服務端工作：

• 若提醒內容和時間在使用者裝置上已知，選本地通知；否則再確認是否真的需要由伺服器端事件觸發。
• 若使用者拒絕通知，保留核心待辦功能並顯示清楚回饋；不要把拒絕當作 App 故障。
• 若課程要求以 Xcode 建置或執行專案，且你目前只有 Windows，先準備可使用的 Mac 環境；若只要求提交程式碼，先依課程規定確認是否必須完成 Mac 上的驗收。
• 若提醒在 App 使用中時沒有如預期呈現，檢查前景通知的處理方式；Apple 的通知處理文件列出通知及相關動作的處理說明。

完成排程後，按前景、授權和設定逐項驗收

依序走完以下步驟，才能分辨是請求沒有加入、授權未開啟，還是前景處理方式不同：

1. 確認提醒需求：寫下提醒內容、預定時機，以及使用者在收到提醒後要做的事。課程要求若只有本機待辦提醒，就不要先加入伺服器推送。
2. 確認請求授權的時機：在使用者理解提醒用途後再請求通知授權，記錄允許及拒絕時 App 各自如何回應。
3. 加入測試請求：先用簡單、容易觀察的觸發條件，確認程式能建立內容與觸發條件，並處理排程回呼中的錯誤。
4. 分開檢查前景與非前景狀態：App 正在使用時，依照通知處理邏輯檢查呈現；App 不在前景時，也要在實際執行環境觀察結果。不要從其中一種狀態推定另一種必定相同。
5. 處理拒絕或設定變更：拒絕授權時確認核心功能仍能操作；之後更改系統通知設定，再讀取狀態並檢查 App 的回應。
6. 按課程要求記錄結果：記下執行環境、授權狀態、觸發條件與觀察結果。若結果未出現，先查授權、觸發設定及系統通知設定，不要只反覆改通知文字。

常見問題：權限、時間設定與推送的分界

使用本地提醒一定要先請求通知授權嗎？

如果功能需要系統顯示通知，就要處理使用者授權。請求前先說明用途，並且在拒絕時保留 App 的主要功能。授權狀態不是你可以預設的固定值；使用者日後更改系統設定後，App 也要能讀取狀態並給出適當回應。

提醒文字和觸發時間分別在哪裡設定？

文字可以放在通知內容物件中，例如標題和內文；觸發時機則由觸發條件描述。完成兩者後，再建立通知請求交給系統排程。初次測試可先選容易觀察的條件，確認流程通過後，再換成課程指定的日期或時間需求。

拒絕通知後，待辦功能還可以使用嗎？

可以，而且應該保留核心功能。你可以繼續讓使用者查看任務與到期時間，同時提示系統通知目前不可用。使用者若之後在設定中重新開啟通知，再讀取最新授權狀態並恢復相應的功能提示；不要把拒絕當成程式錯誤。

本地通知和伺服器推送要怎麼選？

如果提醒所需內容和時間已知，而且可以在裝置上安排，先選本地通知；若通知要等待伺服器端的新事件，才考慮伺服器推送。選擇前先對照課程規格，避免為單純的作業截止提醒增加不必要的網路服務端依賴。

如果你目前靠 Windows 編輯程式碼、借用學校電腦完成建置，常見限制是 Xcode 驗收時間不一定方便安排、環境可能與自己的開發流程分開；直接購買 Mac 則要先承擔較高的硬體支出。可先閱讀學生選購 Mac mini 的價格指南，再按課程是否要求 Xcode 建置與實際使用週期決定。若只是短期需要 Mac 完成構建和驗收，可了解 MacDate 的遠端 Mac 學習環境；如果你的工作長期依賴固定本機環境或實體介面，則應優先評估自有設備是否更合適。