Many mobile applications include WKWebView, which embeds web pages into an application as if they were written native to mobile. These views are fetched through a network call, so historically, they have been a black box for developers: They might see the call made to request the page’s information but they don’t know what happened to actually produce the page.

Not knowing that process can be either slightly inconvenient or absolutely infuriating for a developer. That’s because these webviews can range from inconsequential to absolutely essential.

For example, one application might include a webview that simply displays a small bit of text—something easily written natively. In contrast, an e-commerce application could house an absolutely critical process, such as a payment flow, in a webview.

Even if a webview seems minor, it can be extremely taxing for an application.

Each webview is a separate process, meaning it might prompt a watchdog termination. A user might switch activities or views and have a webview still running, taking up valuable resources. Or, worse, the user might background an application and the application might be terminated because of a webview that is still running.

Web tracking and network monitoring might help with some of these errors, but what happens when a page loads but is blank?

Imagine if this happened every time a user wanted to pay for their items. You’d make a profit of absolutely zero!

These blank webviews can occur for multiple reasons. The JavaScript or image data might use too much memory or there might be a logic error, both of which would cause a crash. In essence, just as a single tab crashing in the Chrome browser will not crash the entire browser, one crash in a single WKWebView will not crash the entire application. Instead, only that specific webview will crash.

Luckily, this issue is easily identifiable and solvable with Embrace.

Embrace will provide a webViewWebContentProcessDidTerminate implementation on all WKWebView instances in your app. With the default configuration, our SDK will automatically log any instances of a termination alongside the rest of a user’s session data.

However, if you’ve predicted the possibility of a crash and have already implemented webViewWebContentProcessDidTerminate, then our SDK will call your implementation so your application can recover and the view can refresh.

Even if you’ve yet to implement this method, you can enable a new Auto-Reload flag in your configuration file to benefit from this feature as well.

Enabling this means that your crashed pages will automatically refresh, preserving your user experience. And, logging these instances means you can optimize how you implement your webviews and with Embrace, track your improvements over time.

That’s just one of the features that makes Embrace the best-in-class mobile platform.

Who we are

Embrace is a data driven toolset to help mobile engineers build better experiences. If you’d like to learn more about Embrace, you can check out our website or request a demo.