With iOS 9, the next major release of the iPhone and iPad operating system, just around the corner, the number of questions we’re receiving from publishers is increasing by the day. This post details what’s new in iOS 9, and how the news affect publishers and their online businesses. There’s a lot to cover, so let’s get started:
- Web content blocking is here
- Newsstand is gone
- Apple News
- Universal links launch your app instead of your web site
- Search becomes a tool for app and content discovery
- The Safari View Controller is Safari within your app
- iPads now support split-screen multitasking
- San Francisco is a new font for the Apple brand
- Apps need to work in IPv6 only networks
- A new default security policy mandates SSL
- Parting thoughts
Web content blocking is here
As you’ve undoubtedly heard by know, iOS 9 includes a feature that, for the first time, enables ad blocking in mobile Safari. iOS represents more than 50% of mobile web traffic on markets like the USA, UK, Japan, France and Scandinavia, so this is a very big deal. To fully understand the implications, the following details are worth going over:
First, Apple is not providing any built-in ad blocking functionality. They are enabling developers to build blockers. Just like on a Mac or Windows desktop, users will need to install a third party ad blocker app to block ads. That said, these ad blocking apps will be just an App Store tap away. They are sure to be very popular.
Second, the new ad blockers only work in Safari, not in native apps or any web views inside them. (A new iOS 9 specific way of embedding Safari in an app is affected, but more about that later.)
Finally, the functionality available to content blockers is limited. Ad blocking apps on iOS will not be able to perform heuristic analysis of web content to recognize and block ads, which is what most advanced desktop blockers do; instead, the blocker must prepare explicit rules for the URLs and page element names Safari should block. This system makes it easy to target common trackers, beacons and ad networks, but blocking first-party ad serving will be much more difficult.
We see this feature affecting the mobile publishing landscape in two ways. Most importantly, widespread web ad blocking clearly bolsters the case for native apps over web sites: publishers will remain in complete control over the way content and ads appear in their native apps.
That doesn’t mean you can solve ad blocking simply by wrapping a web site in an app. No reader will rush to use an app if the only “benefit” is the inability to block its ads. A markedly better user experience remains the price of admission for any successful app.
The other outcome we foresee is a rise in first-party served ads. A key trend in 2015 has been the widespread consensus that ad tech has jumped the shark. Today’s popular belief is that ad networks have simply gone too far with their increasingly user hostile and privacy-eroding tactics. This sentiment has arrived in tandem with a sharp rise in ad blocker usage.
For publishers, contextually targeted, first-party-served ads might be a way to “opt out” of the current ad tech controversy. iOS ad blocking increases the publisher incentive for doing just that. Whether it’s enough remains to be seen.
Newsstand is gone
Newsstand started with good intentions, and the first iterations of the feature brought important features to the iOS platform. In time, every one of those features was made available to non-Newsstand apps as well, and, starting with iOS 7, what remained was a separate section in the App Store and a segregated on-device treatment for Newsstand apps – the latter making the feature a net negative for publishers.
With iOS 9, both of those things go away. For users with existing Newsstand apps, the iOS 9 update will move them to a standard app folder (still called Newsstand). But newly downloaded apps will appear directly on the home screen, just like any other app. This will be a huge boost for popular apps currently stuck in the Newsstand back alley, especially on iPhones; cue champagne corks popping at The New York Times.
On the App Store side, Newsstand makes way for a new App Store category called Magazines & Newspapers. It will be just like any other App Store section, with one benefit remaining exclusive to periodicals: publications will continue to be able to change their app descriptions and screenshots at will, not just when uploading a new version of their app. These updates will have to be made manually, though: the Atom feeds that enabled automatic updates of issue descriptions and cover images will no longer be supported.
And, speaking of issue cover images, they are gone from the App Store and the devices, just like the rest of the Newsstand feature. In iOS 9, all apps will be represented by their app icons, rather than issue covers, both on the device itself and in the App Store. If you have a Newsstand app, it’s worth taking a second look at your app icon now: if you’re like most publishers, you have probably not paid much attention to the icon at all. There was little reason to do so since in past iOS versions the icon of a Newsstand app was almost never visible. In a couple of weeks, it will be front and center on your readers’ iPads and iPhones.
It’s hard to find anything to gripe about in these changes. Some publications (and readers) preferred to have their apps represented by the cover of the latest issue, but that’s not workable with the apps now interspersed with all the other apps on a reader’s home screen.
Richie’s recommendation has been to avoid Newsstand, but now that it’s gone, we recommend publications move their apps to (and in some cases, back to) the vestigial Magazines & Newspapers App Store category. This enables updates to the app description and screenshots in near real time – a huge speedup from the week-long app submission cycle.
Apple News is a discovery app for news, magazines and blogs, launching with iOS 9 in United States, the United Kingdom, and Australia. If you’re in one of those markets, the app is a big deal right now; the rest of the world has the luxury of taking a wait-and-see approach.
The job of the original Newsstand feature was the same as a physical newsstand: to help with content discovery. The problem was an absurd amount of friction: instead of effortlessly browsing a couple of print titles before making a choice, Newsstand was just as bad as the rest of the App Store in this regard: to see a publication, you had to enter your password, download an app, launch it, orient yourself with its user interface, and in all likelihood find out that the app you chose requires payment before you see any content at all. Who would go through all that more than a couple of times? Who would go through that even twice?
Apple News solves this by putting individual articles of content front and center. This is similar to the way Flipboard works; both apps share a focus on creating a beautiful, magazine-like lean-back experience around a set of article content.
Content for Apple News is published either in standard RSS feeds or in the proprietary Apple News Format. Think of this as a two-tiered approach: publishing standard RSS feeds in Apple News is currently available for everyone, but the custom format with higher production values has so far been shared with a small set of carefully chosen publisher partners. In this and many other regards, the Apple News Format subset of the app is similar to Facebook Instant Articles – down to the high fidelity native rendering and the ability to sell iAds next to the content.
Apple News does not support paid content. Monetizing with iAds alone is unlikely to drive significant per-reader revenues. This means that publishers cannot serve regular readers with Apple News alone. Luckily Apple News articles can direct users directly to the publisher’s native app for more content.
Our take on Apple News is that if you are currently sharing free content online for promotional reasons, it makes a lot of sense to share it in Apple News (and Flipboard) as well.
Apple News also raises the bar for news reading experiences on the platform. Most current newspaper and magazine apps are simply not as nice to use as Apple News will be. This is something publishers will have to address if they wish to convert Apple News readers to paying regulars in their own apps. In iOS 9, after all, the button back to Apple News will beckon them on the status bar.
Universal links launch your app instead of your web site
In iOS 6, Apple introduced a Safari feature called Smart App Banners; with a simple tag on a web site, you could display a banner that instructed the user to either download or launch a native app instead of continuing to browse the web site. Apple intended this feature as a friendlier, less intrusive alternative to the modal dialogs, very common at the time, that prompted the user to install the app before they even saw the web site. It never worked very well.
New in iOS 9, Apple allows publishers to go even further: if you designate a page on your web site to be equivalent to the page in your app, iOS simply launches your app, no questions asked.
Note: doing this with an app that’s worse than the web site is a great way to get the app uninstalled. This is especially noteworthy in the context of using a native app wrapper to circumvent ad blocking in Safari.
Search becomes a tool for app and content discovery
In conjunction with the Universal linking mechanism described above, Apple has started to crawl web content for their own search engine. This content appears in Spotlight and Safari search results, and your publications can get in on the action.
Here’s the low-down:
- If you add your site as the support or marketing site in your app description, or
- You use universal links to make the same content available both on the web and in your app, and
- Your app tells iOS to index each piece of content in Apple’s public, server-side index, then
- Your content will appear in search results in both Spotlight and Safari – even for users who don’t have your app installed.
By building an explicit mapping between equivalent content within apps and on the web, Apple is bridging the two worlds. Improved searching of app content is the first benefit realized with this approach; it won’t be the last.
The Safari View Controller is Safari within your app
Most newspaper and magazine apps have web links in them, and if your app is like most, you’ve implemented an in-app browser view to open them. The alternative would have been to open the links in Safari, sending your reader into a completely separate app. Would they ever come back? You probably didn’t want to find out.
iOS 9 changes two things. First, when an app sends the user into another app, the status bar now has a link back to the original app. So in the above scenario, your reader in Safari could get back into your app with a single tap on the status bar. Will that be enough to entice them back from the wonders of the web? I bet you still don’t want to find out.
Apple hears you. The Safari View Controller is a new alternative to your homebrew in-app browser. It’s simply Safari, embedded into your app’s navigational structure. It respects the user’s Safari settings, including any Safari extensions and content blockers they’ve decided to use. That means it works the way the user wants their web browser to work (this may or may not align with the way you want their browser to work).
Our recommendation is to adopt the Safari View Controller in the cases where you currently use a custom in-app browser unless you have a concrete business reason not to. If you decide against it, the current web view technologies (UIWebView and WKWebView) continue to be available.
Pen in hand for the pros and cons list? Safari View Controller maintains strict user privacy, so your app does not know much about what’s going on within the browser. This might be a problem for your analytics, but if it is, I’d honestly recommend a review of your tracking policies. Most users do not expect to be providing tracking data to you while browsing the web in an in-app browser.
The second downside is the potential ad blocking. In addition to content blockers, Safari View Controller also honors the user’s Safari cookie settings, with similar potential effects. This probably makes you reluctant to use the Safari View Controller for links to your own site; our recommendation would be to integrate first-party content deeper into your app, making an in-app browser unnecessary in that context.
What about the upsides? The big one is the improved user experience. Your developers probably wrote the current in-app browser in less than a day and chances are it shows. Another benefit is that your users are more likely to be logged on to social sites like Facebook and Twitter, and even if they aren’t, Safari View Controller’s password autofill support will make it easier for them to do so. More social shares for you and your advertisers is a likely outcome.
iPads now support split-screen multitasking
Apple’s big iPad push this year seems to be around multitasking and pro workflows (with the rumored iPad Pro seamlessly tying into this).
Publishers are likely to find that their apps are a part of many of those workflows. In an example of what we’d traditionally think of as a “pro” workflow, it’s easy to imagine someone using a newspaper app side by side with a notepad app. But the juicier scenario of your app being used side by side with the Facebook or Twitter apps is probably more likely to make you see value in supporting this feature.
If you’re as self-centered as I am, you are probably envisioning people focusing on your app while perhaps occasionally looking at another app on the side. You should consider the opposite scenario equally likely. For example, perhaps a reader would be more likely to engage with your push notification if they could briefly open up an iPhone-width strip of your app next to the app you interrupted them in? To do that effectively, you would need to have a “universal” app, capable of displaying content in both iPad and iPhone sizes.
Finally, if your app features longform video content, a new picture-in-picture feature lets an iPad user do other work while continuing to watch. This makes your video engagement much, much more resilient to interruptions. It’s also trivial to implement, so really a no-brainer, right? Wrong, since chances are you’re monetizing videos with complex ad tech that can’t make the jump. See the pattern here?
San Francisco is a new font for the Apple brand
iOS 9 replaces the old system font, Helvetica Neue, with a new Apple-designed typeface called San Francisco. Helvetica has been with us for almost 60 years now, and partly because of all that time we have collectively learned to view it as a “neutral” font.
San Francisco is a gorgeous, well-designed font, but it’s not neutral: Apple designed it specifically for their own use and are using it, among other things, for the branding of both Apple Watch and Apple Music.
The end result is that standard system text on iOS 9 has more of a “look” than in previous versions. Both Google and Microsoft have a specific look for their respective system fonts, too, so this is nothing new. But if your iOS app currently uses the system font, rather than specifying a custom one, it’s worth a look to see if it’s still compatible with your publication’s branding.
The new system font is a good choice for a UI sans serif if there is no branding reason to choose otherwise; if there is, Helvetica Neue is still available.
We’re down to the part of this post where I am mentioning things mostly for completeness. Also, this is where things get technical, so feel free to skip to the end.
Apps need to work in IPv6 only networks
The world has run out of traditional (or “IPv4”) IP addresses, so there are now live network deployments, mostly with Asian mobile carriers, where devices are not getting an IPv4 address at all. Instead, they are getting an IPv6 address. We’ll never run out of those, but the flip side is that the addresses themselves are much longer and differently structured.
A new App Store policy requires apps to work in such IPv6-only environments; if yours doesn’t, it will be rejected.
Most apps will be fine without any changes. Even IPv6-only devices have connectivity to the traditional IPv4 Internet using gateways, so Apple isn’t requiring your servers to have the new IPv6 addressing just yet.
However, any piece of code that directly accesses and works with the IP address of the device is at risk, because chances are that code like that is not ready for IPv6 addresses. Guess what would be a good place to start looking for risky code around this? Try the SDKs for all the various advertising networks and analytics packages in your app. They tend to figure our your IP address and pass it around with wild abandon.
A new default security policy mandates SSL
Apple has demonstrated increasing interest in user privacy and security over the last couple of years, and in 2015 this has become an explicitly stated focus of the company.
As a part of this push, Apple expects iOS apps to use encrypted connections for all network requests as part of a new iOS platform feature called App Transport Security (ATS).
ATS is usually trivial to implement in your app, but server-side infrastructure is a different story. You need SSL certificates, the regimen for keeping them secure and up to date, and the CPU power to perform the encryption on your servers. Signing up for a CloudFlare account is an easier-than-most way to solve the server-side aspects of encryption.
Again, ad networks and other third party SDKs are likely to be problematic in this regard. Apple provides a simple way for apps to opt out of the new security policy for the time being, and Google raised some eyebrows last week by instructing the users of Google Mobile Ads SDK to do just that. But don’t blame Google: moving all of the web display advertising ecosystem over to SSL is, in the short term at least, an intractable task.
As with web content blocking, publishers with full control of their content and ad delivery are best positioned for this change. But others should not despair: opting out is easy, and encryption will remain optional until iOS 10 next year, at the very least.
From a publisher’s perspective iOS 9 is a huge release. In any previous year, this post would have been much shorter: not necessarily because of a lack of progress in iOS, but because so little of the news was directly applicable to newspaper and magazine apps. Here too I’ve skipped big iOS 9 news, like App Thinning and the new Swift 2.0 programming language, when they have no specific importance for publishers’ businesses.
iOS apps have been with us for seven years now, and for most of that time they have existed as islands nearly completely separate from the rest of the web.
This is now changing, with Apple seeing native applications as direct, drop-in replacements for their corresponding web sites. If a site has an iOS app version, that’s what Apple wants users of iPhones and iPads to see. Apps now exist on the web even if they aren’t of the web.
It’s startling to think how far we’ve come from the original Apple–Google pact where each company was supposed to focus on their strengths: Apple on devices and client software, Google on the Internet services to power them.
Today’s Apple realizes that the iOS ecosystem needs just as many “web parts” as Google’s does. The company needs to work on a search engine, so they do; they need to map the planet, so they already have a fleet of vehicles roaming the world’s roads.
Apple’s vision of an app-enhanced web with guarantees for strong privacy and security is not shared by any of its peers. What sets Apple apart in this is their freedom to operate: unlike Google and Facebook, for example, Apple has zero vested interest in preserving the web as it exists today.
User privacy and security have been the hot-button issue this summer, and the call for change can only grow louder. Apple’s interests in this are perfectly aligned with their customers. If yours aren’t, it is time to re-evaluate.
Marko Karppinen is Richie’s founder and CEO. You should follow him on Twitter here.