Custom scheme handling and WKWebview in iOS 11

Thomas Ricouard
Aug 24, 2017 · 3 min read

Apple wanted everyone to migrate from the perfectly fine UIWebview to the new WKWebView when they released it as a part of the iOS 8 SDK.

There is even a “beautiful” warning message, and it’s been there for 4 years now… Well, you know what? Most apps still use UIWebView, because it’s simple to use and do the job. But, you should really migrate to the WKWebView, because it’s backed directly by the WebKit framework, it have more features, and it use a faster javascript engine.

At Glose books, as part of our reader, we extensively use UIWebView, even if it’s extremely custom and fuse native and web interactions and UI. Yes, the new Javascript bridge (called WKScriptMessageHandler) is one of the most wonderful thing of the WKWebView. The core content of a book is still in HTML format. So it makes sense to use a browser view(be it a UIWebView or anything else) to display it. In the current version of our application, our reader still run on UIWebview (shame, shame, shame), because at the time, it was the only solution available.

In our in development version, we’ve made a totally new mobile reader, and this time it’s based on WKWebView. Why did it took us so long? Because until the iOS 11 SDK there was no way to handle custom url scheme loading with a WKWebView. There were still so many advantages of using WKWebView, but the custom scheme loading was a total blocker.

UIWebView support custom NSURLProtocol, it means that in order to provide a custom way to load a custom url scheme, you simply had to create a subclass of NSURLProtocol and then register your class with NSURLProtocol. Then anything calling your custom scheme (like helloworld://) would invoke your custom NSURLProtocol class. Then you’re responsible for loading and forwarding your content. This is very powerful, and in our case we use it to load various assets within a book, such as images, videos etc… So a total no go if we can’t do that. There is a lot of workaround we could have used, but they were mostly hacks, and not really ok for a production application.

WKWebview doesn’t support custom NSURLProtocol, so you can register any classes you want, it’ll never be called because of a WKWebView requests. Well REJOICE ! In iOS 11 Apple added WKURLSchemeHandler. It works almost the same as NSURLProtocol!

Here is some code example for you to understand, because let’s be honest, you don’t really care about all the bullshit above :)

So first you create your WKURLSchemeHandler subclass, you have to implement the two methods, start and stop. Only the start method is relevant, because this is where you are going to do the work.

The stop method can be left empty, or used for you to do any necessary cleanup.

You have access to the full request, so you can check, extract anything from the url, load your necessary data and forward them to the WKWebView. Your content should then load.

And after your class is created, you have to register it with the WKWebView, and you have to do that when you create its configuration:

You’re all set, now you’re ready to load any custom content in your WKWebView!

Glose Engineering

Stories from the Glose team

)

Thomas Ricouard

Written by

📱 🚀 🇫🇷 [Entrepreneur, iOS/Mac & Web dev] | Now @glose 📖 | Past @google 🔍 | Co-founded few companies before, a movies 🎥 app and smart browser one.

Glose Engineering

Stories from the Glose team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade