iOS: Push notifications do not wake the app in the background

[arosiclair]

Version Number: N/A Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: N/A Expensify/Expensify Issue URL: N/A Issue reported by: @arosiclair Slack conversation: N/A

Action Performed:

1. Log in on iOS
2. Accept push notification prompt
3. Kill the app
4. Send yourself a message
5. Verify a push notification appears
6. View logs

Expected Result:

Logs show the app wake in the background and process the push notification

Actual Result:

The app never appears to run in the background and the push notification is only processed once the app re-opens.

Workaround:

N/A

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [x] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @arosiclair

[melvin-bot[bot]]

Triggered auto assignment to @twisterdotcom (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[twisterdotcom]

Is this in your queue to handle @arosiclair?

[arosiclair]

Yes no progress atm. I might get to it this week.

[melvin-bot[bot]]

@arosiclair @twisterdotcom this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[twisterdotcom]

Shall we make it Monthly?

[arosiclair]

I'll leave the priority up to you @twisterdotcom. My plate's full with #fast-apis and #wave-collect issues atm so I'll unassign and free this up. If it hasn't been worked on I'll get back to it when I can.

[melvin-bot[bot]]

Triggered auto assignment to @rlinoz (AutoAssignerNewDotQuality)

[rlinoz]

Will order an iPhone by tomorrow so I can test this.

[Julesssss]

This is just a guess, but it's possible that we've once again started dropping the onyx payload in the backend, which means that the Onyx data isn't being applied to the DM.

This happens when the payload exceeds 3.5kb.

Edit: Probably not, iOS only...

[twisterdotcom]

Any updates here?

[rlinoz]

I've been focused in finishing Export CSV, I will try to get to this one next week.

[muttmuure]

@rlinoz are you still able to work on this, this week?

[rlinoz]

I'm spending more time than I expected with some chores and won't be able to get to it this week, so I will unassign for now

[twisterdotcom]

Asking for some help: https://expensify.slack.com/archives/C05LX9D6E07/p1722599601478899

[chrispader]

Hey, I am Chris from Margelo, an expert agency and I can work on this issue.

[Julesssss]

Hey, I am Chris from Margelo, an expert agency and I can work on this issue.

Sounds good 👍 Has anyone got you set up with Apple certs/profiles previously?

[twisterdotcom]

Bump @chrispader and @arosiclair

[twisterdotcom]

Okay, should we close as not a priority?

[chrispader]

@arosiclair is going to work on this, because unfortunately i cannot receive push notifications on dev builds. This has to be handled by an internal engineer.

[melvin-bot[bot]]

@arosiclair, @twisterdotcom, @chrispader Whoops! This issue is 2 days overdue. Let's get this updated quick!

[arosiclair]

Well I'm in Savannah and Metro doesn't connect to my iPhone anymore for some reason so I cannot debug this atm. Unfortunately I think this is going to have to wait until I get back next week.

[melvin-bot[bot]]

@arosiclair, @twisterdotcom Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[arosiclair]

Back home and did some testing today.

• Background refresh still doesn't work in dev for me with the latest changes
• I tested in staging on my iPhone and that doesn't seem to work either according to log search
  • I left a minute or two between receiving a background notification and then opening the app and found logs for processing the notification only appeared with timestamps after the app was re-opened
• Playing around with the place/timing of subscribing push notifications to see if that has an effect. No success yet.

I'm going to continue experimenting with how we subscribe notifications and possibly reach out to Ryan at Airship. Another thing to note is that we're upgrading the Airship library from v17 to v19 soon in this PR so this might get fixed by that.

[muttmuure]

thanks for the update!

[melvin-bot[bot]]

@arosiclair, @twisterdotcom Whoops! This issue is 2 days overdue. Let's get this updated quick!

[arosiclair]

My testing steps in the past were to

1. Kill the app from task switcher
2. Receive push notification
3. Watch logs in metro

However according to this thread, that is not supposed to work:

However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.

So it seems like my test steps worked previously as a "bug" and were fixed at some point (this SO seems to corroborate that experience). According to Ryan from Airship, we should be able to test this by stopping the app through Xcode or rebooting the phone instead, but I'm not having any luck with that either.

I think all we can do is conclude that background notifications are configured correctly (we have the background mode for remote notifications enabled and we are setting content_available in iOS push notification payloads), but Apple doesn't provide any reliable mechanism to test it in dev or production. So with that I'll close out this issue.

[muttmuure]

thanks for the persistent investigations here!