3 options to open web content in app

1. UIWebView (deprecated on iOS 8)

2. WKWebView (entered on iOS 8)

3. SFSafariViewController (entered on iOS 9)

Quick Comparison

Recommandations

1. Use WKWebView as the default browser if your app implements customize behavior (UI or “behind the scene”).

2. Use SFSafariViewController as the default browser if your app wants to present a webpage without any customization.

3. If your app supports iOS < 8.0 make sure your app open the best performing browser available. See example in

   if (SYSTEM_VERSION_LESS_THAN(@"8.0")) {
       self.webView = [[UIWebView alloc] initWithFrame:frame];
       self.webView.scalesPageToFit = YES;
       [self.webView setTranslatesAutoresizingMaskIntoConstraints: NO];
       self.webView.delegate = self;
       // Fast scrolling
       self.webView.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
       [self.view addSubview:self.webView];
   }
   else {
       self.wk_WebView = [[WKWebView alloc] initWithFrame:frame];
       self.wk_WebView.navigationDelegate = self;
       [self.view addSubview:self.wk_WebView];
    }
   

UIWebView

1. Apple legacy in-app Webview

2. According to Apple: “In apps that run in iOS 8 and later, use the WKWebView class instead of using UIWebView.”

3. Should be used only in apps that supports iOS < 8.0 and even than, the best practice is to detect the OS version in runtime and if the version is 8.0 or more – open the web content in WKWebView.

WKWebView

1. The in-app webview recommended by Apple for apps that have needs to customize the web-browsing behaviour in either UI\UX aspects or functionality aspects (such as, send ping to the app server when page finished loading).

2. Supports Nitro engine which is a big deal (much faster rendering)

3. From internal tests, WKWebview is 25%-30% faster than UIWebview.

4. Overall performance is much better (See http://blog.initlabs.com/post/100113463211/wkwebview-vs-uiwebview)

SFSafariViewController

1. Released together with iOS 9.0

2. Essentially acts as a Safari instance which belongs (part of) the container app.

3. From Apple docs: “The SFSafariViewController class provides a standard interface for browsing the web. The view controller includes Safari features such as Reader, AutoFill, Fraudulent Website Detection, and content blocking. It shares cookies and other website data with Safari. The user’s activity and interaction with SFSafariViewController are not visible to your app, which cannot access AutoFill data, browsing history, or website data. You do not need to secure data between your app and Safari.”

4. In terms of functionality, the developer can not manipulate or be informed on anything that happens inside the browser except for the original URL which opens in the browser.

5. Apple pushing developers towards this implementation even though they are aware of the drawbacks.

6. Cookies are synced with Safari app