If you would prefer to watch a video instead, you can check it out below!

At Embrace, we help mobile companies solve their most difficult production issues. In this series, we’ll cover interesting bugs that mobile developers might come across, and we’ll provide tips and tricks for finding and fixing them.

Blank WebViews

Here’s a screenshot from one of our partner’s mobile apps.

The cursed white screen of a blank webview

There should be content in those web views, but instead, there’s just a white screen. You might have experienced this in your own applications and can probably guess why it occurred. Maybe the JavaScript didn’t load or the CSS isn’t set up correctly. There could be a number of reasons why this happened, but the interesting thing is that a web view crashing doesn’t cause the application itself to crash. Why is that?

The iOS process model

On iOS, most applications have one and only one process. You have a main thread, and you can spawn other threads to do background work like networking tasks or rendering. But on the whole, your application is running in a single process.

This allows the operating system to better manage resources. If your application is using too much memory, your application can be suspended or terminated to free up resources for other applications on the system. But this changes when you introduce WebKit into your app.

WKWebView actually uses a multi-process model to render its pages, just like the Safari app does on your desktop.

Each tab or each page of WKWebView in your application is backed by two additional processes: a content process and a networking process. So if you have an application with one web view in it, your application is actually running on three operating system processes: the application process, the web content process, and the web networking process. All three of those processes can be independently suspended or terminated depending on what’s going on. For example, if you have a web view in your app that is running a lot of JavaScript, loading a lot of heavy images, or doing heavy processing, that process can be killed independent of your application process.

What this means is your user could be using your application to check out items from your store or read comments on a forum, and all of a sudden all of those items or comments just disappear. This can be incredibly frustrating for your users as it doesn’t crash your application. To your user it looks like your app is still running but the content just disappeared. This is kind of the worst case scenario, so how can you avoid this?

The solution

Luckily, Apple thought about this and provides an API on WKWebView to handle blank web views. First, you should be implementing WKNavigationDelegate, which is a navigation delegate that provides a series of callbacks that can help you manage what’s going on with the content on your web views. You’ll know when the load started, when the load stopped, if your user clicks any links on the page, etc. But there’s an extra method on here that you probably have never looked at or implemented and that is webViewWebContentProcessDidTerminate.

If you implement that callback, the system will tell you when the content process of any of your web views is killed, and you’ll have a chance to react to that event. Sometimes you may decide to hide that web view if it’s an advertisement or something that you’re not able to fix yourself. But if it’s your storefront or your checkout page, you can reload the page because chances are your user was trying to do something and would like to continue doing their work. By simply reloading the page, they can keep going and often that is the best solution.

Summing it all up

In this post, we covered blank web views on iOS applications. They occur when web views fail or are killed by the OS. Normally, a process being killed would crash the application, but on iOS, WKWebViews have two additional processes: a content process and a networking process. These can be killed without affecting the main application process. You can provide a better user experience by deciding which web views should be reloaded upon failure and adding this functionality through the webViewWebContentProcessDidTerminate callback on WKNavigationDelegate.

We hope you found this post helpful and are empowered to take action on how your application responds to blank web views going foward.

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.