About Local Notifications and Remote Notifications

Local notifications and remote notifications are the two types of user notifications. (Remote notifications are also known as push notifications.) Both types of user notifications enable an app 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 remote user notifications look and sound the same. They can display an alert message or they can badge the app icon. They can also play a sound when the alert or badge number is shown.

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

At a Glance

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

Local and Remote Notifications Solve Similar Problems

Only one app can be active in the foreground at any time. Many apps operate in a time-based or interconnected environment where events of interest to users can occur when the app is not in the foreground. Local and remote notifications allow these apps to notify their users when these events occur.

Local and Remote Notifications Are Different in Origination

Local and remote notifications serve different design needs. A local notification is scheduled and sent by the app itself. Remote notifications—also known as push notifications—arrive from outside a device or a Mac. They originate on a remote server—the app’s provider—and are pushed to apps on devices (via the Apple Push Notification service) when there are messages to see or data to download.

You Register, Schedule, and Handle Both Local and Remote Notifications

To have the system deliver a local notification at a later time, an app registers notification types (in iOS 8 and later), creates a local notification object (using either UILocalNotification or NSUserNotification), assigns it a delivery date and time, specifies presentation details, and schedules it for delivery. To receive remote notifications, an app must register notification types, then pass to its provider a device token it gets from the operating system.

When the operating system delivers a local notification or remote notification and the target app is not running in the foreground, it can present the notification to the user through an alert, icon badge number, or sound. If there is a notification alert and the user taps or clicks an action button (or moves the action slider), the app launches and calls a method to pass in the local-notification object or remote-notification payload. If the app is running in the foreground when the notification is delivered, the app delegate receives a local or remote notification.

In iOS 8 and later, user notifications can include custom actions. Also, location-based notifications can be sent whenever the user arrives at a particular geographic location.

The Apple Push Notification Service Is the Gateway for Remote Notifications

Apple Push Notification service (APNs) propagates remote notifications to devices having apps 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 apps. When new data for an app 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 Remote Notifications

To develop and deploy the provider side of an app for remote notifications, you must get SSL certificates from Member Center. Each certificate is limited to a single app, 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 remote 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-app list of devices for which there were failed-delivery attempts (that is, APNs was unable to deliver a remote notification to an app 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 remote 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 remote notifications, familiarity with app 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 remote 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.