Silent push notifications are provided only if the device is charging and / or the application is in the foreground

Question

I implemented silent push notifications, but I noticed some strange behavior. Silent push notifications are processed through:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler 

Silent push messages, apparently, are only received if the device is charging (i.e. a cable is connected) and / or if my application is in the foreground.

If I disconnect the device from the charger (or Mac), quiet push notifications will no longer be accepted if the application is not in the foreground.

In both cases, I get non-silent push notifications.

If I plug in the USB cable again, I get the expected behavior, and silent push notifications are received regardless of whether the application is front or background.

I use UILocalNotification, so I know what it gets.

The fact that everything works perfectly with the connected device means that my quiet clicks of notifications are configured correctly and that the application has the correct background modes set in plist, etc.

This behavior is repeated on the iPhone 5s, 6 and iPad 2, running either on iOS 8 or 8.1.

Has anyone else experienced this? This should be easy to reproduce. Why does a simple way to connect the device to the charger change the ability to receive silent push notifications?

Answer 1

We experienced the same behavior and are trying to understand why iOS decides to provide some notifications and not others.

What we have developed so far:

• Messages are received more reliably in the background, if on Wi-Fi then on cellular data. In fact, if on a cellular network (3g / 4g), if the signal strength is not enough, iOS receives a push message, but does not wake up your application. We post on the Apple forums about this here: https://devforums.apple.com/message/1069814#1069814 . We also opened a support ticket, and the support team informed us to file it in the form of a bug report, which we made a couple of weeks ago, and are still waiting for an answer.

• When you receive a push message, you need to call fetchCompletionHandler as soon as possible. Technically, you have 30 seconds to do background processing, but iOS has a formula in which the more often you send push messages and depending on the amount of time you spend processing this message before returning the application to a suspended state, iOS may reduce the amount of time your application wakes up in the future.

See here Apple didReceiveRemoteNotification: fetchCompletionHandler: documentation:

As soon as you finish processing the notification, you must call the block in the handler parameter or your application will be terminated. Your application has up to 30 seconds of wall clock time to process a notification and call the specified completion handler block. In practice, you should call the handler block as soon as you finish processing the notification. The system tracks the elapsed time, power usage and data costs for downloading phonograms of applications. Applications that use significant power when processing push notifications cannot always be woken up early to handle future notifications.

In our testing, we send frequent silent push notifications to our application (every 10-30 seconds). And the application wakes up for about 3 seconds before we get it back to sleep. We definitely noticed over time a deterioration in the frequency at which our application wakes up to the point that iOS will only wake the application every 15 to 30 minutes. So there is actually some kind of decay / throttling formula, but we cannot find any documentation on how it works. We requested this formula and variables from apple as a support request, but they said: "The information you requested is not publicly available" and again asked us to provide an error report.

So, hope this is helpful? We are still trying to learn more about ourselves, so I found this question :)

Answer 2

With changing background loading of iOS8 in applications. In some cases, a background click will be delivered only to the application. Apple did not directly state what these circumstances are, but from my extensive experiments it basically comes down to whether the phone is charging or not. There are other variables in the game (for example, network type, device type, Wi-Fi support), but the main main factor is whether the device is charging or not when it is pressed.

If the phone is charged via a direct power source or indirectly connected via USB to a computer, then the background presses will be delivered to the application for the vast majority of the time. But disconnect the phone from the power source or USB, and the background button will almost never be delivered to the application, even if the phone’s battery is 100% charged.

You can easily test this for yourself by simply sending a few taps while the phone is charging, while it is not there. BUT you have to take into account that the background steps are using the development build and using the sandbox environment. Do not behave in the same way as the background steps with the production assembly and the production environment, background clicks are likely to be delivered to the application during the development process, they are in production, so it is very important that you test using the production assembly and the Apple production environment to see actual results.

Please note that there are two steps to push delivery, firstly, it must be delivered on the phone itself, and secondly, when it has one, then it needs to deliver the OS to the application. In iOS7, things like turing on Wifi made the chances of a push getting closer to the phone. However, with iOS8, although pressing is successfully delivered to the phone, the OS does not send it to the background application if the phone does not charge. This means that the phone receives a notification and holds on to it, sometimes for several hours, before it can redirect it to the application if the phone is not charging.

Answer 3

I had the same problem, and the reason why I don’t get a push notification when the application is not charging is that when Low Power mode is enabled with Settings > Battery , it disables the background-fetch function for all applications.

What prevents the device from receiving push notifications.

This link may be helpful. Apple Documentation

Answer 4

I also noticed the same thing and spent some time figuring out. See https://stackoverflow.com/a/318626/

If you turned off the Bg App Refresh application, a quiet remote press will silently be discarded (irony).

However, my observation is that if you connect to Xcode by cable, somehow the Bg App Refresh parameter is ignored, and all silent clicks for your application work.

I highly suspect this is an undocumented feature: charging makes the Bg App update option ignore.

Answer 5

This does not work because you turned on the wrong background in the plist. You need to enable the remote-notification tag (the application loads the content in response to push notifications), and not retrieve it. Fetch is used for something else. You may also need to use available content in your JSON payload, for example,

 { "aps": { "content-available": 1 }, "yourdatakey":{data} } 

Answer 6

I hope you use APNS delivery priority "CONSERVE_POWER" (5) , try changing it to "IMMEDIATE" (10)

Answer 7

I have been experiencing this problem for some time, and am very grateful for this question, and @Kevin D. shares his understanding. I'm starting to think that https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc / uid / TP40008194-CH101-SW4 (see priority in one of the tables) describe why my application has problems:

An error occurred using this priority for a click containing only the content-available key.

To send notifications, I use node-apn , where by default (which I also need) to set max priority ( 10 [be careful, it looks like only 10 and 5 are the correct values ​​at this time]), but since I wanted to receive a silent notification, I do not have alert , badge or sound .

Answer 8

If your application does not support VoIP, you will not be able to fulfill this answer [your application will be rejected]

I found another solution that works for me using PushKit Framework

VoIP push signals provide additional functionality in addition to the standard push request that VoIP applications require to process push notifications before displaying a notification to the user

When I send VOIP Push, the application wakes up regardless of the state of the application and can perform any operations

. Register for VOIP push notifications at didFinishLaunchingWithOptions

  PKPushRegistry *pushRegistry = [[PKPushRegistry alloc] initWithQueue:dispatch_get_main_queue()]; pushRegistry.delegate = self; pushRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP]; - (void)pushRegistry:(PKPushRegistry *)registry didUpdatePushCredentials:(PKPushCredentials *)credentials forType:(NSString *)type{ if([credentials.token length] == 0) { NSLog(@"voip token NULL"); return; } NSString *originalToken=[NSString stringWithFormat:@"%@",credentials.token]; NSString *token = [originalToken stringByTrimmingCharactersInSet: [NSCharacterSet characterSetWithCharactersInString:@"<>"]]; token = [token stringByReplacingOccurrencesOfString:@" " withString:@""]; NSLog(@"PushCredentials: %@",token);} 

then you can handle any background extraction in this function as soon as you get VOIP PushNotification

 -(void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(NSString *)type 

NOTE. You must use a certificate that includes a certificate of VoIP services