By John Gruber
Thanks to this tweet from Dave Rutledge, I figured how to get Google Analytics to show me the split in screen sizes for mobile devices visiting Daring Fireball. Just counting “mobile devices” for the last 7 days:
|Device||% Mobile Sessions|
|320×568 (iPhone 5/5S/5C)||30.1|
|768×1024 (all iPads)||29.0|
|375×667 (iPhone 6)||23.7|
|414×736 (iPhone 6 Plus)||7.0|
|320×480 (old iPhones)||4.1|
Those percentages are only for mobile device sessions. (Mobile devices account for 44 percent of all DF sessions.) Two points of interest to me:
This is more confirmation that the split is around 3-to-1 between the 6 and 6 Plus. As many readers have pointed out, the 6 Plus is still supply constrained, so the split might tilt back toward the 6 Plus once both of them are available everywhere for immediate purchase.
There are already slightly more DF readers using one of the iPhones 6 than the iPhone 5/5C/5S combined. You’re my people.
There’s no way to use screen resolutions to look at last year’s 5S and 5C launch, because their displays were the same size as the iPhone 5 from 2012. But we can look at 2012 and see the uptake for 4-inch iPhone 5 six weeks after it debuted.
|Device||% Mobile Sessions|
|768×1024 (all iPads)||37.4|
|320×480 (older iPhone)||30.4|
|320×568 (iPhone 5)||26.2|
In other words, two years ago, 26.2 percent of mobile-device-using DF visitors were using a brand-new iPhone 5. This year, for the iPhones 6 combined, that number is 30.7. Higher, but not drastically so. This could be one of those things where DF readers are very unlike the public at large — I suspect DF readers have always been the type of people who buy new iPhones as soon as they come out.
What’s more interesting is this. In November 2012, “mobile devices” only accounted for 32.7 percent of total sessions; as stated above, today that’s up to 44 percent. In 2012, the iPad (all models combined) accounted for about 12 percent of DF sessions; today, 13 percent. So it’s roughly flat. (DF traffic overall is roughly flat too.) iPhones accounted for about 19 percent of all traffic to DF back in 2012; today that number is 29 percent. The growth in mobile usage among DF readers over the last two years is almost entirely from the iPhone.
While I’m looking at DF’s web stats, here’s the OS usage for all sessions (not just mobile) for the last week: ★
|OS||% Total Sessions|
|Mac OS X||39.1|
|Windows Phone (sad trombone sound)||0.2|
Christopher Mims, writing in the WSJ, “The Web Is Dying; Apps Are Killing It”:
Everything about apps feels like a win for users — they are faster and easier to use than what came before. But underneath all that convenience is something sinister: the end of the very openness that allowed Internet companies to grow into some of the most powerful or important companies of the 21st century.
I can’t believe someone is still writing this in 2014. Users love apps, developers love apps — the only people who don’t love apps are pundits who don’t understand that apps aren’t really in opposition to the open Internet. They’re just superior clients to open Internet services. Instagram didn’t even have a web interface for years, but native app clients for iOS and Android didn’t lock Instagram into anything. Their back-end is just as open as it would have been if they had only had a web browser client interface. They just wouldn’t have gotten popular.
I spoke about this four years ago at O’Reilly’s Web 2.0 conference, in a talk titled “Apple and the Open Web: A Love Story”. The gist of it being that native iOS apps (and native apps for Android, Mac OS X, Windows, and everything else) aren’t in opposition to the “web”. They live on top of the web. A new layer. They are alternatives to websites that run in web browsers. They’re just better clients. There are two big four-letter “H” acronyms that powered the web from the beginning: HTML (client) and HTTP (networking protocol). Native apps are just an alternative to HTML running in a web browser (and many native apps still use HTML web views embedded within the apps themselves to render parts of their interface). Almost all native apps use HTTP/S for networking, though.
It’s just a conceptual simplification. Instead of a web app running inside a browser running as an app inside an OS (three levels of abstraction), we just have apps running within an OS (two levels). Simpler, easier, more elegant.1
Take that most essential of activities for e-commerce: accepting credit cards. When Amazon.com made its debut on the Web, it had to pay a few percentage points in transaction fees. But Apple takes 30% of every transaction conducted within an app sold through its app store, and “very few businesses in the world can withstand that haircut,” says Chris Dixon, a venture capitalist at Andreessen Horowitz.
That’s patently false. Even with Mims’s own example, Amazon. Just a few minutes before sitting down to write this piece, I used Amazon’s iPhone app — the one distributed through Apple’s App Store — to buy some stuff. I added items to my cart, signed in with my getting-close-to-two-decades-old Amazon account, and I was done. Apple won’t see one penny of that transaction. Not one.
If Amazon started using Apple Pay in their app, Apple would have gotten a fraction of a penny of each dollar I spent — but those pennies would have come from my credit card company, not Amazon.
Retailers who sell through native apps do not pay Apple anything, let alone 30 percent. What Apple charges 30 percent for are purchases for in-app digital content. I can’t buy Kindle books in the Kindle app, or Amazon MP3 music, because of this — but I can buy everything else from Amazon.
The Web was intended to expose information. It was so devoted to sharing above all else that it didn’t include any way to pay for things — something some of its early architects regret to this day, since it forced the Web to survive on advertising.
Says the guy writing for the site with a rather strict paywall.
And exposing information, freely, is where the web continues to thrive (says me, the native app proponent who publishes everything I write on a freely-accessible website). If something works great as a web app, let it be a web app. (There are some great web apps, perfectly suited for what they are.) If something works better as a native app, let it be a native app.
The Web wasn’t perfect, but it created a commons where people could exchange information and goods. It forced companies to build technology that was explicitly designed to be compatible with competitors’ technology. Microsoft’s Web browser had to faithfully render Apple’s website. If it didn’t, consumers would use another one, such as Firefox or Google’s Chrome, which has since taken over.
So let me get this straight. Microsoft’s Internet Explorer “was explicitly designed to be compatible with competitors’ technology”. I can’t wait until Jeffrey Zeldman reads this. From a 2007 Businessweek profile of Zeldman:
This concept may seem obvious today, but during the Browser Wars of the 1990s, Microsoft and Netscape each claimed close to 50% of the market, and their browsers were almost entirely incompatible. It wasn’t uncommon to type in a URL and find that the site didn’t work. Companies eager to open their virtual doors had to invest in multiple versions of their sites. In short, it was a bad situation for businesses and consumers alike. Yet the browser makers were behaving as many software companies do — by trying to out-feature the competition with the introduction of new proprietary technologies.
Back to Mims:
“In a lot of tech processes, as things decline a little bit, the way the world reacts is that it tends to accelerate that decline,” says Mr. Dixon. “If you go to any Internet startup or large company, they have large teams focused on creating very high quality native apps, and they tend to de-prioritize the mobile Web by comparison.”
Many industry watchers think this is just fine. Ben Thompson, an independent tech and mobile analyst, told me he sees the dominance of apps as the “natural state” for software.
Ruefully, I have to agree. The history of computing is companies trying to use their market power to shut out rivals, even when it’s bad for innovation and the consumer.
How has the rise of native mobile apps been anything but a renaissance of innovation? I’d argue we’ve seen far more innovation in the iPhone era (2007-2014) than from 2000-2007. I can’t see how anyone would argue that we’ve seen less innovation. We used to print driving directions from mapping websites; now we get audible turn-by-turn directions on our devices. The pre-mobile web was largely about consumption for most people: reading articles, watching videos, buying stuff. In today’s world, everyone is creating and sharing their own content — everything from photos to videos to their thoughts and observations. Mims claims native mobile apps are “bad for innovation and the consumer” while consumers around the world are doing remarkably innovative things using native mobile apps.
That doesn’t mean the Web will disappear. Facebook and Google still rely on it to furnish a stream of content that can be accessed from within their apps. But even the Web of documents and news items could go away. Facebook has announced plans to host publishers’ work within Facebook itself, leaving the Web nothing but a curiosity, a relic haunted by hobbyists.
Here is where Mims most betrays his conflation of client software and “the Web”. For the sake of argument, imagine a world where all native apps went away. A world where we do everything through web browsers like Safari, Chrome, Mozilla, and IE. In that world, Facebook could do exactly the same thing — “host publishers’ work within Facebook itself”. Exactly the same thing. The control Facebook is exerting here has nothing to do with native mobile apps in particular. They’ve always locked non-Facebook users (like me) out of most content posted to Facebook. Now they’re just talking about hosting even more Facebook-only content.
Arguments about “open” and “closed” often devolve into unresolvable cross-talk where the two sides have different definitions of what open and closed really mean. But the weird thing about a truly open platform is that its openness allows closed things to be built on top of it. In broad strokes, that’s why GNU/GPL software isn’t “open” in the way that BSD software is (and why Richard Stallman outright rejects the term “open source”). If you expand your view of “the web” from merely that which renders inside the confines of a web browser to instead encompass all network traffic sent over HTTP/S, the explosive growth of native mobile apps is just another stage in the growth of the web. Far from killing it, native apps have made the open web even stronger. ★
Chrome OS is an attempt to simplify things a different way: web apps running inside a web browser that presents itself to the user as the OS. ↩
New today: updated Android apps for Google Calendar and Gmail. Both look interesting — as Benedict Evans succinctly put it, “Google is reworking Mail and Calendar from database displays to task-led interfaces. I wonder how far they’ll take that.”
And intriguingly, as Google’s new “material” design language evolves, it’s very clearly heading in a different direction than iOS. Talking about flatness is simply too superficial to be a useful discussion. Superficially, iOS and Android seemingly converged toward flatness (and Windows Phone, of course, was there already), but once you get past those surface similarities, all three mobile platforms are evolving in noticeably different ways.
But Google’s “Material Design” isn’t merely the design language for Android, it’s the design language for all the company’s software. One result of this is that Google’s iOS apps feel less and less like iOS apps with each major release. To me, they look and feel like Android apps running on iOS. Android users might disagree with that assessment, as much of what makes a good Android app Android-y is not how the software looks but the way it interacts with the system. But these Google apps certainly don’t look or feel quite like iOS apps. Their brand-new you-need-a-beta-invitation Inbox app is also interesting (I got an invitation last week), but even though it’s a brand-new app, if anything, it feels less like an iOS app than Google’s other iOS apps. For one thing, Inbox uses a blue background for the status bar, which is the system-standard cue to indicate that cellular tethering is engaged. Another example: None of the Google iOS apps I have on my iPhone (Maps, Gmail, Inbox) support the iOS standard swipe-from-left-edge shortcut to go back in the view hierarchy. That’s a two-year-old standard design pattern for iOS, and I find it downright essential with the bigger displays on the new iPhones. (In hindsight, it seems fairly obvious that Apple added this gesture in iOS 7 because they knew then that bigger-screen iPhones were in the pipeline.)
One last thought. Lost in the competition between platforms (iOS vs. Android) is the more philosophical competition between native and in-browser web apps. In the early days of iOS, say, circa 2008-2011, it was easy to conflate these two battles in public debate, because Apple was seen as the primary proponent of native app development, and Google was seen as a proponent of cross-platform web apps. No more. Google today (like Facebook) seems all-in on native apps, at least (again, like Facebook) for post-PC devices. Just a few years ago, I used to see a lot more arguments from web-app proponents that native apps’ dominance on mobile devices would be short-lived. I don’t see so much of that any more.
I don’t think the web version of Inbox is Chrome-only because Google wants to lock people into Chrome. I don’t think it’s about spite. I think it was just a practical decision that fell out of a desire to push the limits of the in-browser web app experience, rather than limit themselves to a common baseline of functionality available across the X top browsers. Cynics surely look at this as the second coming of Microsoft’s IE-only web technologies from the late ’90s, but my guess is that support for additional browsers is coming, that Safari is probably high on that list, and they shipped Chrome-first only because it was the fastest way they could ship. One reason Google created Chrome in the first place was to have a browser they controlled to better enable the sort of web apps they wanted to build.
In short, though, a Chrome-only app from Google — even if only temporary — is not how the world of standards-supporting web apps was supposed to work, in the aftermath of the breakup of Microsoft’s IE hegemony. But I’m not surprised. Practicality trumps idealism in the long-run, and the idea that the post-IE world of web browsers would lead to a world of universal cross-platform software is pretty much the definition of an idealistic crusade.
I see a certain irony in all this. Google is cultivating a single look-and-feel for their apps. But for mobile they’re creating them as separate native Android and iOS apps. But their latest web app for desktop PCs, Inbox, only runs in one browser, Chrome. ★