iOS: webViewWebContentProcessDidTerminate and the value of UIApplication.shared.applicationState

[KevinKelchen]

Hi All, 👋

I was hoping perhaps someone here could help answer a question that I have. 😀

What we're trying to do and why

Somewhat in the spirit of this feature request, we are trying to detect if the iOS WebView involuntarily reloaded in our app. Specifically, we'd like to know if the WebView reloaded while the app was not minimized/is actively being used. We are going to log these involuntary reload events to our error tracking service (Sentry) to learn more about our app's stability.

Currently, we have everything implemented except for the part where we only log the involuntary reload if the app was not minimized at the time the WebView process was terminated. In summary, here's how we've implemented what we have so far:

• Using patch-package, we've edited node_modules/@capacitor/ios/Capacitor/Capacitor/WebViewDelegationHandler.swift
  • In the method webViewWebContentProcessDidTerminate(), we've added code before the WebView reload to set a flag in native app memory indicating that the WebView reloaded. (Native app memory will persist across the WebView reload.)
• We've created a project-local Capacitor plugin that, during web app startup in JavaScript, will call into the native layer and read the reload flag from native app memory. If the WebView involuntarily reloaded, it will log the event to the error tracking service. It will then reset the flag in native app memory.

That by itself gets us pretty far. However, the error logging will include situations in which the app was backgrounded/minimized and the WebView process was terminated but the entire native app process itself is still alive. In this case, when bringing the app to the foreground again, webViewWebContentProcessDidTerminate() gets invoked immediately which logs the event to the error tracking service.

We don't want to log when the WebView was terminated in the background because what we really care about is if a user is actively using the app and the WebView crashes. That's disruptive/jarring, they lose their in-memory state/data, etc. We think that users can expect that if the app is backgrounded, all bets are off on whether the app will "restart" (or in this case, the WebView will reload) when they bring it back to the foreground. We wouldn't classify that as a "crash" but typical of native app/OS behavior. So that's why we want to differentiate it. 🙂

Potential solution

We're investigating using native iOS app state events to detect if the app was in the foreground during the reload.

Some relevant resources if you want to go deeper on iOS app lifecycle:

• https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle
• https://medium.com/@chinthaka01/the-execution-states-of-an-ios-application-84e117132e27
• https://medium.com/@charlesmuchene/hooking-into-apps-lifecycle-events-ios-ef433cefdbce
• https://developer.apple.com/documentation/uikit/uiapplication/1623003-applicationstate
• https://developer.apple.com/documentation/uikit/uiapplicationdelegate#topics

At the time of writing, we're thinking of checking UIApplication.shared.applicationState when webViewWebContentProcessDidTerminate() is invoked so that we only flip the involuntary reload flag in native app memory if the app is in the active state.

The thing we need to be sensitive to is that when a WebView background termination occurs, webViewWebContentProcessDidTerminate() is invoked when the app is coming back into the foreground and will imminently become active. We'd need to have confidence that at the time webViewWebContentProcessDidTerminate() is invoked while the app is resuming, the app is not yet set to active.

The big questions

Do we know the relationship between the timing of when webViewWebContentProcessDidTerminate() is invoked and the value of UIApplication.shared.applicationState? In webViewWebContentProcessDidTerminate(), will UIApplication.shared.applicationState ever be active when bringing the app into the foreground after a WebView background termination?

I realize it might be a shot in the dark if anyone actually knows the answer to this. 😅 Searching online didn't turn up an answer, and we haven't found official documentation from Apple about it (which is kind of expected though).

We want to make sure our solution is reliable and does not give us "false positives" where we log an involuntary reload occurrence that we wanted to ignore. 🙂 Thus far from our testing this approach seems reliable, and since we don't know of a better solution at this time we're planning to use it.

Final thoughts

I greatly appreciate any effort involved in reading this discussion or helping answer the questions! Thanks so much for your time! 😀

Take care,

Kevin

[silviogutierrez]

@KevinKelchen : super helpful. In my case, I actually have the opposite problem. I don't run into crashes, but it does seem like the web view gets shut down when the app is in the background. My app isn't very heavy, uses no media, etc. But it seems like other app usage / resource constraints can cause iOS to shut down my web view.

This may not seem like a big issue, but consider that some apps "count" on being started in a particular path / route. When the web view reloads, it reloads with the current path at the time, not the "root" path. This can cause some issues. Why does my app not support loading other paths? Because 99% of my routes require external data but I specifically made sure the root view requires no connectivity or data so that it loads immediately and quickly.

Just food for thought. Maybe the best we can do for now is clearly highlight that the web view is ephemeral and can be reloaded at any time — plan and build to handle those situations.

[KevinKelchen]

You're welcome! 😀

In the earlier years of our Ionic Angular application, the frontend web app was only designed to be loaded at the root URL.

While this simplified app bootstrapping/startup, we found that the ionic serve live reload was flaky. We kind of put up with it.

However, once we had our sights set on deploying the frontend web app as a regular web app accessible via the web browser, we knew we had to add "reload resiliency" to be able to properly bootstrap the app from any app URL. So we invested in that and are glad we did. 🙂 FWIW, anyway.

Take care,

Kevin

[silviogutierrez]

Good point, and I'm actually fanatical about URLs behaving properly and remember state. And my app is also available on the web. But by definition, being on the web implies network connectivity, so you can get away with relying on it (web workers / offline mode aside).

Not so with the native web view. So yea, even though the app works fine and is resilient to reloading, it's still not the best experience on native. I suppose I could make all views "assume you may not be able to load data". But that's a step too far for such an edge case.

[esam12]

Has anyone been able to find the solution?
#flutter #ios

[mengqutaoyuan]

I encountered the same problem when developing flutter web. Do you have a solution?

[Ibni-Amin]

facing the same issue in ios capacitor ionic usinng angular
2024-02-20 12:59:13.908698+0500 App[11185:1708847] [Process] 0x111001560 - [PID=11190] WebProcessProxy::didClose: (web process 0 crash) 2024-02-20 12:59:13.908838+0500 App[11185:1708847] [Process] 0x111001560 - [PID=11190] WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=Crash 2024-02-20 12:59:13.914284+0500 App[11185:1708847] [Process] 0x156031018 - [pageProxyID=8, webPageID=9, PID=11190] WebPageProxy::processDidTerminate: (pid 11190), reason=Crash 2024-02-20 12:59:13.925588+0500 App[11185:1708847] [Loading] 0x156031018 - [pageProxyID=8, webPageID=9, PID=11190] WebPageProxy::dispatchProcessDidTerminate: reason=Crash