Pimp my Car: Best of Auto-Sticker
24. Juni 2016
Angst um die eigenen Daten
6. Juli 2016

TankTaler-Technik News

Heute erwartet euch Teil 2 der iOS-Silent-Push-Notifications:

What makes a Push silent?

So lets talk about what makes a push payload silent. Of course, this is something your backend team should worry about, but you should know it as well.
The only thing you need to do to turn a push notification into a silent push notification is add `content-available: 1` to the `aps` section of the JSON.

content-available: 1

Additionally, you might want to remove the `alert` and `sound` properties from there. In my experience, if you don’t, the push is still not going to be silent and the phone will show the notification.

Aaaaand, that’s it – you’re good to go!

Setup your Project for receiving Silent Push Notifications

There’s one additional step you need to go through in order to enable silent pushes. You need to add `remote-notification` to the `UIBackgroundModes` key in your Info.plist file. In Xcode this should look something like that:

Silent Pushes Background Modes

Silent Push Notification Limitations

Up until now it’s all been smooth sailing. It seems silent push notifications are a good fit for your projects.
But remember, this is Apple and multitasking – there will be a catch. And here it is:

” …the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.”

This quote, taken right off the `application:didReceiveRemoteNotification:fetchCompletionHandler:` method’s documentation, reveals a major disadvantage to using silent push notifications. Basically, if the user kills your app from the task switcher, no subsequent silent pushes are delivered until the app is manually started again.

Note: The statement above holds true for silent pushes only. Even if the OS stops delivering silent pushes, “normal” notification still work fine.

From a user perspective, this is quite reasonable, I think. If an app is misbehaving, I should be able to stop it completely. If it restarts every time a rogue backend sends a silent push, things can get bad. However, from a developer perspective, silent push notifications turn into an unreliable channel. You can no longer ensure a reliable server to client communication. And people clearing running apps on their phone is a common thing.

I asked around in the TankTaler-Team and we found that around 20% of the people regularly kill apps on their phone.

Again, using silent push notifications in the context of a background fetch, this limitation is perfectly fine. If the user killed the app, you just don’t get to download new content. But if pushes are a trigger for a critical operation within the app,
you might find yourself in a world of trouble.

A possible Workaround

When Apple gives you an unreliable push notification scheme, make a workaround.
One possible solution we were considering in the TankTaler-Team is using silent pushes and reverting to conventional notifications if the app is not responding to them.
Of course, this means that every silent push needs to be acknowledged in order for the server to know if the device received it. And this needs to be done on per-device basis since there might be several of them connected to the same account.
Additionally, since it’s possible that a device receive both a silent and a normal notification for the same event, pushes have to have an identifier that signifies that they all refer to the same event.

It’s not ideal, but if you don’t have other choices, you might consider this option.

Next Steps

Silent push notifications can be a powerful addition to many iOS projects. However, before investing precious development time implmenting them, you should carefully evaluate if their limitations will not have a negative effect on your users’ experience. Most importantly, think if you can afford to lose push notifications when the app is killed from the task manager. Also remember that those limitations are there to protect the phone’s overall UX. Avoid spamming the device with silent pushes and be sparing on the network and CPU time. As a wise man once said:

” … In practice, you should call the handler block as soon as you are done processing the notification. The system tracks the elapsed time, power usage, and data costs for your app’s background downloads. Apps that use significant amounts of power when processing remote notifications may not always be woken up early to process future notifications.”

— Some guy from Apple, that wrote the developer reference docs.

Note: If you’re working on a VoIP project, you might consider using PushKit instead of silent or regular pushes.

Wir hoffen, ihr habt einige spannende Einblicke in die TankTaler-Technik-Welt bekommen. Wenn ihr Fragen habt, wird euch diese Niko bestimmt sehr gerne beantworten 🙂

Liebe Grüße vom TankTaler-Team

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.