How do I test if my app is restarted correctly when receiving push notifications?

Question

Created Sep ’24

Replies 3

Boosts 0

Participants 3

To receive silent push notifications in the background, I need to include content-available payload into my APNS push notification, and have application(_:didReceiveRemoteNotification:fetchCompletionHandler:) implemented.

When I send a push notification, my app receives and handles it with the above method.

This works correctly and is straightforward to test when the app is running in foreground or background on my device.

I would like to test if my app is woken up correctly from scratch and does the above work. But how do I do this? How do I get my app into the state where it is started when it receives a silent push notification?

When the user force-kills the app, the notification is not delivered. This is also the case when I as a developer force-kill the app which I am testing. I assume it also applies when I force-stop the app running on my device from within Xcode.

Is there any way for me as a developer to terminate the app, which does not count as “force killing”, and would reliably start the app when it receives the background notification?

Answered by Engineer in 806069022

Stopping the app from Xcode does not count as force closed.

As much as I hate to recommend it, alternatively you could call exit(0) from a button that will terminate the app without counting as force closed. Just make sure you don't ship your app with that code in it.

Also, if your app were to crash, that would also not be count as force closed.

But as for "reliably" launching the app for testing purposes, unfortunately there isn't a way to guarantee that.

If you want to know what happens when the app is launched due to a notification, you will see application(_:willFinishLaunchingWithOptions:) and application(_:didFinishLaunchingWithOptions:) called before application(_:didReceiveRemoteNotification:fetchCompletionHandler:)

So perhaps you can simulate a launch by mocking the calls to the code which gets called from those functions.

Argun Tekant /  DTS Engineer / Core Technologies

Boost

Answer 1

Engineer OP

Apple

Sep ’24

Accepted Answer

Stopping the app from Xcode does not count as force closed.

As much as I hate to recommend it, alternatively you could call exit(0) from a button that will terminate the app without counting as force closed. Just make sure you don't ship your app with that code in it.

Also, if your app were to crash, that would also not be count as force closed.

But as for "reliably" launching the app for testing purposes, unfortunately there isn't a way to guarantee that.

If you want to know what happens when the app is launched due to a notification, you will see application(_:willFinishLaunchingWithOptions:) and application(_:didFinishLaunchingWithOptions:) called before application(_:didReceiveRemoteNotification:fetchCompletionHandler:)

So perhaps you can simulate a launch by mocking the calls to the code which gets called from those functions.

Argun Tekant /  DTS Engineer / Core Technologies

1

Answer 2

Jaanus OP

Sep ’24

Thank you. Indeed, I now see "didReceiveRemoteNotification” called reasonably reliably for a background notification, and the app started from scratch, after I have killed the app from Xcode debug session.

0

Answer 3

DTS Engineer OP

Apple

Sep ’24

As much as I hate to recommend it, alternatively you could call exit(0) from a button that will terminate the app without counting as force closed. Just make sure you don't ship your app with that code in it

Two other tools/techniques that can be useful when testing this sort of thing:

In "Settings.app-> Developer", one of the options in the list is "State Restoration Testing-> Fast App Termination". As the UI describes, turning that on causes the system to terminate development apps at the point they would normally have suspended. This is primarily intended to simplify state restoration testing, but it can also be useful for this kind of testing.
You can also use memory usage to force yourself out of memory by intentionally allocating memory until the system terminates you. This shouldn't behave any differently than calling exit(0), but it does simulate a more natural/common scenario.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1