Details of iOS APNs and pushkit doorways

Basic

At the beginning of the birth, iOS made some visionary and far-reaching designs to maximize the user experience. APNs (Apple Push Notification Service) is one of them.

Early iOS devices had limited memory and CPU resources, and iOS was "not allowed" to live in the background to allow the app to have as much system resources as possible, and to conserve the device's power. This decision largely protects the user experience and extends the phone's standby time, but app developers need to keep in touch with their users. Developers need to have a stable network channel to push new content to user devices every once in a while. Apple decided to build its own maintenance channel, which is what we call APNs today. When I first started contacting iOS, I noticed that there were a lot of developers with the push mechanism, and I felt that it was not controllable and increased the cost of development. In fact, a little bit of thinking about Apple's platform size and message volume today, and the cost implications, will give you a sense of the intelligence and boldness that Apple needs to design this mechanism. Everything is for the user.

APNs while allowing developers to push messages to user devices, the long-link channel maintained by Apple cannot be used indefinitely, given the magnitude and cost of the message. The APNS has many limitations:

Reliability. In general, Apple will ensure that the qaulity of Service of this channel, that is, push messages can arrive at the device stably in time. However, once the user's device is in the offline state, Apple will only store the latest push sent to the user, and the previously sent push will be discarded. And this last offline push also has an expiration time. Some users should have had this experience, in the use of the time, obviously the other sent a number of messages, but only received a push.

Payload Size. The package body size of each push message is the maximum limit. Apple clearly stated in the documentation that push should only be used to notify the user of new content and should not be used to host the content itself. Theoretically, the smaller the size of the payload, the higher the probability that push will reach the device. Before iOS8 Max payload size was 256 bytes, to iOS8 released the maximum value was adjusted to 2048 bytes, and then to the recent IOS9 release, introduced Http2.0,payload size was set to 4KB. The old version of the 256 bytes is a bit stretched, and even plug a link to think twice. To 2KB time is more comfortable, there are many developers have begun to try to put a small amount of business data, if you can reduce the opening of the app after a network request why not. Of course, 4KB will be more imaginative space. Apple has been tweaking this value to give developers more room to improve the user experience. Push slowly becomes more than just a "alert" so simple.

The success rate is not high. While Apple guarantees a certain degree of reliability in the push channel, push does not guarantee a high level of reach for a variety of reasons. Push needs to request permission from the user, even if the permission was given at the time, and may be turned off by the user because of the push too frequently. In night mode push can reach the notification bar, but the user does not have any sense, let alone click Push to launch the app. There is also server-side token invalidation, which can be feedback service to clean up failed tokens. Apple's APNs server is said to send more than capacity push per day, and the success rate of the developer server and Apple server connections will decrease when spikes occur over a certain period of time. There are also factors such as the unstable network environment of the client device, which makes the successful launch of the app through push not much higher success rate.

By understanding these limitations, you can push content to users according to Apple's specifications. But the doorway in push is far more simple, and Apple has never stopped optimizing for the APNs experience, like payload size adjustment, interactive notification, and so on, every new feature, even minor changes, Can be used by smart developers to enhance the product experience with four or two dials. Here are some of the "hidden doorways" that I have learned.

Not just local Push

Many individual developers do not have the condition to set up a server, and a timed local push is usually provided to alert the user to waking up their app. The Local push seems to be a cheap compromise, in fact it can be more powerful. APNs (also known as remote push) because of the restrictions above, and does not fit well with the business needs. The local push is different, has a complete app business context, and can be customized for push. If you can use local push instead of remote push, the experience boost is self-evident. The limit of Loca push is that the app must be running in order to initiate, and many smart developers will open background task, and after the user presses the home key for a few minutes to run, all remote push is replaced by the local Push Don't underestimate these minutes, and for many active apps, it's not a small chance to press the home key to generate new user content immediately. , WhatsApp uses this mechanism to enhance the experience.

Wake up your App

After you open the background task, you can run a little longer, but when the time is up, the app will be suspended or killed. Most of the time your app is in a non-active state. Many apps require pre-fetching content, or downloading files in the background to reduce user latency. The silent notification and background fetch mechanism introduced by IOS7 can meet this requirement to some extent. The silent push implementation is relatively simple, enabling the following JSON to be sent in a specific format after the relevant background permission has been opened.

Wake up the app to deal with a lot of business, this is a lot of apps is a very practical development, pre-loaded content, or generate local push, can enhance the experience. But this wake-up mechanism is not always reliable, and sometimes it can be called "Awake". If the app is manually killed, it won't wake up if the background fetch is closed by the user, but in both cases it can be woken up when the phone is charged. Apple has its own "smart" strategy.

Foreground Message Channel

Most of the time APNs is used to notify users of a new content in a background app. But the truth is, APNs is a long-linked data channel that can receive push messages when the app is foreground, but there will be no UI display reminders. The location of the callback is also in other words APNs is actually a free foreground message channel. And sometimes the APNs channel will be faster than its own server channel, if the client to do a good job of data deduplication, a number of secondary data channels can certainly enhance the experience.

New Avatar Pushkit

APNs design is designed to avoid the application of the background, only when the user receives the push to initiate the app. The silent push mentioned earlier can be used in a limited scenario without user awareness of launching the app. But by the time IOS8 introduced the Pushkit framework, the app could be woken up by push, but the new Avatar was temporarily limited to VoIP applications.

Before the community saw someone ask questions, said the phone can be in the user hangs up the phone, the call in the push to the missed phone, how curious to do. Because everyone knows that remote push is unable to dynamically modify the push content through the server, there is only one possible answer, and the app is woken up in the background. The push that the user sees is actually a local push, and the local push can be adjusted at the client's discretion. The way to wake up is to use Pushkit.

Of course, the benefit is not just modifying the push content. WhatsApp users should have a noticeable feeling after iOS8, as if they rarely see the startup page. It seems that WhatsApp has turned on the VoIP backend resident mode, but this mode will compare the cost of electricity, some users will be concerned. The truth is not so, WhatsApp is not in the background, but is to open the Pushkit push wakeup mechanism. Each time a user has a new offline message, normal text or VoIP Call,app will be woken up by the background, pull offline messages from the server, and then generate a local push. When the user clicks on the local push to launch the app, there is no launch page, no connecting and loading, all the data is ready, as if WhatsApp had been running in the background. In other words, WhatsApp has actually replaced all the push with the local push. The validation method is also simple:

• Manual Kill WhatsApp.
• The phone enters airplane mode.
• Receive an offline message.
• Use tcpdump to start listening for iphone network packets and turn off airplane mode.
• At this time, the app was push wake up, you can see a WhatsApp-related domain name resolution, indicating that the app was launched.  And you can see a lot of subsequent server interactions (pull offline messages, and so on). 2 Do not know what to consider, neither to open the VoIP backend resident mode, nor to utilize the Pushkit wakeup mechanism. Every time you receive a message after opening the app, are first to see the Earth, connected, charged, to really see the latest news often need more than 3s. The Pushkit has no additional power loss, and the experience of VoIP-class applications is greatly improved.

How to implement Pushkit can refer to the link address at the end of the article.

Summarize

With regard to push's long link channel, Apple has added some feature in almost every new version of iOS. In order to control the impact of the new feature, each change is not much, but how to use these feature to see the developers each have the skill. The changes to the user experience are far more than the official documentation of the simple, only a lot of thinking, always pay attention to the latest industry trends, to explore more hidden "doorway."

Reference articles

1. Apple APNs Official Document: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/ Remotenotificationspg/chapters/applepushservice.html
2. Silent Push implementation: Http://hayageek.com/ios-silent-push-notifications
3. Pushkit implementation: Https://zeropush.com/guide/guide-to-pushkit-and-voip

From: http://music4kid.github.io/ios/2016/01/06/push/

Thank you: http://www.open-open.com/lib/view/open1452487743355.html

Details of iOS APNs and pushkit doorways