[Bug]: [ios] Some Native -> JS messages appear to drop after extended time with app in background

[gabeschine]

Capacitor Version

💊 Capacitor Doctor 💊

Latest Dependencies:

@capacitor/cli: 6.2.0
@capacitor/core: 6.2.0
@capacitor/android: 6.2.0
@capacitor/ios: 6.2.0

Installed Dependencies:

@capacitor/android: not installed
@capacitor/core: 6.2.0
@capacitor/ios: 6.2.0
@capacitor/cli: 6.2.0

[success] iOS looking great! 👌

Other API Details

yarn --version: 1.22.11
node --version: v20.10.0

Platforms Affected

• iOS
• Android
• Web

Current Behavior

If a Capacitor app is backgrounded for a long time, and during this time a notification is delivered to the device and clicked or a deeplink open request is received, when the app is foregrounded the relevant message (either the notification payload from a plugin like @capacitor/push-notifications or the appUrlOpen event from @capacitor/app) is sometimes dropped.

In the field when this occurs, we observe the app's web view reload immediately upon foregrounding.

In testing, it is possible to reproduce the behavior, and it appears to be tied to the timing of iOS notifying the native app through webViewWebContentProcessDidTerminate [1]: if the notification happens immediately, messages are delivered successfully; if the notification is delayed until the app is foregrounded, the messages are not delivered.

[1] https://developer.apple.com/documentation/webkit/wknavigationdelegate/webviewwebcontentprocessdidterminate(_:)

Expected Behavior

The messages are delivered in all scenarios.

Project Reproduction

https://github.com/watch-duty/capacitor-message-bug-repro

Additional Information

The reproduction is not a perfect mirror of what happens in production.

In production: it appears that iOS is killing the WebContent process on its own. Based on reading this can happen to reduce memory pressure or other resource pressure, or based on other conditions unknown to me.

In the reproduction: killing the WebContent process is performed explicitly, since it is impossible to deterministically trigger the same resource pressure conditions encountered in production.

The reproduction is assuming that while the trigger is different, the subsequent symptoms and bug mechanism are shared. Based on many, many user reports of the bug, and associated data gather that we have performed, this appears to be a sound assumption.

[davidemerritt]

+1 here - this reflects what I've seen in our application as well, affecting push notification handling.