3

I’m building an app which handles notifications pushed from Parse, and trying to create a notification history function. I’ve enabled the background modes successfully, so when the app is running in the background, the app can get the payload well via application:didReceiveRemoteNotification:fetchCompletionHandler even the banner/alert is not tapped. However, when force-quit / swipe up to kill the app, application:didReceiveRemoteNotification:fetchCompletionHandler is not called.

Is there any method to implement for getting the push notification payload when the app is killed without tapping the banner/alert? Thank you in advance!

Viral Savaj
  • 3,379
  • 1
  • 26
  • 39
Alison
  • 431
  • 6
  • 19
  • `application:didReceiveRemoteNotification:fetchCompletionHandler` works only when app is running. How can you call a function of an app when its not running? And what will you do with the data when app is not running? It needs to be handled only when app runs foreground/background. – iphonic Jun 01 '15 at 10:59
  • Thanks for the reply! I'm trying to create a notification history function, which displays all the notification received with a Tableview, so I hope that every time when a notification arrives even when the app is killed, the app can still get the payload when it is re-launched, and display the content. If there is no method for the purpose, are there any other approaches to make this possible? – Alison Jun 01 '15 at 11:13
  • Is this an implicit operating system level policy? Why doesn't iOS start the app in background if it receives a silent (content-available: 1) push notification? Is there any local mechanism by which I can schedule jobs/tasks/timers at the OS level, such that when the timer expires my app gets started in background if it was killed? – Alex Bitek Dec 07 '16 at 13:21
  • @Alison have you find any solution? Currently I am struggling with the same. – Beu May 11 '20 at 11:14

1 Answers1

6

You can't get a notification's payload if your app is killed.

In most cases, the system does not relaunch apps after they are force quit by the user. One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user. In other cases, though, the user must launch the app explicitly or reboot the device before the app can be launched automatically into the background by the system. When password protection is enabled on the device, the system does not launch an app in the background before the user first unlocks the device. - Understanding When Your App Gets Launched into the Background

Anyway, push notifications are not reliable.
It means that you can not be sure that they will ever be delivered.

If you want to keep a "notification history" list, do it server-side and fetch it in-app (in a totally not push related way).

Each time you send a push notification, keep it's content in database, like any object. Then when the user opens the history list, fetch the list like any other parse object.

Quentin Hayot
  • 7,786
  • 6
  • 45
  • 62
  • Is this an implicit operating system level policy? Why doesn't iOS start the app in background if it receives a silent (`content-available: 1`) push notification? Is there any local mechanism by which I can schedule jobs/tasks/timers at the OS level, such that when the timer expires my app gets started in background if it was killed? – Alex Bitek Dec 07 '16 at 12:52
  • 1
    It is not implicit. When an app is killed by the user, background fetch is disabled for this app until the user manually opens it again. About your job/task/timer question, the answer is no. This is against iOS sandbox philosophy. **TL;DR: You can not start an app which has been killed by the user without taping on it's icon. At all.** – Quentin Hayot Dec 07 '16 at 14:10
  • 1
    I updated my answer to add Apple's documentation about this. – Quentin Hayot Dec 07 '16 at 14:19
  • Thanks for the update! From the docs I read that `One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user`. If the app has registered to receive 'Location updates' and the app was previously killed by the user by a swipe up, does the app get relaunched for every location update or only for areas/locations registered as geo fences/monitored regions? From `[...] assuming that the sessionSendsLaunchEvents property was set to YES and that the user did not force quit the app` I get the idea that the app will in fact NOT be relaunched if swiped up. – Alex Bitek Dec 08 '16 at 10:25
  • I think that the app will only be restarted when reaching a geofence. This is speculation, but it would be 100% against Apple's privacy philosophy to restart a user killed app to send live location updates. – Quentin Hayot Dec 08 '16 at 10:44
  • Your answer is good advice on how to handle a notification history, but you can get a notification payload after an app is killed. After it is tapped, It will be received in the didLaunchWithOptions function in the App Delegate. It can be used like so: `if let payload: [AnyHashable: Any] = launchOptions?[UIApplicationLaunchOptionsKey.remoteNotification] as? [AnyHashable : Any] { //Do stuff with payload here... }` – davidrynn Dec 16 '16 at 19:12
  • @davidrynn Of course. But that's not what OP wants. He wants to get the payload without *any* input from the user. – Quentin Hayot Dec 17 '16 at 04:36
  • True - but the first line of your answer is "You can't get a notification's payload if your app is killed." Which is not correct. Otherwise, yeah he's not getting any payload without tapping the banner unless the app is in the foreground. – davidrynn Dec 19 '16 at 15:37
  • 1
    Tapping the notification starts your app then transmit the payload. You don't get the payload while your app is killed ;) – Quentin Hayot Dec 19 '16 at 16:11
  • @QuentinHayot, you're totally right. My bad. Don't know why I was being stubborn and not reading correctly. Would delete my response but I'll leave it here to document my shame. ;) – davidrynn Nov 30 '17 at 15:52