By John Gruber
Build faster, more secure apps at scale. Try us for free.
Back in May I wrote a piece titled “Safari vs. Chrome on the Mac”. From my conclusion:
In short, Safari closely reflects Apple’s institutional priorities (privacy, energy efficiency, the niceness of the native UI, support for MacOS and iCloud technologies) and Chrome closely reflects Google’s priorities (speed, convenience, a web-centric rather than native-app-centric concept of desktop computing, integration with Google web properties). Safari is Apple’s browser for Apple devices. Chrome is Google’s browser for all devices.
I personally prefer Safari, but I can totally see why others — especially those who work on desktop machines or MacBooks that are usually plugged into power — prefer Chrome. DF readers agree. Looking at my web stats, over the last 30 days, 69 percent of Mac users visiting DF used Safari, but a sizable 28 percent used Chrome. (Firefox came in at 3 percent, and everything else was under 1 percent.)
As someone who’s been a Mac user long enough to remember when there were no good web browsers for the Mac, having both Safari and Chrome feels downright bountiful, and the competition is making both of them better.
But really, taken as a whole, the response to my piece was about one thing and one thing only: the fact that Safari does not show favicons on tabs and Chrome does. There are a huge number of Daring Fireball readers who use Chrome because it shows favicons on tabs and would switch to Safari if it did.
The reaction was so overwhelming I almost couldn’t believe it.
The gist of it is two-fold: (1) there are some people who strongly prefer to see favicons in tabs even when they don’t have a ton of tabs open, simply because they prefer identifying tabs graphically rather than by the text of the page title; and (2) for people who do have a ton of tabs open, favicons are the only way to identify tabs.
With many tabs open, there’s really nothing subjective about it: Chrome’s tabs are more usable because they show favicons. Here are two screenshot comparisons between Safari and Chrome from my 13-inch MacBook Pro. The first set shows 11 tabs: the TechMeme home page plus the first 10 stories linked today. The second set shows 17 tabs: the Daring Fireball homepage and the 16 items I’ve linked to so far this week.
This is not even close. Once Safari gets to a dozen or so tabs in a window, the left-most tabs are literally unidentifiable because they don’t even show a single character of the tab title. They’re just blank. I, as a decade-plus-long dedicated Safari user, am jealous of the usability and visual clarity of Chrome with a dozen or more tabs open. And I can see why dedicated Chrome users would consider Safari’s tab design a non-starter to switching.
I don’t know what the argument is against showing favicons in Safari’s tabs, but I can only presume that it’s because some contingent within Apple thinks it would spoil the monochromatic aesthetic of Safari’s toolbar area. I really can’t imagine what else it could be. I’m personally sympathetic to placing a high value on aesthetics even when it might come at a small cost to usability. But in this case, I think Safari’s tab design — even if you do think it’s aesthetically more appealing — comes at a large cost in usability and clarity. The balance between what looks best and what works best is way out of whack with Safari’s tabs.
And it’s highly debatable whether Safari’s existing no-favicon tabs actually do look better. The feedback I’ve heard from Chrome users who won’t even try Safari because it doesn’t show favicons isn’t just from developers — it’s from designers too. To me, the argument that Safari’s tab bar should remain text-only is like arguing that MacOS should change its Command-Tab switcher and Dock from showing icons to showing only the names of applications. The Mac has been famous ever since 1984 for placing more visual significance on icons than on names. The Mac attracts visual thinkers and its design encourages visual thinking. So I think Safari’s text-only tab bar isn’t just wrong in general, it’s particularly wrong on the Mac.1
I really can’t say this strongly enough: I think Safari’s lack of favicons in tabs, combined with its corresponding crumminess when displaying a dozen or more tabs in a window, is the single biggest reason why so many Mac users use Chrome.
You can even make an argument that adding favicons to Safari wouldn’t just make Safari better, but would make the entire MacOS system better, because Safari gets dramatically better battery life than Chrome. For MacBook users who spend much or most of their days in a web browser, it can mean the difference of 1-2 hours of battery life. This is actually a common refrain I heard from numerous readers back in May: that they wished they could switch from Chrome to Safari because they know Safari gets better battery life, but won’t because Safari — seemingly inexplicably — doesn’t show favicons in tabs.
Favicons wouldn’t even have to be displayed by default to solve the problem — Apple could just make it a preference setting, and power users would find it. The fact that it’s not even a preference, even though it may well be the single most-common feature request for Safari, seems downright spiteful. And not just mean-to-others spiteful, but cut-off-your-nose-to-spite-your-face spiteful. It might sound silly if you’re not a heavy user of browser tabs, but I am convinced that the lack of favicons is holding back Safari’s market share. ★
And iPad, for that matter, which arguably places even more emphasis on icons over names than the Mac. ↩︎
Thanks to last week’s inadvertent release of an unredacted build of HomePod’s version of iOS, we know some things that we didn’t know before. One of those things is that the new edge-to-edge iPhone is codenamed D22, and that the OS explicitly supports an iPhone display with hardware resolution of 2436 × 1125 pixels.
For reference, all 4.7-inch iPhones to date (6, 6S, and 7) have a display resolution of 1334 × 750, at 326 PPI. All Plus models to date have a display resolution of 1920 × 1080, at 401 PPI. Apple publishes these numbers on the iPhone tech specs comparison page.
Back in 2014, in the lead-up prior to the announcement of the iPhone 6 and 6 Plus, I tried to guess the pixel dimensions of both phones:
But after giving it much thought, and a lot of tinkering in a spreadsheet, here is what I think Apple is going to do:
- 4.7-inch display: 1334 × 750, 326 PPI @2x
- 5.5-inch display: 2208 × 1242, 461 PPI @3x
@2x means the same “double” retina resolution that we’ve seen on all iOS devices with retina displays to date, where each virtual point in the user interface is represented by two physical pixels on the display in each dimension, horizontal and vertical. @3x means a new “triple” retina resolution, where each user interface point is represented by three display pixels. A single @2x point is a 2 × 2 square of 4 pixels; an @3x point is a 3 × 3 square of 9 pixels.
I could be wrong on either or both of these conjectured new iPhones. I derived these figures on my own, and I’ll explain my thought process below. No one who is truly “familiar with the situation” has told me a damn thing about either device. I have heard second- and third-hand stories, though, that lead me to think I’m right.
My guess about the 4.7-inch display was exactly correct. My guess about the 5.5-inch display was wrong, but my logic was right. All 5.5-inch iPhone Plus models have hardware 1920 × 1080 displays at 401 PPI, but at their default scaling (“Standard” as opposed to “Zoomed” in the Display section of Settings) they pretend to be 2208 × 1242 displays at 461 PPI, exactly as I predicted. (Actually, it’s better to think of it as 462 pixels per inch, because 462 is evenly divisible by 3, which is what you need to do convert pixels into points on an @3x retina display. So let’s use 462 henceforth. I should have thought of this back in 2014.)
iOS scales the user interface on the Plus models from the virtual resolution of 2208 × 1242 to the actual hardware resolution of 1920 × 1080 on the fly. The upside of this is that the display is less expensive and consumes less power. The downside is that the UI is not rendered pixel perfectly — the scaling uses anti-aliasing to fake it. But because the pixels are so very small, almost no one has sharp enough eyes to notice it, and because the physical resolution is so high (401 PPI), it looks sharper than the 4.7-inch displays which are running at their “true” resolution, with no scaling. But pixel-perfect “true” @3x would look even better.
Using similar logic, and considering all of the rumors and purported part leaks, I have a highly-educated guess as to the dimensions of the D22 display:
5.8 inches, 2436 × 1125, 462 PPI, true @3x retina with no scaling.
We’ve seen the numbers 2436 × 1125 before. Supply-chain rumor savant Ming-Chi Kuo suggested those numbers in a report back in February, which was summarized by both MacRumors and 9to5Mac. But what Kuo has predicted is different from what I’m suggesting. Kuo said the OLED display in this year’s new OLED iPhone will measure 5.8 inches diagonally and will have a total hardware resolution of 2800 × 1242. That’s corner to corner, the entire front face of the device, minus the bezels on the sides, top, and bottom. Within this 5.8-inch display, Kuo said there would be a 5.15-inch “display area” with resolution 2436 × 1125. The remaining area at the bottom of the display would be a “function area” (his term) where, presumably, a virtual home button would appear.
Here is the actual image from Kuo’s report, illustrating this.
I think Kuo has it wrong, and is conflating the pixel dimensions of two different iPhones. I think this year’s new flagship iPhone, D22, has a 5.8-inch 2436 × 1125 display. I wouldn’t be surprised if Kuo heard about a 2800 × 1242 display, too, but if so I think that phone is a Plus-sized version of this new form factor, with the same 462 PPI density and a size of around 6.6 inches diagonally. Such a display, with the reduced bezel design of D22, would be exactly as tall as an iPhone 7 Plus and slightly narrower. I wouldn’t be surprised if such a phone is in the pipeline for 2018.
From what I’ve seen, Kuo specified the size (5.8 inches) and the pixels (2800 × 1242), but he didn’t specify the PPI density. But given the size and the horizontal and vertical pixel counts, you can work out the PPI. Benjamin Mayo did so, and the result is 521 PPI.
A 521 PPI display doesn’t actually make sense though. I didn’t really think about this until today, but that number should have stuck out like a sore thumb back in February. Here’s the thing. It matters how big a point is, because it directly affects the real-world size of on-screen elements.
All non-Plus iPhones to date — every one of them from the original iPhone in 2007 through the iPhone 7 — has a display with 163 points per inch. In the pre-retina era, that meant 163 pixels per inch, too. Each pixel was a point, each point was a pixel. All @2x iPhone retina displays have 326 pixels per inch. Divide by 2 and you get 163 points per inch. That means that a 44-point touch target is exactly the same physical size on screen on all non-Plus iPhones. 16-point type renders at exactly the same size, and so on.
The 6/6S/7 Plus phones have a slightly lower points per inch density: take 462 (the number of pixels per inch in the scaled version of the UI), divide by 3 (because it’s an @3x retina display) and you get 154 points per inch. That’s OK, though, because fewer points per inch means that a, say, 44-point touch target will be slightly bigger on screen. 16-point type will render slightly larger, and so on. Larger tap targets are easier to hit, and larger type is easier to read. The iPhones Plus use most of their extra pixels (compared to their non-Plus siblings) to show more content on screen. But they also use them to make all content slightly larger.
A 521-PPI display doesn’t make sense because if you divide by 3 (because it’s @3x retina), you get around 174 points per inch. That’s not a huge difference, but everything would appear smaller on screen compared to an iPhone 7, and quite a bit smaller than on an iPhone 7 Plus. The only two natural pixel-per-inch densities for an @3x iPhone display are 462 PPI (154 × 3) and 489 PPI (163 × 3).
“What about scaling?” you might be thinking. Couldn’t the resolution of the display be 521 PPI and Apple could make the points per inch work out by scaling the interface dynamically, like they do on the Plus models? They could, but that would be really dumb. For one thing, if it’s @3x, they’d have to scale the UI up, not down. They’d be using a smaller image to fill a bigger screen. With the Plus, they use a larger image to fill a smaller screen. Scaling down is a reasonable and interesting compromise. Scaling up would be stupid. Surely a 521-PPI display would cost more to manufacture than a 462-PPI display. So why would Apple pay more for a display and use scaling when they could pay less for a 462 PPI display on which they don’t have to do any scaling at all? It would cost less, look better, and be more efficient.
So we know that iOS 11 has support for a 2436 × 1125 iPhone display. We know that 462 PPI is the “natural” (no scaling) resolution for @3x retina on iPhone. We know that a 2436 × 1125 display with 462 PPI density would measure 5.8 inches diagonally. We know that all rumors to date about the D22 iPhone claim it has a 5.8-inch display. We know that a 5.8-inch display with a 2.17:1 aspect ratio (2436/1125), combined with 4-5mm bezels on all sides, would result in a phone whose footprint would be just slightly taller and wider than an iPhone 7. And we know that all rumors to date say that D22 is slightly bigger than an iPhone 7.
We also know that the same section of iOS 11 that specifies the 2436 × 1125 display does not mention anything about a 2800 × 1242 display. Further, that same section of iOS refers to the iPhone Plus as having a 1920 × 1080 display — this is part of the OS that deals with the actual hardware resolution of the displays, not the virtual scaled display size.
We also know that a 2800 × 1242 display would have a slightly different aspect ratio: 2.25:1. Stephen Troughton-Smith noted today with a mockup that a purported schematic of D22 made from precise blueprints, which was leaked on Twitter by Benjamin Geskin back in April of this year, shows a display that exactly matches the 2.17:1 aspect ratio of a 2436 × 1125 display. A 2800 × 1242 display doesn’t come close to fitting that schematic.
We know these things. All of these facts point to the same conclusion: D22’s display is 5.8 inches, 2436 × 1125, 462 PPI. The only reason to think otherwise is that Ming-Chi Kuo reported otherwise back in February. The simplest explanation is that Kuo got this wrong, and either he or his sources conflated the displays of two different iPhones.1 ★
It also never made sense to me how Kuo would know about the precise dimensions of a single display that would be split into separate “display” and “function” areas. That’s something that would be handled by iOS in software, not something in the hardware. Kuo’s sources seem to be exclusively or almost exclusively in the Asian supply chain. I can’t recall him ever getting a major scoop related to software. My understanding is that Apple does not even send prerelease builds of iOS to China. Instead, Apple employees fly prototype iPhones from China back to the US for testing with development builds of iOS. ↩︎
From the company blog of ExpressVPN, a major VPN provider serving users in China:
We received notification from Apple today, July 29, 2017, at roughly 04:00 GMT, that the ExpressVPN iOS app was removed from the China App Store. Our preliminary research indicates that all major VPN apps for iOS have been removed.
Users in China accessing a different territory’s App Store (i.e. they have indicated their billing address to be outside of China) are not impacted; they can download the iOS app and continue to receive updates as before. […]
Users in China can continue to stay connected to the open internet with ExpressVPN’s apps for Windows, Mac, Android, and other platforms.
Sunday Yokubaitis, president of Golden Frog, a company that makes privacy and security software including VyprVPN, said its software, too, had been taken down from the app store.
“We gladly filed an amicus brief in support of Apple in their backdoor encryption battle with the F.B.I.,” he said, “so we are extremely disappointed that Apple has bowed to pressure from China to remove VPN apps without citing any Chinese law or regulation that makes VPN illegal.”
He added, “We view access to internet in China as a human rights issue, and I would expect Apple to value human rights over profits.”
That’s a popular sentiment — that Apple should have stood up to China’s demands and accepted the consequences, even if it meant losing sales in China. But it’s disingenuous to pretend that this situation is not fraught with complications.
It’s also disingenuous to claim Apple has “bowed to pressure from China to remove VPN apps without citing any Chinese law or regulation that makes VPN illegal”. The very next paragraph in the Times story says:
In a statement, Apple noted that the Chinese government announced this year that all developers offering VPNs needed to obtain a government license. “We have been required to remove some VPN apps in China that do not meet the new regulations,” the company said. “These apps remain available in all other markets where they do business.”
Beijing has launched a 14-month nationwide campaign against unauthorised internet connections, including virtual private network (VPN) services, which allow users to bypass the country’s infamous “Great Firewall”.
A notice released by the Ministry of Industry and Information Technology on Sunday said that all special cable and VPN services on the mainland needed to obtain prior government approval — a move making most VPN service providers illegal.
Here’s a story from earlier this month about the Waldorf Astoria in Beijing being forced to remove the VPN service that had previously been provided for guests. New York Times reporter Paul Mozur (who lives in Beijing) posted to Twitter today that Amazon is sending cease and desist letters to AWS customers using VPNs in China. Apple is not alone.
Too many people reacting to this story think that it’s about Apple deciding to acquiesce to this particular demand regarding VPN apps. It’s not. The real issues are two-fold:
Neither of these are simple topics, and I would (and am about to) argue that neither question has a clear-cut “this is the right thing to do” answer.
First, let’s dispose of the notion that Apple could have chosen to defy the Chinese government and keep the VPN apps in the App Store. Technically, Apple could have done that. But if they had, there would have been consequences. My guess is that the Chinese government would move to block all access to the App Store in China, or even block access to all Apple servers, period. This would effectively render all iOS devices mostly useless. iPhones have been sagging in popularity in China for a few years now — with no access to apps, their popularity would drop to zero. And Apple would have a lot of angry iPhone-owning users in China on its hands.
If Apple tugged on the “We refuse to remove these VPN apps from the App Store” thread, it would inextricably lead to their leaving the entire Chinese market. It’s easy to say “Apple shouldn’t have removed these apps.” It’s not so easy to say “Apple should pull out of China.” This is of course further complicated, politically, by the fact that the vast majority of Apple’s supply chain is in China.
You can say it though. Yes, China is Apple’s second-biggest market in the world, accounting for almost $11 billion in revenue in the quarter that ended three months ago. But Apple could take a stand and draw the line in the sand here.
If you really think VPN apps in the App Store is the hill Apple should die on in China, I get it. But I do not agree.
As I see it, there are only two scenarios:
The first scenario is obviously better for Apple financially. But I would argue that the first scenario is also better for the people of China.
The thing I keep thinking about is that iMessage and FaceTime are among the few protocols available inside China with end-to-end encryption. The Chinese just started blocking WhatsApp a few weeks ago. I don’t know why they allow iMessage and FaceTime to continue working, but they do, and both of those protocols are designed from the ground up to only work using end-to-end encryption. There is no “off switch” for iMessage encryption that Apple can flip inside China. If you’re using iMessage, it’s encrypted. It would surprise no one if China started blocking iMessage and FaceTime, but for now, their availability is a real benefit to the people of China that seems to go largely unrecognized.
To me, the more interesting question isn’t whether Apple should be selling its products in China, but rather whether Apple should continue to make the App Store the only way to install apps on iOS devices. A full-on “install whatever you want” policy isn’t going to happen, but something like Gatekeeper on MacOS could.
Keep iOS App Store-only by default. Add a preference in Settings to allow apps to be downloaded from “identified developers” (those with an Apple developer certificate) in addition to the App Store. In that scenario, the App Store is no longer a single choke point for all native apps on the device.
The App Store was envisioned as a means for Apple to maintain strict control over the software running on iOS devices. But in a totalitarian state like China (or perhaps Russia, next), it becomes a source of control for the totalitarian regime.
I don’t expect Apple to do this. They’d rather deal with the negative consequences of the App Store as a choke point than give up the benefits (including the profits) of maintaining complete control over all software on the platform.1 But if you’re angry about Apple’s role in this VPN crackdown in China, I suggest you direct your anger at the App Store as the single source for third-party software. ★
It’s worth noting that it’s not quite true that all software on iOS must come from the App Store. Anyone with a developer account can compile and install apps on their iOS devices from Xcode. There are a number of open source apps for iOS that are distributed this way. Open source VPN clients could be a workaround — albeit one with a high technical expertise barrier — for this VPN situation in China. ↩︎