“Push Notifications? Ohh, no!”. Yes, that’s the first thing that was coming to my mind when I was called to implement push notifications in an iOS app, and I’m pretty confident that it has been coming to yours as well. And not because it’s difficult to use push notifications, it’s just all that series of steps required prior to even be able to test a single push notification and cause eventually a huge confusion to almost all developers. But, let’s hold on a minute, and let’s take things from the beginning.
It’s quite often necessary to pull the user’s attention when an app is not running, and that’s possible to happen by using what we know as notifications. As an iOS developer, you know that iOS supports two types of notifications: Local and Push (or Remote). In the former case, notifications are registered and scheduled by the app itself, and they’re really easy to be implemented. Actually, you can find a couple of older tutorials about local notifications in this and this link.
Push notifications on the other hand are not scheduled by the app. They are triggered by another service (called provider), most often a web server, and they’re usually targeting to multiple devices simultaneously. With push notifications, app creators can send messages to users when necessary, either in random times or scheduled, and either with a customized (personalised) or a default message body. Here is a good resource for some general information about Apple Push Notifications.
Every single push notification that is sent from a provider to one or more target devices, follows a mandatory path. That is through the Apple Push Notification Servers, or simply APN servers. Those servers actually route push notifications to the proper devices, and messages are normally delivered within a few seconds by the time they’re sent by the provider. In simple words, the lifecycle of a remote notification can be summed up as shown next:
Provider >> APN servers >> Target Devices
I encourage you to pay a visit to the official documentation for useful details about the way push notifications work.
Several steps are required so as an app can accept push notifications. Those steps are divided in two general categories: The programming preparation, and the production of various certificates, provisioning profiles and more. The programming part is easy, as it consists of standard pieces of code that must be added to the project. The confusing is the second part, where a number of other actions are necessary to be taken in various places, such as the Mac OS Keychain Access app, the project, and the Apple Developer Member Center portal.
Besides all that, there are two kinds of remote notifications: Sandboxed that can be used in the development stage so it’s possible to test notifications, and Live that are meant to be used only in production stage. If you manage to successfully receive sandboxed notifications in your app and at the same time you have taken all the actions that were shortly mentioned above properly, then you can be sure that live push notifications will work too. Needless to say that Apple provides test servers for sending sandboxed notifications, and it’s not the production APNs for that purpose.
Our goal in this tutorial is quite simple: We are going to enable push notifications for a demo app, and we’ll make sure they work by sending a couple of them in sandbox mode. Hopefully, this tutorial will be your guide the next time that you’ll need to add push notifications to your app, but most importantly, it will take you out of any hassle and confusion resulting from the push notifications prerequisites.
Continue reading my tutorial on Appcoda