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?

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