Scheduling Local Notifications on iOS Correctly
By Mykhailo Boichuk · Co-founder & Vice-President
In short
Local notifications look trivial but have real constraints: the system caps how many are pending, calendar-based triggers interact with time zones and daylight saving, and delivery depends on the user’s permission and settings. Scheduling them correctly means using calendar triggers for wall-clock times, staying within the pending limit by scheduling a rolling window, and handling permission and time-zone changes deliberately.
Calendar time versus elapsed time
The first decision is whether a notification should fire after an interval of elapsed time or at a particular wall-clock time. A reminder for nine in the morning is a wall-clock time and must use a calendar-based trigger, so the system resolves it against the user’s current time zone. Using an elapsed-time interval for a wall-clock intention breaks the moment the device changes time zone or daylight saving shifts, because the interval no longer lands on the intended local time.
Getting this distinction right is the difference between a reminder that reliably fires at the intended local moment and one that drifts when the user travels or when clocks change.
Respect the pending limit
The system limits how many local notifications an app can have pending at once. An app that tries to schedule one for every future occurrence of a recurring reminder will hit this ceiling and silently lose the ones beyond it. The reliable pattern is to schedule a rolling window of the nearest upcoming notifications and replenish it as they fire or as the app runs, rather than attempting to schedule the entire future at once.
- Use calendar-based triggers for wall-clock times so the system handles time zones.
- Schedule a rolling window within the pending limit, not every future occurrence.
- Replenish scheduled notifications as they fire or when the app next runs.
Permission and changing conditions
A notification only arrives if the user has granted permission and has not disabled the relevant settings, so the app must request permission appropriately and behave gracefully when it is denied or later revoked. Conditions also change underneath scheduled notifications: the user travels across time zones, changes their reminder preferences, or reinstalls. Each of these requires the app to reconcile its scheduled notifications with the new state rather than assuming what was scheduled still reflects the user’s intent.
Key takeaways
- Distinguish wall-clock times, which need calendar triggers, from elapsed-time intervals.
- Calendar triggers let the system resolve notifications against the user’s time zone.
- The system caps pending notifications, so schedule a rolling window, not the whole future.
- Replenish scheduled notifications as they fire or when the app runs.
- Handle permission denial and time-zone or settings changes by reconciling the schedule.
Frequently asked questions
- Why use a calendar trigger instead of a time interval?
- A wall-clock time like nine in the morning must use a calendar trigger so the system resolves it against the user’s time zone; an interval drifts when the zone or daylight saving changes.
- What happens if I schedule too many local notifications?
- The system caps how many can be pending, so notifications beyond the limit are silently lost. Schedule a rolling window and replenish it instead.
- What conditions can break a scheduled notification?
- Permission being denied or revoked, the user changing time zones or reminder preferences, or a reinstall, each of which requires reconciling the schedule with the new state.
References
About the author
Mykhailo Boichuk
Co-founder & Vice-President
Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.