31 Days of iOS: Day 26-Push Notifications Part 1: The Setup

Welcome to Day 26 of the 31 Days of iOS.  Yesterday, we wrapped up a two part mini-series on life cycle events on the application object and view controllers.  Today we’re going to start discussing the very important topic of Push Notifications.  Push notifications enable your apps to get information from an outside source.  Instead of your app only being able to pull information down when running, we’re going to see how it’s possible to send data to our apps whenever we want.  One VERY IMPORTANT thing I’d like to point out is that you NEED to be a registered iOS developer in order to follow along today.  There are steps you can’t take (like moving the app to a device) unless you are.  Also, you can’t test push notifications on the simulator, you’ll need to have an iOS device in order to test this out.  We won’t be doing any coding today as there is a lengthy set up process we need to go through first involving the Apple developer portal.  Tomorrow we’ll implement all of the code and actually test out our push notifications.

A bit about client server stuff

In order to test and demonstrate push notifications, we have to have some way to send those push notifications.  Unfortunately, there isn’t a way to do that from the Apple dev portal.  What we really need is a computer that can send information to Apple’s Push Notification Service (APNS) in order to have it deliver the push notification.  I could always run something locally or deploy something somewhere but in order to make things as easy on me as possible and not focus on the server side today, I’m going to use something I am familiar with, Windows Azure Mobile Services.  This will allow me to easily test out sending a push notification without us getting into specifics of how it’s done.  Once you’re done reading this, if you’re interested I have a bunch of other articles on what you can accomplish with Mobile Services besides just testing push which we’ll do today.

The Apple dev portal

Unfortunately, a lot of what we have to do today isn’t strictly code related.  Due to how Apple restricts developers from putting applications on to devices and how push notifications and signing applications work, we have to do a fair amount of work in the portal.  So, start by launching Safari (or whatever browser you prefer) and go to http://developer.apple.com.  After logging in, select the iOS Provisioning Portal from the Developer Program Resources.  Once here, click on the Devices link on the left.  Ensure that your device is showing up here:

After that, click on Certificates, and make sure your certificate is showing up:

These steps aren’t strictly part of getting push notifications to work but if they aren’t in place, things won’t work later on.  Now tap on App IDs.  The dev portal has the concept of Wildcard app IDs which allow you to use the same certificate and profile for multiple apps while developing (along with some other reasons).  However, if you want to us APNS, as well as several other Apple resources, your app needs to have a unique ID that can’t be shared with other apps.  This ID is going to be unique to your app from all the other apps in the store and on a device.  Go ahead and click the New App ID button in the top right.  In the page that comes up, you’ll need to enter a Description and a Bundle Identifier.  The Description can be whatever you want and is used in the provisioning portal to identify your app.  The Bundle Identifier is what is really important.  This is that unique ID that identifies your app.  The example given in the portal is com.domainname.appname and this is the format many organizations use for their apps and what we’ll use today.  It’s extremely important that the appname part of your identifier matches your app name as this part is hard-coded to your project in Xcode and can’t be changed.  There is also an read-only Bundle Seed ID.  This gets prepended automatically to your identifier and is a unique identifier for your iOS Developer account (or your team’s account if you’re part of one).  I’m going to make my identifier com.cmr.DayTwentySix:

One other thing you should know is that (as of now) there isn’t a way to get rid of an App ID once it’s in your portal.  So make sure things are right before you hit Submit.  With that done we can scroll down the list (if you already have app’s) and find the one we just created:

As you can see, Push Notification are marked as Configurable.  Depending on where your app is in your list, you may not be able to see the column headers but all of the indicators on the left side are for the Development version of your app and the right are for Production.  Click on the Configure link now. 

Configuring App ID

Here we can do many things including configuring for APNS, iCloud, Passes, and Data Protection.  Today we’re interested in APNS:

We first need to check the box at the top left.  Then the Configure buttons will become enabled.  Click the one to the right of Development.  The next screen will walk you through Generating a Certificate Signing Request.  This is a file you can generate using the Keychain Access application in OSX.  Follow those steps to generate your CSR file and then click Continue.  In the next window, click Choose File and browse to and find your CSR file and then click Generate.  After a moment you should see a successful message:

Click Continue and you’ll be able to Download the cert.  Do so now.  After downloading, find the cer file you just downloaded and double click it.  This should open up the Keychain Access app.  Under My Certificates, you should see one matching your app name.  Mine for example is Apple Development IOS Push Services: com.cmr.DayTwentySix.  Right click on your cert and choose the Export option:

This will allow you to export a Personal Information Exchange or p12 file.  However you are testing your push notifications, you’ll need this file to sign your requests to send a push notification.  The APNS servers then inspect those requests to make sure they were signed with the same p12 file.  When you do the export, you’ll have the option to enter a password.  It’s recommended that you do, just don’t forget what that password is.  Now return to the portal and you should see the light has changed from yellow to green and says Enabled for the development push settings. 

Provisioning Profile

Return to the top of the portal and click Provisioning on the left. The last step we need to take is to produce a provisioning profile specific to our app.  When you create an iOS dev account, you automatically get an iOS Team Provisioning Profile that is tied to your wildcard app ID.  That is to say, you can sign any application from your account with it to put it on a device (as long as that device is also connected to your development account).  However, in order to make use of the app specific stuff we just set up (APNS) we need a profile JUST for this app.  Click the New Profile button in the top right.  We’re asked for a profile name, which cert to use, which App ID to use, and which devices to allow it on.  Make sure you’ve selected the right App ID if you have multiple:

After filling in the details, click Submit.  You’ll be taken back to the list of profiles where the new one should show up as Pending.  Refresh your browser after a moment and it should show up as Active.  Click the Download button to the right of it to download it locally and then double click the file.  This should give you the ability to import it into your list of local profiles.  You can check this by opening Xcode and going to the Window menu and choosing Organizer.  In Provisioning Profiles under Library, you should see your profile:

If that all went well then you’re ready to test out push notifications.  We’ll be addressing the coding portion of that tomorrow.

Conclusion

Today we started reviewing how push notifications work with APNS.  We covered the first half of what is necessary with push notifications which was all done in the Apple developer portal.  Due to how each device is tied to a developer account and every app that goes on those devices needs to be signed and every request to APNS has to be signed in a way that matches up with what’s in the portal, the set up process was pretty complicated.  Thankfully this means that all we need to do tomorrow is the code.