After a stay of execution, on March 31st Apple are finally discontinuing the APNs legacy binary protocol used to send push notifications to iOS devices. If you have an app in the App Store with push notification capability or an Apple Developer account, you will have likely already received an email from Apple telling you to update to the HTTP/2-based provider API.
In this article, we’ll quickly explain what this means and what you have to do (spoiler alert: if you’re a Kumulos customer – nothing)!
First, some background…
The Apple Push Notification service (APNs) was first announced in June 2008 as a more battery efficient way to send or push messages to apps than long-running background processes that would continually poll for and pull new messages if there were any. Interest in the service was immediate and led to Apple pushing back the initial launch so they could re-architecture APNs to scale to meet to the overwhelming demand.
APNs was first launched in June 2009, back when iOS 3.0 was the operating system of choice on your iPhone 3GS! Since then, push notifications have become widely accepted as the single, most effective way to reach out to and engage (or annoy if done badly) a mobile user.
APNs Legacy Binary Protocol
Back in 2009, if you wanted to send a push notification, you had to call APNs directly using the APNs Legacy Binary Protocol (of course it wasn’t legacy back then, but keep reading, all will become clear). Writing this as a long-ago Comp Sci graduate, who started out coding C++ on Unix servers for Telcos, even I can fully appreciate that although highly efficient and functional, binary interfaces are challenging to use, unforgiving of errors and therefore not necessarily for everyone. Therefore, it was no real surprise that in 2015, Apple released a new HTTP/2 provider API for APNs.
In the intervening years, and with Google adding Push Notifications to Android in May 2010, some vendors such as yours-truly, emerged as a means to abstract away the complexity of interfacing with the APNs Legacy Binary Protocol and Google Cloud Messaging (GCM – as it was called back then). Furthermore, these vendors such as ourselves, incorporated analytics to expand upon the basic push functionality of APNs and provide sophisticated, intelligent user, behaviour and location-based audience segmentation and targeting, accessible either through an easy-to-use campaign management UI or a transactional, RESTful API that worked with both platforms. However, under-the-hood, these vendors were all using the APNs Legacy Binary Protocol themselves.
Apple supported the APNs Legacy Binary Protocol and the HTTP/2 Provider API alongside each other for the next four years, before announcing in 2019 that support for the APNs Legacy Binary Protocol would be discontinued. At first, this was expected in 2020 but a stay of execution was then granted until 31st March 2021 – perhaps due to the aforementioned vendors who were still using it themselves!
What do you have to do?
First off, if you are a Kumulos customer, nothing! Why? Because we have already done this for you! Kumulos switched over to the HTTP/2 Provider API in early 2020, not long after the initial announcement from Apple. Win!
If you are using another push notification vendor, then the chances are you won’t have anything to do either. However, it might be worth checking in with them, just in case. It is widely believed that the reason Apple granted the APNs Legacy Binary Protocol a stay of execution was to allow some vendors, who had not been as prompt as Kumulos in adopting the HTTP/2 Provider API, further time to migrate. Best not leave anything to chance and give your vendor a call today.
Finally, if you have built your own in-house integration using the APNs Legacy Binary Protocol and haven’t yet updated this use the HTTP/2 Provider API, then you have some work to do, and fast!
Build vs. Buy
The re-opens the debate of build vs. buy. Why pay a vendor such as Kumulos when you can call APNs directly using the HTTP/2 Provider API? If your app is only available on iOS and only ever targets notifications to individual users, this may be a compelling question.
However, there are four significant reasons why using a specialized mobile messaging vendor to send your push notifications might be the way you want to go from now on…
- Firstly, and most obvious, is that vendors such as Kumulos, enable you to send mobile push notifications across different platforms including iOS, Google Android and Huawei Android through a single SDK, UI and/or API without having to build interfaces against each platform’s APIs (which we have already done for you).
- Secondly, vendors such as Kumulos are backed by analytics and as such provide intelligent user, behaviour and location-based audience segmentation and targeting options, all through an easy-to-use campaign management UI – functionality that increases the impact of your push notification campaigns and functionality that you will have to code and build yourself, should you choose to go down that route.
- Next-up, and related to the above, vendors such as Kumulos invariably incorporate other messaging channels such as in-app messaging, web push notifications, SMS and email, enabling you to provide a rich, seamless experience through the complete user journey.
- Finally, and perhaps most importantly in this context, vendors such as Kumulos shield you from numerous changes to the platform APIs and the significant complexity in using them. For example, Apple require you to hold open and reuse existing connections to the HTTP/2 provider API for “as long as possible” (for many hours to days) and have also recently required all connections to incorporate a new root SSL certificate. In addition, Google have also deprecated their own legacy HTTP API and are encouraging everyone to migrate to the latest HTTP v1 API – we also migrated to this API in early 2020, so again no action required for Kumulos customers.
One of the wider implications of Apple discontinuing support for the APNs Legacy Binary Protocol is that many apps and vendors used the feedback mechanism, rightly or wrongly, as a proxy for app uninstall events. The HTTP/2 Provider API will return if a token is invalid it (either by blocking push notifications or uninstalling the app) but, for privacy reasons, this will only happen after a random delay of days or even a few weeks.
However, rather than focusing on the uninstall number, we would instead recommend you focus on retention and engagement – how many users you have retained, engaged and converted to the next step in their journey through timely, personalized messaging? Great! Now what can you do to increase that number!
For those that do drop-off or for those who simply prefer to be engaged via different messaging channels, the Kumulos platform contains a range of features designed to ensure you know and can target users on the channels they are most active on, without having to broadcast across them all (or worse, shout into an empty room). For more details on our reachability checks, Contact Us and we’ll be happy to discuss the options that are right for your app and its audience.
Despite the somewhat alarming email from Apple, users of Kumulos and more than likely most other push notification vendors will have nothing to do. If, however, you have built your own integration with the APNs Legacy Binary Protocol, then you now have a decision to make – update this to the new HTTP/2 Provider API or start using a specialist push notification vendor, such as Kumulos. There are a number of factors that will influence this decision, but in our experience, more and more are stacking up in favour of outsourcing the delivery of push notifications to specialist providers, freeing you and your team up to focus on the app itself.
We’d be more than happy to discuss the pros and cons of both approaches with you and promise absolutely no hard sell. Contact Us today and we’ll put the kettle on!
To find out how to build and execute an effective push notification strategy, download our Push Notifications Best Practices Guide now.