WebKit, Safari and SafariViewController

iOS and web have been always hand-by-hand since the iOS inception. After all, websites were already 15 years old when iOS saw the light (the first website ever created dates back to 1991 and iOS was presented in 2007). There was already so much web content when the iPhone came out, that iOS had to offer a way to show it.

In iOS 9, we have different options to render web content and depending on the specific needs, developers can evaluate the different options and choose the one that fits them better. Let’s take a look at the different solution that a developer can adopt.


WebKit is the layout and rendering engine behind Safari on OS X and iOS. It allows to parse and render html, load and display images, and execute JavaScript.

The UIWebView class was introduced in iOS 2 and is part of UIKit. It has been widely used, and for quite a long time, UIWebView was the only tool available to embed web content in an iOS app.

Then, in iOS 8 Apple introduced WKWebView as a replacement of UIWebView on iOS and WebView on OS X. The new APIs brought exactly the same functionality to both platforms, streamlined communication between Apps and webpage and multi-process architecture also used in Safari.

WKWebView provides many features that were previously only available to Safari. It provides a 60fps responsive scrolling using hardware acceleration and Core Animation, fast JavaScript, and built-in gestures like back-forward swipe and zoom gestures from Safari. One of the major improvements over UIWebView is the ease app-webpage communication, how interaction and data can be passed back and forth between an App and its web content.

WKWebView is pretty easy to adopt. Here, the Swift lines of code that demonstrates that:

Here, the Objective-C version:

Line 1 defines the frame of the webView instantiated in line 2. Line 3 creates and returns an URL structure (an object in Objective-C) initialized with the URL string provided. Line 4 creates and returns a URL request. In line 5, the web view loads the URL request. Finally, line 6 adds the web view to the view controller’s view.

Here is the result of running the code above:


WKWebView is a view of web content that allows Javascript and html rendering. You can add your own back button, forward button and progress indicator. Starting with iOS 9, you can additionally securely load file url’s and data.

WKWebsiteDataStore introduced in iOS 9 and OS X 10.11 is a new API that manages the data stored by a website, like cookies. It’s a read-write property on your web view’s WKWebViewConfiguration. You can delete data by type, like cookies and cache, or by date. You can change configuration to use a non-persistent data store.

WKWebView offers a lot of features and you should go for this tool if you own the web content and need to customize it, like JavaScript evaluation against the page.

However, if you just need to show web content, then you should use either Safari or the new SFSafariViewController. Let’s see both of these options.


Using Safari allows you to delegate the responsibility of rendering web content to Safari. In this way, you also write less code than when using a WKWebView.

To launch Safari from your application, you call openURL: method on UIApplication and iOS brings Safari in foreground sending your app in background.

A new iOS 9 feature allows the user to go back to your app through a back button that automatically appears in the top-left corner of the user interface (see A in the image below).

This is an easy solution for developers to provide the same great user experience offered by Safari. Next picture highlight the UI components (see B and C in the following picture) you get for free.


Here some sample code to show you how to launch Safari from your app delegating it the rendering of some web content:

Here the same source code in Objective-C:

Safari View Controller

Let’s take a look at SFSafariViewController. This class has been introduced in iOS 9. Using SFSafariViewController, Safari is embedded in you application and the user never leaves your app.

Safari ViewController eliminates distractions, turning the URL field to be read-only (see D in the image below) and a Done button to go right back to your app (see E in the image).

Here, some sample code to show you how to offer web content to your user through SafariViewController.

Let’s see the implementation in Swift:

And now, the same thing in Objective-C:

The code above, will result in something similar to the image below:


Now, let’s break down the features that SafariViewController has to offer when you use it in your app:

A familiar user interface

SafariViewController offers the same interface than Safari, allowing you to seamlessly integrate it in your app by even respecting the tint color of your app. You will find the same sharing options offered by Safari, where the user can add the webpage to the reading list or send the page to a friend (see F in the image below). Additionally, the developer can also provides activities adding a dedicated button to the action sheet.


Password, Credit Card and Contact Card AutoFill

SFSafariViewController allows users to AutoFill sensitive information and credentials securely from their iCloud keychain. This includes filling in passwords, credit cards and contact information.

Cookies shared with Safari

Cookies are shared between Safari and SFSafariViewController which means that user sessions and preferences persist between the two. Authorizing an app to access Twitter or Facebook, for example, will be a streamlined experience if the user is already signed in with Safari or if their passwords are stored in iCloud Keychain.

Safari Reader

The safari reader button will allow the user to show an easy-to-read version of the website, offering themes and fonts for the user to choose from.

Content Blocking

Starting with iOS 9, any app can write a description of web content that Safari and Safari ViewController blocks as the user browses the web. Additionally, a user can also add content blocking elements in settings. Those elements will be then blocked and not shown to the user. This means that an app showing web content using either Safari or Safari ViewController will be affected by the content blocking elements selected by the user and by the developer. Content blocking elements can be a single element on a page or block loads, like all images or scripts from a page.


When showing web content in your app, you have different options to choose from and it’s up to you to choose the one that fits your needs. WKWebView, introduced in iOS 8, gives you the most flexibility if you need to modify or manipulate the web content. Launching Safari from your app will give the user the same great experience that Safari offers, but your users might not come back to your app. SFSafariViewController is like embedding Safari in your app and is very easy to adopt.

Happy browsing!


Eva Diaz-Santana (@evdiasan) is cofounder of InvasiveCode. She develops iOS applications and teaches iOS development since 2008. She also worked at Apple as Cocoa Architect and UX designer.



(Visited 1,136 times, 2 visits today)