Local notifications and push notifications are both ways for an application that isn’t running in the foreground to let its users know it has something for them. That something could be a message, an impending calendar event, or new data on a remote server. When presented by the operating system, local and push notifications look and sound the same. They can display an alert message or badge the application icon. They can also play a sound when the alert or badge number is shown.
Note: Push notifications were introduced in iOS 3.0, and local notifications in iOS 4.0. This document previously was titled Apple Push Notification Service Programming Guide.
Once users are aware that the application has a message, event, or other data for them, they can launch the application and access that item. They can also choose to ignore the notification, in which case the application is not activated.
Note: Push notifications and local notifications are not related to broadcast notifications (NSNotificationCenter
) or key-value observing notifications.
Only one application on an iPhone, iPad, or iPod touch can be active in the foreground at any time. Many applications operate in a time-based or interconnected environment where events of interest to users can occur when the application is not in the foreground. Local and push notifications allow these applications to notify their users when these events occur.
Relevant Chapter: “Local and Push Notifications in Depth”
Local and push notifications serve different design needs. A local notification is local to an application on an iPhone, iPad, or iPod touch. Push notifications—also known as remote notifications—arrive from outside a device. They originate on a remote server—the application’s provider—and are pushed to applications on devices (via the Apple Push Notification service) when there are messages to see or data to download.
Relevant Chapter: “Local and Push Notifications in Depth”
To have the operating system deliver a local notification at a later time, an application creates a UILocalNotification
object, assigns it a delivery date and time, specifies presentation details, and schedules it. To receive push notifications, an application must register to receive the notifications and then pass to its provider a device token it gets from the operating system.
When the operating system delivers a local or push notification and the target application is not running in the foreground, it presents the notification (alert, icon badge number, sound). If there is a notification alert and the user taps the action button (or moves the action slider), the application launches and calls the UIApplicationDelegate
method application:didFinishLaunchingWithOptions:
, passing in the local-notification object or remote-notification payload. If the application is running in the foreground when the notification is delivered, the application:didReceiveRemoteNotification:
or application:didReceiveLocalNotification:
method of the application delegate is invoked.
Relevant Chapter: “Scheduling, Registering, and Handling Notifications”
Apple Push Notification service (APNs) propagates push notifications to devices having applications registered to receive those notifications. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. Providers connect with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device.
Related Chapter: “Apple Push Notification Service”
To develop and deploy the provider side of an application for push notifications, you must get SSL certificates from the iPhone Developer Program portal. Each certificate is limited to a single application, identified by its bundle ID; it is also limited to one of two environments, sandbox (for development and testing) and production. These environments have their own assigned IP address and require their own certificates. You must also obtain provisioning profiles for each of these environments.
Related Chapter: “Provisioning and Development”
The binary interface is asynchronous and uses a streaming TCP socket design for sending push notifications as binary content to APNs. There is a separate interface for the sandbox and production environments, each with its own address and port. For each interface, you need to use TLS (or SSL) and the SSL certificate you obtained from the iPhone Developer Program portal to establish a secured communications channel. The provider composes each outgoing notification and sends it over this channel to APNs.
APNs has a feedback service that maintains a per-application list of devices for which there were failed-delivery attempts (that is, APNs was unable to deliver a push notification to an application on a device). Periodically, the provider should connect with the feedback service to see what devices have persistent failures so that it can refrain from sending push notifications to them.
Related Chapters: “Apple Push Notification Service,” “Provider Communication with Apple Push Notification Service”
For local notifications and the client-side implementation of push notifications, familiarity with application development for iOS is assumed. For the provider side of the implementation, knowledge of TLS/SSL and streaming sockets is helpful.
You might find these additional sources of information useful for understanding and implementing push notifications:
The reference documentation for UILocalNotification
, UIApplication
, and UIApplicationDelegate
describe the local- and push-notification API for client applications.
Security Overview describes the security technologies and techniques used for the iOS and Mac OS X platforms.
RFC 5246 is the standard for the TLS protocol.
Secure communication between data providers and Apple Push Notification Service requires knowledge of Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). Refer to one of the many online or printed descriptions of these cryptographic protocols for further information.
Last updated: 2010-08-03