There’s no need to add any content or other controls at all. Also, quite often I give you a starter project to begin with, but not this time.Īll you have to do for the demo app of this tutorial, is to create a new iOS project in Xcode, and just stop there. The first thing I always do right before I get into the point of each tutorial is to provide some information regarding the demo app that we are about to implement. 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.
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. Needless to say that Apple provides test servers for sending sandboxed notifications, and it’s not the production APNs for that purpose. 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.
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.īesides 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.
The programming part is easy, as it consists of standard pieces of code that must be added to the project. Those steps are divided in two general categories: The programming preparation, and the production of various certificates, provisioning profiles and more. Several steps are required so as an app can accept push notifications. I encourage you to pay a visit to the official documentation for useful details about the way push notifications work. In simple words, the lifecycle of a remote notification can be summed up as shown next: 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. That is through the Apple Push Notification Servers, or simply APN servers. Here is a good resource for some general information about Apple Push Notifications.Įvery single push notification that is sent from a provider to one or more target devices, follows a mandatory path. 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. They are triggered by another service (called provider), most often a web server, and they’re usually targeting to multiple devices simultaneously.
Push notifications on the other hand are not scheduled by the app. Actually, you can find a couple of older tutorials about local notifications in this and this link. In the former case, notifications are registered and scheduled by the app itself, and they’re really easy to be implemented. As an iOS developer, you know that iOS supports two types of notifications: Local and Push (or Remote). 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. But, let’s hold on a minute, and let’s take things from the beginning.
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.
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.