Apple TV: A World Without Webviews
The new Apple TV’s operating system, tvOS , has some differences from iOS 9, but one of the most startling ones is the removal of support for webviews. These are used throughout the industry for a wide range of purposes, the most obvious of which is to display a website from within your app.
Our Friend, the Webview …
Webviews are found on every major platform out there: OS X, iOS, Android, Windows, Linux, etc. Generally speaking, most major browsers, such as Safari and Chrome are applications built around a webview. The menus and buttons let you interact with the app, navigate to different sites, etc., but the actual heavy lifting of the browser (e.g., showing you what’s on daringfireball.net) is rendered in the main content pane of the app in an embedded webview.
… Is MIA
Webkit is the framework that Apple uses to allow developers to include webviews in their apps. UIWebview, a UIKit class, provides a simple way to do so. Both of these are missing from tvOS.
Even though the classes exist to fetch a page from a remote site, nothing else is really there — the content has to be parsed, the DOM has to be built, the actual HTML has to be rendered and styled, and any embedded Javascript has to be run.
There’s no mechanism for doing any of these things or presenting the Web page to the users.
OK, so what does that mean?
No Internet Browsing
If you’re looking at Twitter and someone you follow posts a link, you can click on it and the app will create a webview, load the link in the webview, and show it to you. You get to check out links quickly without ever having to leave the app. The Facebook app uses webviews for the same purpose. And that’s practically the sole reason why apps like NetNewsWire exist in the first place.
That kind of functionality won’t be happening here.
A Lot of Broken Applications and a Lot of New Code
Webviews are the Duct tape of the mobile world. I’d estimate that 50 to 80 percent of the major apps out there use webviews somewhere within their apps. Apple’s Mail app uses webviews for your email messages, because webviews can style and render the content very efficiently. NetNewsWire uses them prolifically, particularly in a few features we haven’t enabled in the shipping version yet.
The thing about a webview is that although it’s not as good as a native view, it can still be pretty darn good. If you’re a big company trying to roll out apps for iOS, Android, and the desktop browser, you’re going to have three different teams belting out code like crazy for each platform.
Taking a select subset of your app’s views and making them webviews lets you cheat a little. You have a sports company that’s rolling out dedicated apps for each platform, but the batter’s box you show in all of them is actually an embedded Web page. Or you have a social networking app, and the user registration page is an embedded Web page.
Goodbye, OAuth (woah). For now, anyway.
Or you have some content that may have to be changed on the fly, like a concert schedule. Just make it an HTML file you can update and all the sites will grab it and show it when the user wants to check the schedule out.
Webviews make showing content that doesn’t have to look native pretty easy to do, and you only have to do it once and make sure that it renders correctly on all three of your platforms. This can simplify a lot of tricky situations and reduce your costs when you can use them.
For a lot of companies, the absence of webview support on tvOS is going to be painful. It’s going to require custom rewrites of those web-based widgets and views in either native code or TVML, just to support the Apple TV.
In some apps, webviews show up a lot, so this is a huge amount of special case content just to get on the platform. That’s going to make it expensive, in terms of time, level of effort, and money.
No Web Apps
I’m editing this article in Google Docs while my teammates correct my grammar and editing mistakes, and we’re discussing it in Slack. Both of these applications, and pretty much everything else Google does, are web-based, so those are all gone (not that typing with an Apple TV remote would be awesome — just pointing out the class of applications).
Why Would Apple Do This?
Probably for a variety of reasons. Apple uses webviews for its own products, and TVML has been around for the pre-existing Apple TV models for a while. Apple’s been preparing content for this device for a long time, and needed a mechanism for content providers to use as well, so they certainly know the ins and outs of what the platform can handle well.
Control of the user experience would be a huge reason. A gigantic 1080p, non-Retina screen is not going to render Web content well, and Mobile Safari also depends on a large number of gestures (pinch zoom, tapping to zoom in a div, etc.) that simply are not available on the platform.
For another thing, many “native” apps are simply wrappers around Web content, which tend to be a poor overall experience compared to true native apps. This decisively puts an end to those and ensures that any new apps will be more in keeping with the Apple ecosystem. And native apps might endure tvOS updates more gracefully than Web content decoupled from the current platform version.
From a security standpoint, it makes a lot of sense to very much restrict the ecosystem in a way that especially eliminates Web exploitability, which these days always seems to be the weakest link. That’s not to say that it’s not exploitable, but this move at least severs ties with a major security risk.
Result
No matter what the motivation, there’s going to be a lot of work for people to do, particularly for companies that lean heavily on embedded Web content for their apps. Obviously this is going to be great for users, in terms of a consistent experience.
But the industry is going to be very, very busy for a while making the changes needed to support this new platform.
Companies hoping to leverage a universal HTML5/CSS/JS-based UI for multiple platforms may no longer find this option viable. They will need to rethink their strategy for providing a cohesive branded experience on multiple platforms while still writing native apps for those platforms. That’s not to say that someone wouldn’t be able to try compiling WebKit and creating their own view within to render HTML. Certainly there are companies with the manpower and resources to do this. I’m not certain those apps wouldn’t get rejected, though.
One way or another, it’s an exciting time. I’m looking forward to what’s ahead for all of us.
