iPhone Push Notification Services Guidelines

ballooncadgeInternet and Web Development

Oct 31, 2013 (3 years and 5 days ago)


iPhone Push Notification Services Guidelines

In I
OS, apps can’t do a lot in the background. Apps are only allowed to do limited set of activities so
battery life is conserved.

But what if something interesting happens and you wish to let the user know
about this, even if they’re not
currently using your app?

For example, maybe the user received a new
, their favorite team won the game, or their dinner is
ready. Since the app isn’t currently running, it cannot check for these events.

Luckily, Apple
has provided a solution to this. Instead of your app continuously checking for events or
doing work in the background, you can write a server
side component to do this instead.

And when an event of interest occurs, the server
side component can send the ap
p a push notification!
There are three things a push notification can do:

Display a short text message

Play a brief sound

Set a number in a badge on the app’s icon

You can combine these however you see fit; for example, play a sound and set the badge but n
ot display
a message.

Push notification architecture:

Getting push to work for your app takes quite a bit of effort. This is a puzzle with many pieces. Here is an

List of components involved during push notification service for any iPhone app

1. iPhone app

2. IOS

3. APNS server

4. Web server

(Push notification server)

Each and every iPhone app is associated and distinguished with its App Id, Bundle identifier and
Provisioning profile.

Below are the procedures to track all the required fields
before start of developing any iPhone app.

Generating an ID for your app

Login to your Apple Developer account.

Team Agents or Team Admins should navigate to the ‘App ID’ section of the Provisioning Portal.

Click ‘Add ID’.

Enter a common name for your
App ID. This is a name for easy reference and identification within
the Provisioning Portal.

Enter a Bundle Identifier in the free
form text field. The recommended usage is a reverse
name style string, e.g., com.domainname.applicationname. For a sui
te of applications sharing the
same Keychain access, you should use a wild
card character in the Bundle Identifier (e.g.
com.domainname.* or *). This Bundle Identifier will need to match whatever CF Bundle Identifier
you use for your application in Xcode.

Click ‘Submit’. At this time, the 10 character Bundle Seed ID is generated and concatenated with
the Bundle Identifier you entered. This resulting string is your App ID.


The Bundle Seed ID does not need to be entered into Xcode.

Generate a new App

ID for each set of applications with shared Keychain Access needs. If you
are creating a suite of applications that will share the same Keychain access (e.g. sharing
passwords between applications) or have a set of applications with no Keychain Access
uirements, create a single App ID for all applications utilizing a trailing asterisk as a wild

Registering an App ID for Apple Push Notification service

To enable push notifications in your app, it needs to be signed with a provisioning pr
ofile that is
configured for push. In addition, your server needs to sign its communications to APNS with an SSL

The provisioning profile and SSL certificate are closely tied together and are only valid for a single App
ID. This is a protectio
n that ensures only your server can send push notifications to instances of your app,
and no one else.

As you know, apps use different provisioning profiles for development and distribution. There are also two
types of push server certificates:



your app is running in Debug mode and is signed with the Development
provisioning profile (Code Signing Identity is “iPhone Developer”), then your server must be using
the Development certificate.

Apps that are distributed as Ad Hoc or on

the App Store (when Code Signing Identify
is “iPhone Distribution”) must talk to a server that uses the Production certificate. If there is a
mismatch between these, push notifications cannot be delivered to your app.

To send Push notification to an appli
cation/device couple you need

unique device token and a

Device token will be associated and unique for each iPhone device.

Creating the SSL Certificate and Keys:

generate the SSL certificate that your push server uses to make a secure
connection to APNS. This
certificate is linked with your App ID. Your server can only send push notifications to that particular app,
not to any other apps.

After you have made the App ID, it shows up like this in the list:

In the “Apple Push Notificati
on service” column, there are two orange lights that say “Configurable for
Development” and “Configurable for Production”. This means our App ID can be used with push, but we
still need to set this up. Click on the


link to open the Configure App
ID screen.

Check the

Enable for Apple Push Notification service

box and click on the


button for the
Development Push SSL Certificate. The “Apple Push Notification service SSL Certificate Assistant” pops

Choose the CSR file that you generated earlier and


It takes a few seconds to generate the SSL certificate. Click


when it’s finished.

Now click


to get the certificate

it is named “aps_developer_i dentity.cer”. Click


to close
the assistant and return to the

App ID screen.


can see, we have a valid certificate and push is now available for development. You can
download the certificate again here if necessary. The development certificate is only valid for 3 months.

When you are ready to release your app, repeat this process f
or the production certificate. The steps are
the same.


The production certificate remains valid for a year, but you want to renew it before the year is over
to ensure there is no downtime for your app.

You don’t have to add the certificate to your
Keychain, although you could if you wanted to by double
clicking the downloaded aps_developer_i dentity.cer file. If you do, you’ll see that it is now associated with
the private key.

If you write your push server in PHP language you have to combine the ce
(aps_developer_i dentity.cer) and private key (.p12 file)

in PEM format, else make directly use of it.

Installing the SSL Certificate and Key on the Server

You should install the SSL distribution certificate and private cryptographic key you
obtained earlier on
the server computer on which the provider code runs and from which it connects with the sandbox or
production versions of APNs. To do so, complete the following steps:


Open Keychain Access utility and click the My Certificates category
in the left pane.


Find the certificate you want to install and disclose its contents.

You'll see both a certificate and a private key.


Select both the certificate and key, choose File > Export Items, and export them as a Personal
Information Exchange (.p12
) file.


To convert the certificate to

format, complete the following steps:


In KeyChain Access, select the certificate and choose File > Export Items. Select the
Personal Information Exchange (.p12) option, select a save location, and click Save.


h the Terminal application and enter the following command after the prompt:

openssl pkcs12




Copy the


certificate to the new computer and install it in the appropriate place.

Now your server is
ready to send the push notifications to your registered app with server.

Apple Push Notification provider server

As a provider, your server needs to communicate with the Apple Push Notification Service (APNS) to
send the messages that are then pushed to

hone. This is necessary so that the device only needs
to maintain 1 connection to the APNS, helping to reduce battery usage.

Basic Structure


You connect to the APNS using your unique SSL certificate


Cycle through the messages you want to send (or
just send 1 if you only have 1)


Construct the payload for each message


Disconnect from APNS


The payload is limited to 256 bytes in total

this includes both the actual body message and all of the
optional and additional attributes you
might wish to send
. Push notifications are not designed for
large data transfer, only for small alerts. For example we only send a short alert message
detailing the server monitoring alert triggered.

APNS does not provide any status feedback as to whether
your message was successfully delivered.
One reason for this is that messages are queued to be sent to the device if it is unreachable, however
only the last sent message will be queued

overwriting any previously sent but undelivered messages.

Push notif
ications should not be used for critical alerts because the message will only be delivered if the
device has wifi or cellular connectivity, which is why we recommend combining push with another
alerting method such as e
mail or SMS for our server monitorin
g alerts.

The SSL certificates used to communicate with APNS, discussed
, are generated on an
application level. The implementation discussed

only concerns a single iPhone application so if
you have several, you will need to adapt the code to us
e the appropriate certificate(s) where necessary.

Device Token

Each push message must be “addressed” to a specific device. This is achieved by using a unique device

oken generated by APNS within your iPhone application. Once this token has been
retrieved, you need
to store it on your server, not within your iPhone application itself. It looks something like this:

c9d4c07c fbbc26d6 ef87a44d 53e16983 1096a5d5 fd825475 56659ddd f715defc

For the Server Density iPhone application, we call the
necessary generation methods on app launch and
pass it back to our servers via an

This store

the device

oken in a database on our servers
for that u
ser so we can then communicate with the device linked to that user.

Feedback Service

Apple provides a

feedback service

which you are supposed to occasionally poll. This will provide a list of
device tokens that were previously but are no longer valid, such as if the user has uninstalled your iP

You can then remove the device t
oken from your database so you do not communicate with
an invalid device.

Payload Contents



is formatted in JSON, compliant with the
RFC 4627 standard. It consists of several parts:


the text string to display on the device


the integer number to display as a badge by the application icon on the device home


the text string of the name of the sound to accompa
ny the display of the message on the