Push notifications—also known as remote notifications—let users learn when applications on their iPhone and iPod touch devices have data waiting for them on their servers. They use a persistent IP connection. When a device receives a notification for an application and that application isn’t running, it notifies the user through an alert message, a distinctive sound, or a number badging the application (or some combination of these). The user may then launch the application, which then downloads the data from its server, which is also known as its provider. Introduced in iPhone OS 3.0, push notifications serve the same purpose that a background application would on a desktop computer. (As you may know, background applications are not allowed on these handheld devices.)

What Are Push Notifications?

An application on an iPhone or iPod touch is often only a part of a larger application based on the client-server model. The client side of the application is installed on the device; the server side of the application has the main function of providing data to its many client applications. (Hence it is termed a “provider.”) A client application occasionally connects with its provider and downloads the data that is waiting for it. Email and social-networking applications are examples of this client-server model.

But what if the application is not connected to its provider or even running on the device when the provider has new data for it to download? How does it learn about this waiting data? Push notifications are the solution to this dilemma. A push notification is a short message that a provider has delivered to a device; the device, in turn, informs the user of a client application that there is data to be downloaded. If the user enables this feature and the application is properly registered, the notification is delivered to the device and possibly the application. Apple Push Notification Service, described in “Apple Push Notification Service,” is the primary technology for the remote-notification feature.

Push Notifications from the User’s Perspective

Imagine yourself using an iPhone: making phone calls, surfing the Internet, listening to music. You have a chess application installed on your iPhone, and you decide to start a game with a friend who is playing remotely. You make the first move (which is duly noted by the game’s server application), and then quit the client application to read some email. In the meantime, your friend counters your move. The server for chess applications learns about this move and, seeing that the chess application on your device is no longer connected, sends a push notification to Apple Push Notification Service (APNs).

Your device—or more precisely, the iPhone OS running on the device—receives the notification from APNs. Because your chess application is not currently running, iPhone OS displays an alert similar to Figure 1-1. The message consists of the application name, a short message, and (in this case) two buttons: Close and View.

Figure 1-1 A push notification alert

If you tap the View button, the chess application launches, connects with its provider, downloads the new data, and adjusts the chessboard user interface to show your friend’s move. (Pressing Close simply dismisses the alert.)

Instead of displaying an alert message—or in addition to an alert message—iPhone OS could display a badge number in the upper-right corner of the icon of the target application, such as illustrated in Figure 1-2. The badge number often reflects the number of items that the server has waiting for the application, but could also mean other things. The badge number is specific to an application, and could indicate any number of things, such as the number of data items to download or the number of unread (but already downloaded) email messages.

Figure 1-2 Application icon with a badge number

Along with an alert message or badge number, iPhone OS might also play a short, distinctive sound to alert the user to the incoming notification.

A provider has much control over how users of its client applications are alerted. It decides which combination of alert message, alert sound, and badge number the device should display (although users have some control over this). It can specify a custom alert sound and increment, decrement, or even remove the badge number. If it specifies an alert message, it composes the message text and may even specify one button instead of two. In the latter case, the View button is suppressed, as illustrated in Figure 1-3.

Figure 1-3 Notification alert message with the View button suppressed

A provider may send a push notification to an iPhone application whether the application is running or not. If the application is running when the notification arrives, the application delegate may handle the notification directly. APNs retains the last notification it receives from a provider for an application on a device; so, if a device comes online and has not received the notification, APNs pushes the stored notification to it. A device receives push notifications over both Wi-Fi and cellular connections.

Users of iPhone and iPod touch devices can control whether the device or specific applications installed on the device should receive push notifications. For applications they can also selectively enable or disable notification types (that is, icon badging, alert messages, and sounds). They set these restrictions in the Notifications preference of the Settings application. The UIKit framework provides a programming interface to detect this user preference for a given application.

Push Notifications from the Developer’s Perspective

Push notifications serve much the same purpose as a background application on a desktop system. For an iPhone application that is not currently running, the notification occurs indirectly, as a result of user intervention. The operating system receives a push notification on behalf of the application, and alerts the user through one or more of the methods described in “Push Notifications from the User’s Perspective.” Alerted, users may choose to launch the application, which then downloads the data from its provider has for it. If an iPhone application is running when a notification comes in, it may handle the notification directly if it chooses to.

As its name suggests, Apple Push Notification Service (APNs) uses a “push” design to deliver notifications to devices. A push design differs from its opposite, a pull design, in that the intended recipient of the notification—iPhone OS in this case—passively listens for updates rather than actively polling for them. A push design makes possible a wide and timely dissemination of information with few of the scalability problems inherent with pull designs. APNs uses a persistent IP connection for implementing push notifications.

Most of a push notification consists of a payload: a property list containing APNs-defined properties specifying how the user is to be notified. For performance reasons, the payload is deliberately small. Although you may define custom properties for the payload, you should never use the remote-notification mechanism for data transport because delivery of push notifications is not guaranteed. For more on the payload, see “The Notification Payload.”

Adding the remote-notification feature to your application requires that you obtain the proper certificates from the iPhone Developer Program portal and then write the requisite code for the client and provider sides of the application. “Provisioning and Development” explains the provisioning and setup steps, and “Provider Communication with Apple Push Notification Service” and “iPhone OS Client Implementation” describe the details of implementation.

Apple Push Notification Service continually monitors providers for irregular behavior, looking for sudden spikes of activity, rapid connect-disconnect cycles, and similar activity. Apple seeks to notify providers when it detects this behavior, and if the behavior continues, it may put the provider’s certificate on a revocation list and refuse further connections. Any continued irregular or problematic behavior may result in the termination of a provider’s access to APNs.