About Local Notifications and Push Notifications

Local notifications and push notifications are ways for an application that isn’t running in the foreground to let its users know it has information for them. The information 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 they can badge the application icon. They can also play a sound when the alert or badge number is shown.

When users are notified that the application has a message, event, or other data for them, they can launch the application and see the details. They can also choose to ignore the notification, in which case the application is not activated.

At a Glance

Local notifications and push notifications have several important aspects you should be aware of.

The Problem That Local and Push Notifications Solve

Only one application 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.

Local and Push Notifications Are Different in Origination

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.

You Schedule a Local Notification, Register a Push Notification, and Handle Both

To have iOS 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 notification (iOS only) or push notification (iOS or OS X) 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 or clicks the action button (or moves the action slider), the application launches and calls a method to pass in the local-notification object or remote-notification payload. If the application is running in the foreground when the notification is delivered, the application delegate receives a local or push notification.

The Apple Push Notification Service Is the Gateway for Push 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.

You Must Obtain Security Credentials for Push Notifications

To develop and deploy the provider side of an application for push notifications, you must get SSL certificates from the appropriate Dev Center. Each certificate is limited to a single application, identified by its bundle ID; it is also limited to one of two environments, one for development and one for 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.

The Provider Communicates with APNs over a Binary Interface

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 development 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 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.


iOS App Programming Guide describes the high level patterns for writing iOS apps.

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.

See Also

The following documents provide background information:

You might find these additional sources of information useful for understanding and implementing local and push notifications:

For information on how to send push notifications to your website visitors using OS X, read “Configuring Safari Push Notifications” in Notification Programming Guide for Websites.