Mobile Development 17 min read

Understanding iOS Push Notifications: Remote and Local Push, History, and Implementation Details

This article provides a comprehensive overview of iOS push notification mechanisms, covering remote and local push differences, device token acquisition across iOS versions, silent push constraints, scheduling nuances, and the evolution of notification APIs from iOS 7 to iOS 13, with practical code examples.

NetEase Game Operations Platform
NetEase Game Operations Platform
NetEase Game Operations Platform
Understanding iOS Push Notifications: Remote and Local Push, History, and Implementation Details

Introduction

The article explains why a new iOS push notification guide is needed despite abundant online resources, focusing on the complexity caused by OS versions, user authorization, app lifecycle states, and push types.

1. Remote Push

1.1 When can deviceToken be obtained

The remote notification flow includes client requesting a device token, reporting it to the server, server sending payload to APNS, APNS delivering to the device, and the device displaying the notification based on user permission.

Client requests device token from Apple.

Token is reported to the server.

Server sends notification payload with token to APNS.

APNS delivers the notification to the device.

Device decides whether to show the notification based on user settings.

Authorization dialogs only affect the final display step.

Device token retrieval differs by iOS version:

iOS 8+ : No user authorization required for token; once reported, notifications can be delivered.

iOS 7 and earlier : Token is obtained via [UIApplication registerForRemoteNotificationTypes:] .

1.2 Special cases before iOS 8

First install with authorization: token may not be returned immediately; it appears on the next app launch.

First install without authorization: token is unavailable until the user enables notifications in Settings and relaunches the app.

1.3 Silent (background) push

Silent pushes (Background Update Notification) were introduced in iOS 7 and allow the app to process data in the background without user-visible alerts.

Usage limits

Apple treats background updates as low priority and may throttle them; it is recommended to send only a few per hour.

Payload control

To create a silent push, include content-available:1 in the aps dictionary and avoid alert , sound , or badge keys, otherwise it becomes a regular push.

1.4 Summary of push states

The article summarizes how app state, user authorization, and push type (regular vs. silent) combine to produce different observable behaviors for both users and developers.

2. Local Push

Local notifications are managed by the system, allowing delivery even when the app is terminated. iOS 10 introduced a new API; earlier versions use different mechanisms.

2.1 Repeating notifications

iOS 10+ uses [UNTimeIntervalNotificationTrigger triggerWithTimeInterval:timeInterval repeats:YES] with a minimum interval of 60 seconds. iOS 9 and earlier can only repeat by minute using NSCalendarUnitMinute .

2.2 Monthly weekday repeats

iOS 10+ can schedule a notification for, e.g., the second Friday of each month using [UNCalendarNotificationTrigger triggerWithDateMatchingComponents:dateComponents repeats:YES] . This is not possible with UILocalNotification on iOS 9-.

2.3 Expiration

Local notifications expire roughly after 15 minutes; if the device is off during that window, the notification will not appear.

3. Evolution of iOS Push Notifications

From iOS 7 to iOS 13, Apple introduced silent pushes, revamped permission handling, HTTP/2 APNS, the UserNotifications framework, notification content extensions, privacy controls, grouping, dynamic actions, critical alerts, new APNS headers, and changes to device token formats.

iOS 7

Added support for silent pushes.

application(_:didReceiveRemoteNotification:fetchCompletionHandler:)

iOS 8

Redesigned notification permission request.

Introduced registerUserNotificationSettings(_:) .

Added UIUserNotificationSettings, UIUserNotificationCategory, UIUserNotificationAction.

iOS 9

Added text input actions.

Switched APNS to HTTP/2 with a new Provider API.

iOS 10

Introduced the UserNotifications framework.

Supported foreground display, title/subtitle in payloads.

Provided Notification Service and Content extensions.

// iOS 10 payload with title and subtitle
{
  "aps":{
    "alert":{
      "title":"I am title",
      "subtitle":"I am subtitle",
      "body":"I am body"
    },
    "sound":"default",
    "badge":1
  }
}

iOS 11

Added notification content hiding options (always, when unlocked, never).

iOS 12

Introduced automatic and custom notification grouping.

iOS 13

Changed deviceToken format; example conversion code provided.

Added apns-push-type header with values like alert, background, voip, etc.

For background pushes, apns-priority must be set to 5.

Apple discontinued TLS v1 support for push APIs.

const char *tokenBytes = (const char *)[deviceToken bytes];
NSMutableString *token = [NSMutableString string];
for (NSUInteger index = 0; index < deviceToken.length; index++) {
    [token appendFormat:@"%02hhx", tokenBytes[index]];
}

Conclusion

The article acknowledges the complexity of iOS notifications and encourages readers to consult official documentation for topics not covered.

iOSPush NotificationSwiftObjective-CAPNSLocal PushRemote Push
NetEase Game Operations Platform
Written by

NetEase Game Operations Platform

The NetEase Game Automated Operations Platform delivers stable services for thousands of NetEase titles, focusing on efficient ops workflows, intelligent monitoring, and virtualization.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.