• 4 min read

Enhancing Mobile Services support for iOS apps: Push Notifications support

After we delivered iOS client libraries for Mobile Services in October, many of you asked when support for iOS push notifications would follow.  Today is the day—I’m happy to share…

After we delivered iOS client libraries for Mobile Services in October, many of you asked when support for iOS push notifications would follow.  Today is the day—I’m happy to share that Mobile Services now supports sending iOS push notifications! 

With this update, Mobile Services now fully supports Windows Store, Windows Phone 8, and iOS apps.  Android support will follow shortly.

The Basics: iOS Push Notifications

Sending push notifications to an iOS device is as simple as:

push.apns.send(““, { alert: “Hello Apple World!”}); 

Handling feedback from Apple Push Notification Services is similarly easy:

push.apns.getFeedback({ success: function(results) { /* process feedback */ } });

If you’re ready to add push notifications to your app today, head to the dev center and follow the Get Started with Push Notifications in Mobile Services tutorial.  That tutorial will walk you through the basics of configuring your iOS app for push and sending push notifications. 

Once you’ve got the basics, follow this tutorial for how to use a table to store Apple Push Notification Service tokens that can then be used to send push notifications to an app’s users.

Scott Guthrie’s post has more information on this announcement.

SMS, Email, and Push—Oh My!

More important than catching the reference (bonus points for realizing why it’s current again), is understanding when and how to use the wide variety of tools we’re providing.  We’ve not only brought the ability to send push notifications at your fingertips, but also partnered with Twilio and SendGrid to make SMS and Email just as easy. 

When and how to use SMS versus Email versus a badge notification versus a toast notification, however?  The easy answer is that it depends on the app.  I’m going to share, however, some general guidelines we’ve adopted as best practices.  I’d love to hear some of your own best practices in the comments, as well as discuss when it makes sense to depart from these or your own general guidelines. 

Push Notifications: the Canonical Default. 

Push notifications were created specifically with smartphones and apps in mind.  They are the most powerful and effective channel for engaging your customers.

Be careful, though, because with great power comes great responsibility.  Most users will give you some leeway at the outset and allow push notifications.  They will withdraw that consent just as quickly, however. 

The most common danger zones? Social apps that send alert notifications every time a user’s Facebook friend signs up, without limiting to only those that the user actually invited or has engaged with on the app.  News apps that add to the badge count every time there’s a new story published in a category, even if you are not following the specific topic.  Obviously, selling any type of push notification is the quickest way to have your user disable push notifications.

Toast notification best practices:

  • Keep it brief and simple. You’re working with a very small space.
  • Use this with a clear call to a very specific action or non-action.  Even with something as simple as a to-do app, “You have a new task ‘Buy a gallon of milk’” sounds infinitely better than “A new item ‘Buy a gallon of milk’ has been added”

Badge count best practices:

  • The action required to engage with and reset the badge count should take three or fewer (taps, swipes, etc.). 
  • Limit the number of things a badge notification can mean.  Take a turn based game with a chat component.  If the badge count increases with both game updates and a new message arriving to the in-game chat, your customer doesn’t have a clear understanding of the ask.
  • The badge count should never hit double digits.  Once it does, the customer is definitely ignoring the app and likely to disable push notifications right away, if not uninstall outright.

SMS: Must Read Messages

There is an almost infinite way to use SMS with your app.  Our friends at Twilio have an army of Doers that have proved just how versatile a simple SMS can be.  To narrow that focus, however, to SMS as only a means of communicating with your customers, SMS is for when there is a must-read item.  Since it can’t be turned off, the risk of uninstall is much higher too.  Be sure that it’s worth it.

When to use Email: the Basics and the Important Stuff

Just like with SMS, there are tons of fantastic and non-standard use cases for Email in the modern app.  Developers are using SendGrid to do that everyday. Limiting the discussion again to just a means of customer communication, however, one scenario shines through. 

Use email for the content you want your users to be able to go back and find days, weeks, or months later.  Does that include confirmation on successful authentication? Absolutely.  Does that include a shot of the final board in their high score Scrabble type game? Absolutely.  Does that include requests to invite friends to the app in order to enhance their experience? Maybe not.

Let us know what you think, how you’re using Mobile Services, and what you want to see next.

If you have feedback (or just want to show off your app), shoot an email to the Windows Azure Mobile Services team at mobileservices@microsoft.com

As always, if you have questions, please ask them in our forum.  If there’s a feature you’d like to see, please visit our Mobile Services uservoice page and tell us.

You can also find me on Twitter @kirillg_msft 

Also, my colleague Josh just posted a short video demonstrating these new features which I’d recommend checking out: