IOS remote silent notification is not working during phone calls / network fluctuation

Question

I am developing the iOS application where I am doing the background work. I am awaking the app by sending the silent notification. The code is working fine most of the time.

The issue is during the phone call app is not awaking, even during the low network connectivity or during network fluctuation app is not awaking.

I am doing the following things:

1: Enabled 2 background mode
   i) Background fetch.
   ii)Remote notification. 

2: Sending notification as:

   { 
  aps: {
          content-available: 1,
          sound: ""
          message:"background fetch"
       }
    } 

and 
3)
-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler{
     UALogFull(@"\n\n BACKGROUND NOTIFICATION \n\n\n");
     completionHandler(UIBackgroundFetchResultNewData);

}

My observation is: The app is not crashing. It is not logging "BACKGROUND NOTIFICATION" even there notification during the phone call( the mobile is connected wifi ).

Please let me know how I can get the accuracy?

Ostrom

Please let me know the solution. – Ostrom

Can you hear the sound when receive push notification during phone call/when app is in background ?? Try this payload: { "aps": { "alert": "Hello World", "sound": "default", "content-available": 1 } } to confrim that you are seeing the alert and receiving push notification – Pigtail

The device receiving the notification and it is working, but some time device not able to weak up from suspend mode to background. – Ostrom

I guess your app is killed when you are receiving the notification. If that's the case then you need to handle notification in application:didFinishLaunchingWithOptions: also. Detail Here and here are some similar questions if this is the issue: Crash when handling remote notification when app not running PLUS iphone Launch Options – Pigtail

There is no visible notification, it's in the background. – Ostrom

Yes I know. I am just saying you try this to debug the issue. If u can receive visible notifications then u will receive silent notification too. Have you handled notification in application:didFinishLaunchingWithOptions: as suggested? – Pigtail

Yes, I am handling that as well. the app starting working after some delay. – Ostrom

Let us continue this discussion in chat. – Pigtail

Still having the same issue. Is there anything which I am missing? – Ostrom

Answer 1

I believe just because you are sending a silent notification, doesn't mean that the application will get notified straight away.

From my observations using a GSM iPhone. Whenever I am on a Phone Call the Cellular Data type drops a band e.g. LTE -> 3G, 3G -> EDGE etc. So the data network is not reliable.

You also state that it does not happen during network fluctuation, the system has recieved the notification, it hasn't passed it along for battery saving purposes. The slower the cellular data connection is, the more draining on the battery.

In regards to a phonecall on wifi, still not recieving the silent notification. The cellular chip is running, using the wifi as well would drain the battery even more.

From my understanding a silent notification is to let the device know that there is new data available. Because the window to download said data in the background is a small window, there may be certain cases where it is not appropriate with the examples you are describing essentially being the reasons.

On a phone call -> The cellular chip is being used for voice transmission. Data transmission is extra work for the chip to do which could affect battery life dramatically.

Network Fluctuation -> The system cannot guarantee a solid connection allowing for data to be downloaded. Also being in a slower data speed area is additional strain on the cellular chip that is trying to locate a stronger, more stable connection band.

A silent notification allows your app to present fresh data to the user as a benefit to the user when they switch back to your app, they don't have to wait for fresh content for as long. But it is not an essential part of app functionality. The system will also determine whether to pass your notification along based on other factors, such as time since last launch. Too soon after closing or a long time after closing the app might mean that your app won't get priority and will have to wait for other apps,

too soon: content is still relatively fresh. long time: The user is not using the app a lot. Save resources.

Mix in with this launch patterns. If you send the notification along at a time when the user is more likely to launch your app based on previous patterns, you are more likely to recieve the notification.

Finally to quote the documentation:

Important: Delivery of notifications is a “best effort”, not guaranteed. It is not intended to deliver data to your app, only to notify the user that there is new data available.

Found Here

Antihelix

I am sending notification for each 5 min. and it drops only 6 to 8 time in 24 hours. – Ostrom

You cannot guarantee that each notification will be delivered. A 2% failure rate is extremely good. As I have said, the system determines whether to pass through the notification based on different factors. Also add in the the APNS system is a "Best Effort" and no guarantees are made for 100% delivery. If you ran your app on device based on low, average and high usage you would have different success rates. – Antihelix

I aggregated that, but the issues are some time it will not work on series of notifications( drop 2 to 3 notifications in series). – Ostrom

Just because one notification was not sent/handled does not mean the next one will. If it is down to the APNS only the latest notification will be sent. If it is down to the system not handling/passing through the notification I imagine it just fails and leaves it be, the system doesn't know if the silent notification is still valid and because it is silent, it isn't "user critical", thus and "forget it and wait" handling. – Antihelix

The problem is not with the notification not being received, but that the app is not woken up... see similar question... – Unmerciful