How Apple Uses Its App Store to Copy the Best Ideas
Developers have come to accept that, without warning, Apple can make their work obsolete by announcing a new app or feature that uses or incorporates their ideas. Some apps have simply buckled under the pressure, in some cases shutting down. They generally don’t sue Apple because of the difficulty and expense in fighting the tech giant—and the consequences they might face from being dependent on the platform.
The imbalance of power between Apple and the apps on its platform could turn into a rare chink in the company’s armor as regulators and lawmakers put the dominance of big technology companies under an antitrust microscope.
The thrust of the Post’s story is clear from its headline. But I don’t think it holds any water. What’s the alternative? For Apple never to add any features to the OS that exist in third-party apps?
[…]
When Apple implements a feature or app idea, they do it in a way that has the broadest possible appeal (or at least try to). The key to competing with Apple as a third-party developer is to focus on segments of the audience that want more than the basics.
[…]
The debate over what’s fair game for Apple (or Google, or Microsoft) to copy from third-party developers has nothing to do with app stores. A popular app is a popular app, and the platform vendors have always known all the popular apps.
Every developer is, in a sense, worried about being Sherlocked. But I don’t think this is anywhere near the top of their list for what to change about the App Store. And, as Gruber says, it’s not clear what the solution would be, anyway. That said, I think app stores do change things a bit, in that the platform vendor can get better data sooner, without having to rely on indirect tactics.
Previously:
Update (2019-09-17): Jeff Johnson:
The issue isn't Apple competing with and copying other developers. It's that Apple artificially restricts and unfairly disadvantages competition.
Apple software isn't subject to App Store (or OS) restrictions, rules, and rejections. It also doesn't have forfeit 30% of revenue.
What’s not fair is this (number 5): they know all past and present market data that even the copied developer doesn’t know himself. About his app. About all similar apps.
12 Comments RSS · Twitter
> "The more basic the feature, the more likely that is. The flashlight is a perfect example. It’s so obviously a good feature for the system that it’s a button on the lock screen — one of only two, right next to the camera."
It's 'so obviously a good feature' that Apple initially banned flashlight apps from the store as 'inappropriate use of hardware,' before turning around and copying them.
The idea that Apple ought to never "add any features to the OS that exist in third-party apps" is presented as self-evidently absurd, but I'm not so sure. This statement elides the distinction between an actual operating system and apps that run on the OS, and the inherent privileges Apple bestows on its own apps. Apple certainly benefits from people thinking of its own apps as immutable features of the OS, like the battery charging system or the volume buttons, but they're not. They're just apps, and they compete against other apps in app store market. And I think there's actually a pretty strong case to be made that it's harmful for Apple to unfairly privilege its own apps that compete in this market.
"What's the alternative? For Apple to put its own apps on the same playing field as everyone else's?" doesn't have the same ring to it, though.
@Moonlight What does “same playing field” mean? No use of private APIs? Developed without knowledge of upcoming features? No integration with other Apple apps?
Anyway, the original idea presented was that even with the same playing field, Apple still shouldn’t add a feature that someone else has implemented. In other words, it’s OK to have multiple third-party flashlights, but Apple isn’t allowed to have one. That does seem absurd to me.
Whether Apple recognizes a hole in their OS right away or not, filling a significant hole is only a strategy for short-term profits for a third party. Apple has to fill holes.
@Michael I think what I mean, on a technical level, is that for the "playing field" to be the same then, yes, Apple's apps would have to be programmed with the same APIs and cross-app integration capabilities as every other app. You make a good point that it's hard to correct for the asymmetry of knowledge between Apple and app makers, but perhaps that is just an argument for saying Apple shouldn't make apps at all. I think that is actually close to what Elizabeth Warren is actually saying she wants? And that might be an absurd position, but I haven't really thought it through that much.
The way I look at flashlight apps is not that I think Apple should be forbidden from making one. The problem is that only Apple can ensure their flashlight button is on the lock screen.
I dunno, mostly I'm feeling wary of Apple using the blurry gray area that smartphones fall into on the spectrum between single-purpose device (like a toaster or real flashlight) and general-purpose computer to obfuscate or justify the potential misuse of platform-holder power.
@Moonlight There need to be some built-in apps. And Apple making its own apps is good for developers because it gets them to dogfood the APIs. Of course, I would love to be able to put third-party apps on the lock screen.
Imagine if Apple apps had to dogfood the same App Store restriction/review/rejection cycles as pleb devs.
> And that might be an absurd position
I don't think it's absurd. I think it would make sense for a platform company like Apple to have an independently run subsidiary (like Claris) to make actual commercial software for that platform. Then that subsidiary would also be subject to the same restrictions as all other third-party software devs, and Apple's incentives would be more closely aligned with third-party devs'. The whole setup right now, where Apple both provides the platform, but then also competes with people who publish software on that platform, is inherently problematic.
Not that it is the biggest issue with Apple's platform at the moment, but still...
This statement elides the distinction between an actual operating system and apps that run on the OS
What is that distinction, though?
This always felt a little iffy to me with the Microsoft/IE+WMP lawsuits. Shipping Windows without any browser or media player would have been absurd. The eventual compromise where, on first launch, you get a dialog presenting various browser options seemed like a decent approach to me.
If iOS shipped without its own home screen, you could still call it an OS. And you could make the argument that any third party should get equal opportunity to make their “desktop”/”shell”/whatever. And you’d — I’m sure — find people who would like that. But that’s not really the Apple way, is it? macOS doesn’t really let you replace the Dock (sadly) or Finder.
The problem is that only Apple can ensure their flashlight button is on the lock screen.
That’s a real problem, but I don’t think it’s an example of malice or abuse on Apple’s part. (After all, to what end? Writing their own flashlight app isn’t exactly a profit center. They only do it as a value-add to the iPhone, i.e. to sell more hardware. The calculus is different with, say, Apple Music, where not only are they in a privileged position; they also financially benefit from it compared to their competitor Spotify.)
Rather, my guess is they haven’t found a good way to balance having lock screen apps be sufficiently secure vs. allowing a third party to write one.
(Well, that, and nobody is lighting a fire under their bottoms to prioritize solving that.)
This kind of goes back to iOS not having any notion of default apps, and if Warren et al ultimately come to the conclusion that an OS must provide such a facility, I wouldn’t mind at all.
But I think Gruber has this right. If your app provides functionality that many people expect to be built in, that’s not really on Apple.
I think it would make sense for a platform company like Apple to have an independently run subsidiary (like Claris) to make actual commercial software for that platform. Then that subsidiary would also be subject to the same restrictions as all other third-party software devs, and Apple’s incentives would be more closely aligned with third-party devs’.
I agree as far as apps like iMovie are concerned, and I think it was a bad move when they made iLife and iWork free. It further accelerated the race to the bottom with app pricing assumptions.
(There's a case to be made that even the flashlight button in Control Center, upon first invocation, should show a "Hey, look at all these great flashlight apps" popup, but there's a ton of issues with that.
At some point, the consumer would be annoyed and wonder if they bought a phone, or a construction kit for one.)
> What is that distinction, though?
The distinction I'm trying (and possibly failing) to make is that the operating system internals fall into the category of things that most people are fine with Apple having more or less total control over. And for iPhone software like the lock screen, the home screen launcher, "first-party" apps like Safari, Siri, and Contacts, by talking about these as "OS features" or "part of the OS," we're grouping them in with the first category even though, from a technical standpoint, they're not the same. I think this is ceding control of aspects of our phones.
I could be wrong, of course. It's possible this is just a quirk of language I'm hung up on, and obviously there's a lot of depth to this whole overall issue, but that's what I meant by distinguishing between the OS and its apps and why I think that's important.
Sorry, I wasn't clear. By "What is that distinction", I really meant to ask: where does one draw the line?
