2. Push Notifications

Written by Scott Grosch

Push notifications are a useful feature that allow you to interact with your users outside of the normal flow of your app. A notification can be scheduled locally based on conditions such as time or location, or scheduled from a remote service and “pushed” to your device. Regardless of whether you are utilizing a local or remote notification, the general process for handling one is the same:

• Ask your user for permission to receive notifications.
• Optionally make changes to the message before display.
• Optionally add custom buttons for the user to interact with.
• Optionally configure a custom user interface to display the notification.
• Optionally take action based on what the user did with the notification.

What are they good for?

You’d be hard pressed in this day and age to not have seen a push notification at some point. They are capable of many actions:

• Displaying a message.

• Playing a sound.

• Updating the badge icon on your app.

• Showing an image or playing a movie.

• Giving the user a way to pick from a few options.

• Anything that a UIViewController can implement.

While you can technically show any type of user interface as long as it fits within the bounds of a notification window, that doesn’t mean you should do so. Always keep user experience in the forefront of your mind when designing a notification. Will your users want to see it, hear it or interact with it?

Remote notifications

By far, the most common type of notification used is a remote notification, in which a Cloud service, usually a web server, is utilized to determine that a notification should be built and sent to the device.

A remote notification can be a great fit for multiplayer games that are turn-based. Once an opponent has made his or her move, the user is sent a notification stating that it’s now their turn. If the user has any type of data feed, such as a news app, then a silent remote notification can be used to proactively send data to the user’s device so that the content is already there when they run the app the next time, versus having to wait for a network download.

Clearly, you don’t want just anyone to be able to send messages to your users! Apple has built its Apple Push Notification service (APNs) using Transport Layer Security (TLS). TLS provides privacy and data integrity, which ensures that you, and only you, control your app’s notifications.

Security

APNs utilizes cryptographic validation and authentication to ensure security of your messages.

Your server, called a provider, utilizes TLS to send notification requests to Apple, and the device uses an opaque Data instance — referred to as a device token — which contains a unique identifier that the APNs is able to decode. The iOS device receives a (possibly new) token when it authenticates with the APNs; the token is then sent to your provider so that a notification can be received in the future.

You should never cache a device token on the user’s device as there are multiple instances in which APNs will need to generate a new token, such as installing the app on a new device or performing a restore from a backup.

The device token is now the address that a provider uses to reference a user’s specific device. When the provider service wishes to send a notification, it will tell APNs the specific device token(s) that need to be sent a message. The device then receives the message and can take appropriate action based on the content of the notification. You can either build your own provider service, as discussed in Chapter 6, “Server Side Pushes,” or you can use one of the many third-party providers that already exist.

Notification message flow

It is important to understand the steps between registering your app with the Apple Push Notification Service and the user actually receiving a notification.

1. During application(_:didFinishLaunchingWithOptions:), a request is sent to APNs for a device token via registerForRemoteNotifications.
2. APNs will return a device token to your app and call application(_:didRegisterForRemoteNotificationsWithDeviceToken:) or emit an error message to application(_:didFailToRegisterForRemoteNotificationsWithError:).
3. The device sends the token to a provider in either binary or hexadecimal format. The provider will keep track of the token.
4. The provider sends a notification request, including one or more tokens, to APNs.
5. APNs sends a notification to each device for which a valid token was provided.

You can see these steps reflected in the image below:

There are multiple ways a notification can materialize on a device once the notification has actually been pushed, depending on the state of the app and what features have been configured. Those will be discussed in greater detail in the chapters of this book.

Local notifications

A local notification is created and scheduled on the device, as opposed to being sent to the device from a remote provider. A local notification allows all the same features as a remote notification. The only difference is that a local notification is triggered based on a set amount of time passing, or entering/exiting a geographical area, as opposed to being pushed to the device.

You might want to use a local notification similar to a timer. If your app teaches people how to cook in a step-by-step process, you may have a notification appear when the food has been marinating long enough and is now ready to go into the oven, with a new notification when it’s time to take the food out of the oven.

Location aware

While it’s easy to think of notifications as being in a type of sandbox of their own, there’s no reason to exclude other iOS-provided features to enhance your app, such as location services. You can employ location services by tying a remote notification to a user’s location. You may decide to send coupons to your customers, but only in a specific geographical area. Perhaps a guest author is reading at the local bookstore and you want to let your app’s users know about it, but only if they live close enough to make it worthwhile.

Key points

• Push notifications allow you to interact with your users outside of the normal flow of your app.

• A notification can be scheduled locally based on conditions or from a remote service and “pushed” to your device.

• Remote notifications are the most common type, and they use a Cloud service to determine that a notification should be built and sent to the device.

• Notification messages remain secure because APNs utilizes cryptographic validation and authentication.

• A local notification is created and scheduled on the device, as opposed to being sent to the device from a remote provider.

Where to go from here?

This chapter has been the first step in your journey to understanding the many facets, opportunities and challenges of leveraging push notifications.

Now that you know the basic terminology, it’s time for you to actually learn how a notification request, known as a payload, is constructed.