Getting Started — Azure, Notification Hub, and iOS

This weekend I decided to explore Azure Mobile Services for iOS. After creating an account I decided I wanted to accomplish three goals: get the sample application running on a device, create a scheduled task, and have the schedule task send push notifications.

Azure has a decent amount of provided documentation and I found it to be sufficent to achieve the first two objectives. However, trying to register an iOS device to use the Azure Notification Hub proved more difficult. The provided documentation gets you close, but is lacking key details about information you need to get as well as having a correct code sample. Below is a link to the existing documentation:

1) Frameworks

The provided sample app that you can download from Azure after creating a mobile service did not contain the necessary “WindowsAzureMessaging.framework” component. This was easy to find with some quick googling. You can download it from this link by clicking on the “iOS Install” link under the “Mobile” heading.

Once you have this downloaded drag the framework into the application.

2) iOS App Code

In section 6 “Connecting your app to the notification hub” of the guide the code sample below is lacking in details:

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *) deviceToken { 
SBNotificationHub* hub = [[SBNotificationHub alloc] initWithConnectionString:
@"<connection string>" notificationHubPath:@"mynh"];

[hub registerNativeWithDeviceToken:deviceToken tags:nil completion:^(NSError* error) {
if (error != nil) {
NSLog(@"Error registering for notifications: %@", error);

Mainly, the surronding body text does not explain what or where to find the connection string or the notification hub path.

The notification hub path turns out to be straight forward. In the Azure dashboard go to the section for “Service Bus” and click on a namespace (probably named something like “appname-ns”). You should now see a list of notification hubs (if you arrive at the quick start page click on the “All” navigation menu option) and the value in the “Name” column is the data you want. The value will probably be something like “appnamehub”.

Now, let’s figure out the connection string. The value you want is actually close by: from the screen where you see the hub name click on the “Connection Information” in the footer of the page.

A dialog window will appear with the heading “Access connection information”. You should see a grouping called “SAS” with items “DefaultListenSharedAccessSignature” and “DefaultFullSharedAccessSignature”.

Hmm, which one of these access signatures to use? After some digging I discovered that you want to use the “DefaultListenSharedAccessSignature” since this only enables the registering device to listen for Service Hub notifications, but not send them.

Place that long string of text into the “connection string” place holder and your ready to go!

3) Schedule Job

Last step, get the scheduled job to send a push notification.

I modified the SampleJob.cs that comes in the pre-built solution that you download from Azure after setting up your Mobile Application.

You’ll need to include:

using Microsoft.ServicesBus.Notifications;

Here is the implementation of the “ExecuteAsync” method:

NotificationHubclient hub = NotificationHubClient.CreateClientFromConnectionString("<connectionstring>","hubname");
var alert = "{\"aps\":{\"alert\":\"sent from sample job!\"}}";

Remember that other connection string called “DefaultFullSharedAccessSignature” from earlier? Yep, that is what you need to use in the “connectionstring” place holder. And, the “hubname” value is the same as used earlier.

Publish the solution, run the schedule job through the dashboard, and the notification will arrive at the device.


I was glad that everything else up to this point was not too difficult. If it is a headache to make even a small sample application work there would be no hope for any real development to occur. Luckily, only this step of connecting all three parts of the process together was lacking in details. I hope this information proves useful to any one else looking to give Azure a try.

Show your support

Clapping shows how much you appreciated Daniel Bradford’s story.