After we delivered iOS client libraries for Mobile Services in October, many of you asked when support for iOS push notifications would follow. As Scott Guthrie announced Wednesday, Mobile Services now supports sending iOS push notifications! We’ve also improved our iOS Client API by adding an even easier login method; configuring user authentication now only takes a single line of Objective-C code.
Since we now support three means of communicating with your customers—push notifications, SMS via Twilio, and email via SendGrid—across three platforms, this post will first cover the basics of iOS push and then turn to general guidelines on when and why to use each.
The Basics of Configuring iOS Push Notifications
Scott’s blog has all the details you need to get started with push, but to summarize the two big takeaways:
- Mobile Services makes it incredibly easy to send a push notification.
- Mobile Services gives you the tools you need to handle feedback for expired devices and channels right in the portal. Periodically pruning your database of invalid tokens allows you to save money by not sending notifications to uninstalled apps.
Josh Twist, another member of the Mobile Services team, demos these new additions in the following video:
There are also two fantastic tutorials available in the mobile dev center. The first provides a walkthrough of the basics of configuring your iOS app for push and sending push notifications. The second details how to use a table to store APNS tokens that can then be used to send push notifications to an app’s users.
You can also review our reference docs for complete details on how to use the APNS object to send your push notifications.
When to use Push vs Email vs SMS
Just as important as understanding how to use these push notifications, is understanding when to use a push notification versus an SMS versus an email. 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 as well as share some examples that illustrate exceptions to the rule. 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?
- Apps with a social component that send alert notifications every time a user’s Facebook friend signs up, without limiting notifications to only those friends that the user actually invited or with whom they engage regularly.
- 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.
- Selling any type of notification to a third party is obviously a fast way have your user disable push notifications.
Toast notification best practices:
- Keep it brief and simple. Know that you’re working with a very small space and try to avoid ellipses. Make sure the content of a toast notification is valuable in and of itself.
The exception here is when the content of the notification before the ellipses is compelling enough for your user to open and interact in the app. If the content of the toast is a truly irresistible teaser, then by all means use the ellipses. Facebook posts are a great example of this exception.
- 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 gestures (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.
The Mail app is definitely the exception here. It’s not uncommon for users to not only tolerate a badge count of more than ten, but a badge count of more than one hundred. This is likely due to the fact that users have had decades to get comfortable and familiar with high unread mail counts. Unless your app has a similarly long history, it’s probably best to avoid letting the badge count run too high.
SMS: Must Read Messages
There is an almost infinite number of ways 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. Let’s narrow our discussion, however, to SMS only a means of customer communication. SMS should be reserved for must-read items. 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. When 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 their highest scoring final board in a Scrabble type game? Absolutely. Does that include requests to invite friends to the app? Maybe not.
Uber does a great job with this. Instead of sending a toast notification that you have a new receipt, Uber emails a receipt and ride summary to their customer. This makes sense since it’s content that customers will likely revisit.
If you would like to get started with Mobile Services and are new to Windows Azure, sign up for the Windows Azure 90-day Free Trial and receive 10 free Mobile Services running on shared instances.
Visit the Windows Azure Mobile Development Center to learn more about building apps using Mobile Services.
If you have feedback (or just want to show off your app), shoot an email to the Windows Azure Mobile Services team at firstname.lastname@example.org.
You can also find me on Twitter @kirillg_msft