By John Gruber
Run Windows and more with this Parallels Mac app bundle for $25 with code: ALLSTARMAC
Special guests Craig Federighi and Greg Joswiak join me to discuss the news from WWDC 2021: the all-new multitasking interface in iPadOS 15, on-device Siri, new privacy controls in Safari and Mail, MacOS 12 Monterey, and more.
Brought to you by these outstanding sponsors:
The email evidence1 in the Epic v. Apple trial has offered a cornucopia of insight into Apple’s internal deliberations over the last 14 years. Juicy stuff always comes to light in a big-money trial like this, but the discovery evidence in Epic v. Apple has struck me as particularly juicy.
On the cusp of WWDC 2021, my thoughts remain focused on one in particular — a 28 July 2011 email from Phil Schiller to Steve Jobs and Eddy Cue. (Jobs, at the time, was a month away from stepping down as CEO; I don’t know what to make of the fact that Tim Cook wasn’t included on the email.)
The subject of Schiller’s email ostensibly was this Wall Street Journal story positing that HTML5 was a threat to both Adobe Flash and Apple’s App Store. But, really, the email was about the future of the App Store itself. The entire email (from slide 44 of Epic’s Opening Demonstratives:
From: Philip Schiller
Subject: HTML5 Poses Threat to Flash and the App Store
To: Eddy Cue, Steve Jobs
Date: Thu, 28 Jul 2011 09:27:10-0700
Food for thought:
Do we think our 70/30 split will last forever? While I am a staunch supporter of the 70/30 split and keeping it simple and consistent across our stores, I don’t think that 70/30 will last that unchanged forever. I think someday we will see enough challenge from another platform or web based solutions to want to adjust our model (already Google has rolled out a web in app purchase model at 95/5).
If someday down the road we will be changing 70/30, then I think the question moves from “if” to “when” and “how”. I’m not suggesting we do anything differently today, only that whenever we make a change we do it from a position of strength rather than weakness. That we use any such change to our advantage if possible. And thinking about this long in advance can only help to look at an eventual change as an opportunity (with developers, press, customers, etc).
Just as one thought, once we are making over $1B a year in profit from the App Store, is that enough to then think about a model where we ratchet down from 70/30 to 75/25 or even 80/20 if we can maintain a $1B a year run rate? I know that is controversial, I just tee it up as another way to look at the size of the business, what we want to achieve, and how we stay competitive. Again, just food for thought.
This email is simultaneously not surprising — because he’s Phil Schiller, steward of the Apple brand, and because, of course, at some point surely some discussion was had within Apple about the permanence of 70/30 — but also shocking, because, my god, it spells out a game plan that would have kept Apple out of all this.
Apple’s antitrust concerns around the world are almost entirely centered around the App Store. Some of those concerns are not about the 70-30 / 85-15 splits. Some of the concerns are simply about Apple’s total control over the platform — the lack of options for distributing native software from any sources other than the App Store; the fact that Apple can build features like Find My into the operating system while third parties like Tile cannot; the fact that Apple Music is installed by default and Spotify is not, etc. There are some serious complaints that would not go away if Apple were to unilaterally reduce the App Store commission to, say, 80/20 or even 90/10.
But: an awful lot of the complaints about the App Store — legal objections from competitors, regulatory investigations from governments, and developer community frustrations — would not be on the table today if Apple had followed Schiller’s loose plan outlined in this email. A lot of it is about the money.
Apple makes record-shattering amounts of revenue and profit. But they don’t make every bit of money they can from every single opportunity. To do so would be counterproductive — to squeeze too tightly on every possible source of revenue would dent the company’s brand. To name one seemingly inconsequential example: they do not sell t-shirts or other souvenir-type logo paraphernalia in their retail stores, other than at the visitor center at Apple Park. They choose to leave that money on the table.
You cannot place a dollar value on many essential aspects of any company’s business. What is the Apple logo worth? Think about that. I’m not being coy to state flatly that the Apple logo is invaluable. It is literally priceless. The Apple logo means something very important to the company, but no dollar value can be placed on it. And they could squander some of that value by overusing (or misusing) it.
The App Store, though, feels more and more like the one area of the company where they’ve committed to squeezing as much money as they can out of it. The damage this has caused to Apple’s third-party developer relations is immense.
During Tim Cook’s testimony a few weeks ago, the most strident questions he faced came not from Epic’s attorneys (who, quite frankly, did not seem to have a coherent game plan) but from Judge Yvonne Gonzalez Rogers, who throughout the trial seemed rightly focused on App Store rules I’ve long objected to — anti-steering provisions. These are the rules that forbid apps from telling users they can sign up for accounts (or buy e-books or other digital content) at the company’s website. The rules against explaining the rules, as I like to put it.
Rogers also expressed doubt that Apple’s Small Business Program, which cut App Store fees in half for small developers, was made out of concern for small businesses during the Covid pandemic, as Cook testified on Friday. “That seemed to be the result of the pressure accrued because of investigations, of lawsuits,” Rogers said.
Cook said that lawsuits were in the back of his head, but what triggered the program was worry over small businesses during Covid.
Rogers remarked that she had seen a survey that 39% of Apple developers are dissatisfied with the App Store. “It doesn’t seem to me that you feel any pressure or competition to actually change the manner in which you act to address the concerns of developers,” Rogers said.
Cook disagreed and said that Apple “turns the place upside down for developers.”
Most developers I know think that the only thing Apple turns upside down for developers is the proverbial couch, out of which Apple seemingly wants to shake every last nickel of spare change it can.
Apple’s platforms have never been for every developer. (The closest, perhaps, was the Apple II era.) But post-Macintosh, for a certain type of developer, Apple’s platforms were the show. The big leagues. I stole that from a post by my friend and colleague Brent Simmons:
I don’t think Joel is wrong about anything he says. It’s true, for instance, that “if your Windows product appeals to 1 in 100 Windows users, you have to appeal to 25 in 100 Mac users to make the same amount of money.”
On the other hand, it’s still true that if Joel sells 10,000 copies to Windows users of a $100 app, he makes the same amount of money as I do if I sell 10,000 copies to Mac users of a $100 app.
One of the reasons I develop for OS X is that, when it comes to user interface, this is the big leagues, this is the show. That’s probably what Joel would call an “emotional appeal” — and to call it that, that’s fine by me.
Brent wrote that 19 years ago.
I’m talking about the sort of developer who, back then, chose to write Mac-exclusive software in the years when the Mac was languishing, or even during the rebound years of the early OS X era, when the Mac market was growing again but still small compared to Windows or the universal platform of the web.
The sort of developers who today would prefer to create something iOS-specific — building on the frameworks and design idioms exclusive to Apple’s specific platforms, not to “mobile” as a general idea.
The sort of developers who want to do what Apple does with software: make things that are delightful, exquisite, and just right for the platform.
It’s these developers, who were once the most firmly committed to developing software exclusively for Apple’s platforms, whose criticisms of Apple’s App Store policies are the most cogent and strident.
In my imagination, a world where Apple had used Phil Schiller’s memo above as a game plan for the App Store over the last decade is a better place for everyone today: developers for sure, but also users, and, yes, Apple itself. I’ve often said that Apple’s priorities are consistent: Apple’s own needs first, users’ second, developers’ third. Apple, for obvious reasons, does not like to talk about the Apple-first part of those priorities, but Cook made explicit during his testimony during the Epic trial that when user and developer needs conflict, Apple sides with users. (Hence App Tracking Transparency, for example.)
These priorities are as they should be. I’m not complaining about their order. But putting developer needs third doesn’t mean they should be neglected or overlooked. A large base of developers who are experts on developing and designing for Apple’s proprietary platforms is an incredible asset. Making those developers happy — happy enough to keep them wanting to work and focus on Apple’s platforms — is good for Apple itself. “Only on iPhone” is powerful.
I’ve been deeply involved with the Apple developer community since the 1990s. There has always been conflict between developers and Apple. Over the balance of fixing bugs versus adding features to the platforms, over the quality of documentation, over the tools, over everything. But the relationship has clearly turned for the worse during the App Store era, and the reason, I think, is money.
What’s weirdest about Apple’s antitrust and PR problems related to the App Store is that the App Store is a side hustle for Apple. Yes it’s earning Apple $10+ billion a year, and even for Apple that’s significant. But it’s not Apple’s main business by a longshot. To my knowledge no company in history has ever gotten into antitrust hot water over a side business so comparatively small to its overall business. Apple doesn’t need this.
I think Apple’s senior leadership — Cook in particular — truly does believe that Apple has earned every dollar it generates from third-party software in the App Store, and that their policies in place are just and fair. That righteousness came out on the stand in the Epic trial. But even if Apple’s executives are correct — if the current rules and revenue splits could somehow be proven to be dialed in to a hypothetical Platonic ideal of fairness to all parties involved — that doesn’t change the fact that so many developers see it otherwise.
I don’t think the developers are wrong, but even if they are wrong, it’s not good for Apple that they’re so unhappy, and feel so aggrieved. It’s not good for Apple that developers don’t see the App Store as a platform that works in their interests.
Like the Apple logo, “developer goodwill” has no price tag. But Phil Schiller’s decade-ago idea to start dialing down the revenue split — in favor of developers — comes pretty close to assigning it one. ★
It really has all been email, too. Unless I’m missing something, not one piece of communication entered into evidence — from either Apple or Epic — has been anything other than an email message. Not one message from iMessage or any other messaging service. I find that very surprising. Do Apple executives never use iMessage to discuss work? Nor Epic’s? If anyone with legal expertise can explain why this is, let me know. ↩︎
Interesting new document in the May update to Apple’s Platform Security guide: “Secure Intent and Connections to the Secure Enclave” (spotted by Glenn Fleishman). It’s short, so I’m quoting it in its entirety:
Secure intent provides a way to confirm a user’s intent without any interaction with the operating system or Application Processor. The connection is a physical link — from a physical button to the Secure Enclave — that’s available in the following:
- iPhone X or later
- Apple Watch Series 1 or later
- iPad Pro (all models)
- iPad Air (2020)
- Mac computers with Apple Silicon
With this link, users can confirm their intent to complete an operation in a way designed such that even software running with root privileges or in the kernel can’t spoof.
This feature is used to confirm user intent during Apple Pay transactions and when finalizing pairing Magic Keyboard with Touch ID to a Mac with Apple silicon. A double-press on the appropriate button when prompted by the user interface signals confirmation of user intent. For more information, see Securing purchases with Apple Pay. A similar mechanism — based on the Secure Enclave and T2 firmware — is supported on MacBook models with the Apple T2 Security Chip and no Touch Bar.
First things first, this sentence seems to be outdated/wrong:
A double-press on the appropriate button when prompted by the user interface signals confirmation of user intent.
because some of the devices on this list don’t require double-pressing a button. The double-press rule is only for Face ID devices. Touch ID devices on this list only require a fingerprint scan — that includes MacBooks, M1 Macs with the new Magic Keyboard, and older iPad Pros.
In broad strokes, we can classify Apple devices into five categories with regard to authentication and secure intent:
Devices that support neither Face ID nor Touch ID in any way. On such devices (old iOS devices, and Intel Macs without a Touch Bar or Touch ID button) you can only authenticate by entering passcodes / passwords.
iOS devices with Touch ID on the home button. Most such devices are not included in this list. See below.
Devices with Touch ID support not on a home button. This includes the new iPad Air (which has Touch ID on the power button), and recent MacBook models with a Touch Bar or with a Touch ID power button. (The above-quoted support document from Apple mentions “Mac computers with Apple Silicon”, and also says “a similar mechanism … is supported on MacBook models with the Apple T2 Security Chip and no Touch Bar”. That seemingly omits Intel-based MacBook Pros with a Touch Bar, but I think that’s a mistake. Any MacBook Pro with a T2 security chip should, I think, be eligible for the same “similar mechanism” as the ones without a Touch Bar.)
Face ID devices: iPhones X or later, and 2018 or later iPad Pros.1
Apple Watch, which has neither Face ID nor Touch ID, but knows when it has been removed from your wrist after it’s been unlocked via passcode or via unlocking the iPhone to which it is paired. (A lot of Apple Watch owners are not aware that you don’t have to enter your passcode when you put the watch on — you can just put it on and the Watch will unlock when next you unlock your iPhone.) Once unlocked, your Apple Watch is trusted until you take it off.
The desktop Macs eligible for secure intent — the new M1 iMac and the M1 Mac Mini that launched last November — do not qualify without a trusted peripheral. Neither of them has Touch ID on the computer itself. To use Touch ID, they need to be paired with one of Apple’s new Magic Keyboards.
This still qualifies for secure intent, despite the fact that secure intent requires “a physical link from a physical button to the Secure Enclave”, because the keyboard itself contains its own Secure Enclave. [Update 4 June 2021: I was wrong — the Magic Keyboard does not have its own Secure Enclave. See this post for details. But it’s also the case that Apple’s “secure intent” description is now wrong as well, because clearly there’s no “physical link” between the Touch ID sensor of a wireless keyboard and the Secure Enclave in the Mac with which it’s paired.]
Likewise, for several years now, any modern Mac has been able to use an Apple Watch paired to the same iCloud account as a “secure intent” device, very much like using a paired Touch ID Magic Keyboard. You can use a double-click of your Apple Watch side button to confirm purchases and administrator-privileged actions like moving protected files to the Trash. Same thing for unlocking your Mac: your Watch counts as a secure authentication method (but with no interaction required, only proximity).
Conspicuously absent from the list of “secure intent” devices are
all most iOS devices with Touch ID on the home button. The exceptions are the early iPad Pro models from 2015–2017. I have no idea why those early iPad Pros qualify but Touch ID iPhones and non-Pro iPads do not.
One factor — but a factor that wouldn’t explain why home button iPad Pro models qualify for secure intent — might be that the home button is overloaded on those devices. There have been a handful of scam apps that pop up “surprise” in-app purchase prompts, and if the user tries to press the Touch ID home button with the intention of just getting out of the app and back to the home screen, they risk confirming the unwanted purchase as soon as they put their finger on the home button. If all software were trustworthy, Touch ID on the home button would be ideal. With the potential for untrustworthy software, it’s not an ideal design to use the same button for “get me out of here with a press” and for “just touch this to confirm”. In the shift from home button Touch ID to Face ID on iPhones and iPads, Apple has recalibrated the balance between convenience and security to be a little more secure but a little less convenient.
But perhaps the reason Touch ID home button devices don’t qualify for this list is simply that those home buttons don’t have the direct “physical link” to the Secure Enclave that the new Touch ID buttons do (on MacBook keyboards and the new iPad Air’s side button). Perhaps they work in a way such that malware with root privileges could potentially spoof them? And, somehow, the early iPad Pro models were designed with a more secure connection between the home button and Secure Enclave?
Face ID by itself is a good and convenient authentication system for low-security authentication. Unlocking your device, opening up a locked note in Apple Notes, viewing passwords in your Keychain, etc. But for actions that should require extra confirmation, Face ID alone isn’t enough. Consider in-app purchases — it’s not feasible to just use Face ID to confirm a purchase, because if you see the purchase confirmation on screen, you’re already looking at your iPhone or iPad.
The extra confirmation for Face ID could be something on screen that you tap or click, but then it would be susceptible to malware that, in theory, might be on your device. Anything on screen is only as secure as iOS or MacOS itself. That’s why Apple made double-clicking the side button the confirmation for Face ID — the software running on your device cannot spoof a double-click of the side button, and the side button has a direct physical connection to the Secure Enclave that doesn’t go through the OS.
I think this is why Face ID on Macs might prove a little tricky. If a future iMac, say, has Face ID built in, that should work fine for low-security authentications like unlocking your Mac when it wakes from sleep. But for “secure intent”, where does the physical button connected directly to a Secure Enclave go? The iMac could use its power button, like iOS devices do, but the power button on iMacs is on the back of the display. It’s not meant to be convenient. You want the confirmation button to be built into a keyboard, and that keyboard needs to have its own Secure Enclave to have a physical connection to the button. Bluetooth and USB are out — they both go through the OS, so they’re not secure enough. And if you need a Magic Keyboard or Apple Watch for secure intent confirmation, would it really be that convenient to have Face ID on iMacs just for unlocking the screen on wake? Maybe. But like I said, it’s tricky.
[Update 4 June 2021: The new M1 iMacs do use their power buttons as a form of secure intention confirmation: you need to double-press the power button to confirm pairing a Bluetooth keyboard. I didn’t notice this with my review unit because Apple pairs the included keyboard with the iMac at the factory.]
This is true for MacBooks too. They could (and I hope someday will) add Face ID, but if they do, Face ID will likely only be used for low-security authentication, and “secure intent” will necessitate that there still be a Touch ID button in addition to Face ID, or that the user be wearing a trusted Apple Watch.2
In short, I suspect Apple’s biometric authentication future will be multi-sensor. ★
The 2nd generation iPhone SE came after the iPhone X, and does not have Face ID, but because it shipped after the iPhone X, it should qualify for “iPhone X or later” — but it’s unclear to me if it qualifies for secure intent. I think now that the list is growing, Apple ought to list each supported device specifically. ↩︎︎
And again, think about how these confirmations work on Apple Watch: you don’t OK them on screen, you OK them with a double-click of the hardware side button, something software in WatchOS cannot spoof. ↩︎
Copyright © 2002–2021 The Daring Fireball Company LLC.