iPhone App Developer Backlash Growing
from the openness-is-a-good-thing dept
To summarize, it's bad for developers because they're distanced from their users, and can't quickly make changes and updates, since each change needs to go through Apple's long, mysterious and arbitrary approval process. On top of that, by creating a very real risk that Apple might not approve an app, developers have less incentive to put in the time. It's bad for innovation because you are putting a gatekeeper in front of any innovation. It's bad for consumers, because they can't do what they want and often the apps they get are lower quality than they would be otherwise, because developers cannot rapidly respond with necessary improvements and changes. Finally it's bad for Apple because it's driving away some talented developers who are useful in making the iPhone so powerful. As those developers move to other platforms, it will help those other platforms catch up, and potentially surpass the iPhone. But, perhaps more importantly, it's bad for Apple because it risks Apple's overall reputation. It makes it harder to hire top engineers:
There are a couple reasons they should care. One is that these users are the people they want as employees. If your company seems evil, the best programmers won't work for you. That hurt Microsoft a lot starting in the 90s. Programmers started to feel sheepish about working there. It seemed like selling out. When people from Microsoft were talking to other programmers and they mentioned where they worked, there were a lot of self-deprecating jokes about having gone over to the dark side. But the real problem for Microsoft wasn't the embarrassment of the people they hired. It was the people they never got. And you know who got them? Google and Apple. If Microsoft was the Empire, they were the Rebel Alliance. And it's largely because they got more of the best people that Google and Apple are doing so much better than Microsoft today.As for why Apple is making this mistake, Graham blames Apple's general view of the market:
They treat iPhone apps the way they treat the music they sell through iTunes. Apple is the channel; they own the user; if you want to reach users, you do it on their terms. The record labels agreed, reluctantly. But this model doesn't work for software. It doesn't work for an intermediary to own the user. The software business learned that in the early 1980s, when companies like VisiCorp showed that although the words "software" and "publisher" fit together, the underlying concepts don't. Software isn't like music or books. It's too complicated for a third party to act as an intermediary between developer and user. And yet that's what Apple is trying to be with the App Store: a software publisher. And a particularly overreaching one at that, with fussy tastes and a rigidly enforced house style.My guess is that there may be another reason: the perfectionist attitude at Apple. They don't want "bad" apps getting into the store, and certainly some people appreciate that. But the store has 100,000 apps right now, and most people are never going to see the vast majority of them. Having a few "bad apps" get in isn't a huge issue at this point, and certainly user-level reviews can help deal with that issue anyway. And, even if that is the biggest concern, why not at least allow non-approved apps to be viewed and downloaded, just without an official "apple seal of approval." Perhaps it made sense when Apple was first launching the store (though, even that seems questionable), but if it wants to continue to lead the market, it needs to break down that wall.
If software publishing didn't work in 1980, it works even less now that software development has evolved from a small number of big releases to a constant stream of small ones. But Apple doesn't understand that either. Their model of product development derives from hardware. They work on something till they think it's finished, then they release it. You have to do that with hardware, but because software is so easy to change, its design can benefit from evolution. The standard way to develop applications now is to launch fast and iterate. Which means it's a disaster to have long, random delays each time you release a new version.