In December 2015, Apple released a new provider API for Apple Push Notification service (APNs). This API is based on the HTTP/2 network protocol and allows app developers to send remote notifications to their app on iOS, tvOS, and OS X devices, and to Apple Watch via iOS.
We’ve analyzed the new provider API, and in this article, we’ll present a breakdown of its most important features and the benefits this long-awaited update brings to iOS developers.
Why we needed this APNs API update
APNs debuted back in iOS 3 era, and has remained largely unchanged throughout all these years, even despite implementing APNs has always been somewhat problematic for the app developers. Here are only some of the issues that were making the work with APNs too time-consuming and complex:
- Notifications had to be serialized to a binary format and sent individually using a secure TCP socket.
- Sockets required Apple’s SSL certificate to be opened in.
- All - Development, AdHoc, App Store, and VoIP apps - had to use different certificates.
- We had to use a separate binary TCP socket API to check for unsubscribed devices in order to avoid sending future notifications to them.
- All errors led to the TCP socket closing.
- Error codes were too generalized which made it difficult to identify the exact causes of errors.
- A high notification throughput required multiple simultaneous connections to be opened.
The new provider API finally fixes all these issues making Apple Push Notifications service much more fast and convenient thanks to HTTP/2 protocol and JSON data interchange format.
New features
The HTTP/2 APNs provider API makes our life as developers much easier by the following things:
- A JSON-based request-response protocol
- APNs now sends 200 Success Response on each notification
- Errors are now getting a JSON-string response with detailed error descriptions
- Message length increased from 2048 bytes to 4096 bytes, which enables to add extra content to notifications (not just text, but also images and GIFs)
- Compression allows to reduce the number of simultaneous connections to sustain a notification throughput
- The connection status check with the HTTP/2 PING Frame
- Topics support - you can now identify topics (bundle identifiers) for your notification
- The Universal Push Notification Client SSL Certificate for Development, AdHoc, App Store, and VoIP apps
The updated push notifications delivery service protocol
How the HTTP/2 protocol makes notifications more effective
The HTTP/2 is basically an extension of the previous HTTP 1.x standards. This means that, although HTTP/2 eradicates the performance limitations of the previous protocols, the core concepts remain the same, and the developers don’t need any app-level changes to update the existing notification systems.
Binary framing layer
The performance enhancements of HTTP/2 are possible thanks to the new binary framing layer. It introduces a more effective way how to encapsulate and transmit HTTP messages between the client and server.
Binary framing layer
The binary framing layer splits all HTTP/2 communication into smaller messages and frame, encoding them in binary format. Yet, the apps will be unaware of those changes - all changes happen on a client-server level: while the HTTP semantics remains the same, only the way how it’s being transmitted and encoded is now different.
Also, with the new binary framing mechanism, we can say farewell to parallel TCP connections. Now, splitting streams into many interleaved and prioritized frames makes connections persistent and fast since it requires only one connection per origin.
Data exchange mechanism
The new mechanism of data exchange is based on three components: 1) Streams, 2) Messages, and 3) Frames.
All communication goes through a single TCP connection that can carry any number of streams.
Stream is a two-directional flow of bytes that happens during the connection and transmits messages. Each stream carries messages using a unique identifier and optional priority information.
Message is a logical request or response mapped by a sequence of frames.
Frame is the smallest unit of communication in HTTP/2. Each frame contains a header that identifies the stream the frame belongs to.
Hence, the HTTP/2 protocol communication is realized through the exchange of binary-encoded frames which are mapped to messages. Messages, in their turn, belong to particular streams. All these components are multiplexed within a TCP connection and ensure the best performance the HTTP protocol ever had.
Request and response multiplexing
As mentioned above, the binary framing layer in HTTP/2 enables full request and response multiplexing within a single TCP connection: first, the client and the server breaks an HTTP message down into independent frames, then interleave them, and finally reassemble them on the output.
This improvement alone leads to a number of performance benefits for push notifications, including:
- Interleaving multiple requests and/or responses without blocking on any one
- Interweaving the logical streams over a single TCP connection without head-of-line blocking
- Using a single connection to deliver multiple simultaneous requests and responses
- Removing of the unnecessary HTTP/1.x workarounds that we were using to compensate the previous protocol’s shortcomings
Three parallel streams being transmitted between the client and the server within one connection
Header compression
Each HTTP transfer carries a set of headers with metadata that describe the transferred resource and its properties. In HTTP/1.x, headers were sent as plain text adding a considerable weight. In HTTP/2, request and response header metadata are compressed using the HPACK compression format.
To compress headers, HPACK uses two techniques:
- Encoding the transmitted header fields using a static Huffman code, which reduces their individual transfer size.
- Encoding the transmitted header fields using an indexed list of previously transferred values as a reference for the effective reconstruction of the full header keys and values.
HPACK header compression for HTTP/2
Conclusion
Before the update, Apple Push Notifications service was limited by the shortcomings of the HTTP/1.1 protocol. The protocol’s forcing to use multiple TCP connections to process multiple requests simultaneously had a huge negative impact on the network performance. The old APNs also required different certificates for different app builds throughout the development process course and was making it almost impossible to track the sent notifications.
These and many other issues were unnecessarily time- and resource-consuming for us as app developers.
The new APNs provider API employing HTTP/2 protocol solves all major problems the previous API had, allows to eradicate unnecessary workarounds, greatly increases performance, and reduces the overall development time.
Further reading on APNs and HTTP/2:
What’s New In Apple Push Notification Service / WWDC16
Local and Remote Notification Programming Guide / Apple Developer
Getting Ready For HTTP/2: A Guide For Web Designers And Developers / Smashing Magazine
Also, read about our iOS and Android app development services.
