The Apple iOS 9 Reviewby Brandon Chester on September 16, 2015 8:00 AM EST
Deep linking takes care of the situations where a link in an application redirects to Safari. However, there are other ways that developers can handle links in their applications. The other major method is one you’ll find in apps like Skype and Facebook, and it’s basically a mini web browser built inside the application. These built in web browsers traditionally used UIKit’s UIWebView class, which was subject to performance constraints when compared to mobile Safari. iOS 8 introduced the WKWebView class which was just as fast as Safari, but had some issues of its own that made it difficult to implement in many situations. While iOS 9 fixes many of the issues with WKWebView, such as lack of support for loading local files with the file://URL protocol, it also comes with a much better method for developers to handle the transition from their app to Safari. This new feature is called the Safari View Controller.
The main reason for Safari View Controller’s existence is to provide a better user experience than the existing miniature web browsers that applications have built in to them to handle web links. When an application handles the rendering of web pages on its own, the user loses access to many features of Safari like their password keychain, their stored credit card info, their cookies, and more. The obvious solution to this is to just use Safari, but that has traditionally come with the cost of moving the user out of their current application. This is certainly improved with the addition of the back link in iOS 9, but it would be much better if those mini web browsers could just be replaced by Safari running inside of an application. That’s essentially what Safari View Controller is.
When an application uses Safari View Controller to handle web content, the user will be presented with the interface above after clicking on a link. It’s very similar to Safari’s interface, but with a few alterations to let the user know what has happened. For starters, there’s a button in the upper right that says “Done”, which is a fairly obvious control to return to the application. The URL bar at the top is also greyed out, which indicates that you can’t change it. If you do want to start surfing the web, there’s a button in the bottom right to open the actual Safari application. Developers can also specify a custom tint color for the UI so users remember what application they’re working within.
While Safari View Controller gives the user access to all of their data like passwords, credit cards, and cookies, none of this information is provided to the host application. This is because Safari View Controller is actually running in a completely separate sandboxed application, which means that users don’t have to worry about the security of what they input or where they visit. This is also helpful for developers who don’t want to deal with the privacy implications of having users input into their own built in mini browser. What’s also useful for both developers and users is the ability to specify custom options in the Safari View Controller share sheet, such as a button that can share the current web page to a social network or to a contact via an instant message.
Since applications haven’t taken advantage of Safari View Controller yet it’s difficult to really communicate the advantages it provides. However, I think everyone can appreciate the improved user experience that comes with having access to all your web browser content in a safe and secure manner within any application. Since Safari View Controller also makes a developer’s life a lot easier by taking away the need to build a mini web browser UI, I think it will see significant and speedy adoption among new and existing applications.
Safari Content Blockers are extensions that provide Safari with a list of rules which defines content or resources on webpages that should not be shown or even loaded. The list of rules is written in JSON, and the syntax is simple enough that it really wouldn't be that difficult for most people to figure out how to make their own Content Blocker on their own. Having a relatively user-friendly syntax is also important because iOS 9 now allows you to sideload applications and extensions without having to pay the yearly $99 for an iOS developer account so long as you're compiling from source. This means that users can write and install their own Content Blocker with Xcode, or download and install an open source one from the web.
Pretend that you're reading AnandTech, and you're really annoyed at the Twitter sidebar on the right for whatever reason. You decide to write a Content Blocker to remove it, and the code for that blocker is what's shown in the Xcode project window above. As you can see, it's fairly readable code. The action applies the css-display-none attribute to page elements matching the selector, which is article.twitter in this case. For the trigger section we have the url-filter set to .* which means anything, as we want to indiscriminately eradicate every part of the Twitter feed. To make sure it doesn't affect content on other sites we tell it to only apply if the domain matches AnandTech.com or any of its subdomains.
Once you install an application that provides a Content Blocking extension, a new Content Blocker menu will appear in the Safari section of the settings app. In that menu you can enable or disable the Content Blockers that exist on your device. There's not much more to it once you enable the Content Blocker. If you were to install this and load any page on AnandTech the Twitter sidebar would be completely gone. It's worth noting that Content Blockers can only be installed on ARMv8 devices, which limits it to any device with Apple's A7, A8, or A8X SoCs.
The most shocking thing of all is the reduction in network traffic. With no ads firing trackers your network requests end when the page loads. Without the Content Blockers you can see that the network requests continue. The results vary, but I've seen it go as long as 25 seconds. Those 25 seconds are a period where your data is being used, and your radio is actively in use which is draining your battery without you even knowing it.
Like I said before, I'm not going to take a stance for or against adblocking. I will say that as a user, one never really gives explicit permission to be tracked, and it's just implied by your use of a service which makes it less clear to the user what exactly they're consenting to. I'll also say that the ad experience on the web is nothing short of terrible. If ad blocking becomes a big thing in mobile the publishers and ad networks are going to have to fix the intrusiveness and slowness of ads, or move inside applications like Apple News where another company that does know how to implement them in a user friendly manner can do it for them.