Ad blocking on iOS has been a hot topic recently because new features in iOS 9 allow third-party apps to block ads in Safari. The implications for publishers are huge: some have even declared this move the beginning of the “slow death of the web”, since ubiquitous use of ad blocking would kill the dominant revenue stream for many websites.
Ad-blocking on iOS 9
However, Safari isn’t the only way to view web content on an iOS device. A link clicked inside of Twitter or Facebook, for example, will open up a mini-browser inside that app called a ‘WebView’, rather than the opening the site externally in the Safari. In addition to WebViews, there are third party browsers, like Chrome, that can be downloaded and used as the primary web browser instead of Safari.
Another announcement that makes this interesting is Google’s ‘AMP HTML’, an open-source technology similar to Facebook’s Instant Articles: faster-loading, more engaging pages built specifically for publishers and their content requirements. These pages limit ad blocking by not only allowing but encouraging performant ads specific to the platform. This does mean, however, that publishers will have to invest more into exploratory technical efforts and are once again at the mercy of the platforms that host them. The pros and cons can be enumerated endlessly.
What’s at stake as things stand today? Simply put, if a majority of links are opened not in Safari, but in WebViews, then ad blocking for Safari on iOS 9 is significantly less worrying than it has been made out to be. If the reverse is true, then people should fear the rise of the ad blocker and should invest in native experiences such as AMP and Instant Articles to diversify their content views and de-risk their revenue stream.
Where are link clicks taking place?
This data is a sample of browsers we see for Branch link clicks on iOS 9 devices. We believe that where links are being clicked is a decent proxy for how much traffic is driven into a given browser. It does not take into account time within the browser.
Figure 1. Branch link clicks by browser on iOS 9
The only one that isn’t a household name is Webkit, which is the default name for most in-app browsers, such as those in Twitter and Slack. For the technically inclined, this is also the identifier given by the User Agent string for the new SFSafariViewController.
This data suggests the ad-blocking controversy is overblown. Our data shows that Safari just about controls the majority of browser share, most likely due to its integrations with native Apple apps that come pre-installed, such as iMessage, Mail and News. In addition, many long-tail apps would prefer to open links in an external browser than deal with loading a browser internally. Apple’s ability to drive users to Safari (and therefore dictate the web browsing experience on mobile) is reliant on two key variables: high engagement with its own apps, and providing the long-tail of app developers with simple and powerful Safari integrations. Traffic driven through these sources will be subject to ad blocking changes.
However, Facebook and other WebViews have a solid footprint, with over 41% of link traffic. 32% is a massive amount of web market share for Facebook to claim on Apple’s native platform (and similar to another study that shows the overall time spent in Facebook is an amazing 10% of all time spent on a mobile device). Chrome receives less than 2% of the link traffic, likely a consequence of Google’s mobile lethargy and the significant barriers Apple created to adoption on iOS (such as preventing users from changing their default browser).
Ad-blocking is not the death of the web
Armed with these facts, Web content publishers can take a breath. It’s true Safari controls a large percentage of the market, but Facebook and other WebViews have enough users engaged in their in-app browsers that they offer a serious alternative. If publishers double down on Facebook and other third-parties, they can grow that market share even further, to their mutual advantage.
Of course, the ultimate solution is to build their own native app and acquire users there. Safe from the perils of platform-dependence, publishers can build amazing experiences and control their audience. They just need to figure out how to do it profitably.