Thoughts on Paul Graham's post: "Apple's Mistake"

I just read Paul Graham's blog post titled Apple's Mistake. If Steve Jobs doesn't read that post and finally take some action on the farce that is the App Store approval process, Apple will have made two mistakes. And you should read it too because it is overflowing with wisdom.

It is telling in itself that Paul doesn't feel the need to make the case that Apple's App Store approval process is broken. I feel we can all safely agree that it is. The real problem, according to Paul, however, is a greater one:

I don't think Apple realizes how badly the App Store approval process is broken. Or rather, I don't think they realize how much it matters that it's broken.

The way Apple runs the App Store has harmed their reputation with programmers more than anything else they've ever done. Their reputation with programmers used to be great. It used to be the most common complaint you heard about Apple was that their fans admired them too uncritically. The App Store has changed that. Now a lot of programmers have started to see Apple as evil.

Perception.

Good will.

We're not talking about how many applications there are on the App Store today or how many developers there are currently on the platform. We're talking about how happy those developers are. About what they think of Apple.

We're not talking about things that will necessarily affect Apple today but may have a profound affect on the iPhone platform one month/one year/maybe years from now.

I already wrote about how Apple has already begun to lose iPhone Value Adders and how I've personally been hurt by Apple's App Store approval process. Not surprisingly, I find myself left with a very sour taste in my mouth (and writing posts extolling the virtues of open web technologies and praising the innovative open approach of companies like Palm and Google.)

All this and I haven't even submitted my app to Apple yet. (I hope to by this Monday, the latest!)

I am scared, however, of how I will support my users when updates takes weeks to get approved.

Wait a second, I'm scared.

I'm scared of how Apple's lengthy approval process will impact my reputation if I can't deploy a bug fix in a timely manner. I am a developer and I am scared of the platform I am developing for.

Something is very wrong here.

Paul asks:

How did Apple get into this mess? Their fundamental problem is that they don't understand software.

Apple understands that User Experience is about control. That's why they control both the hardware and the software that goes into a Mac. They understand that UX requires a dictatorial iron fist to avoid feature creep and maintain consistency. They understand that the magic word is "no", not yes. And this works wonderfully for them on the desktop because they don't attempt to extend this control to third parties.

There is an honor system of sorts for Mac software developers. Apple leads by example, not direct control. Developers create beautiful, engaging apps for the Mac because they want to and because they want to match the elegance of the operating system and the default applications. It is, however, possible to create ugly apps that don't work for the Mac and no one can stop you from doing that if that's what rocks your boat.

If this works on the desktop, why not implement it on the iPhone? Why not let developers put whatever they like up on the App Store (and update it as frequently as they like), implement a cooling off/refund period to protect users, and let users and the market decide which apps rise to the top and which get buried?

To understand Apple's thinking, here are more words of wisdom from Paul:

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… 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.

Software definitely isn't music. A piece of music, once published, is finished. File corruption aside, you never need to update a piece of music (I'd personally love a system where artists could push new versions and updates to their songs as they evolved them but that's definitely the topic of a separate blog post). Software, on the other hand, is ever-evolving. The only time a piece of software is "finished" is when it is no longer being developed or supported. In other words, the only time a piece of software is "finished" is when it is dead.

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.

More than anything else, it is the potential nightmare of not being able to release timely updates that scares me about the iPhone. More than anything else, this is the reason I am actively looking into alternative platforms like Palm's WebOS and Google's Android. I love the iPhone but I also love my reputation and I would hate for Apple to ruin it.

To understand how important timely updates is to software, consider this:

How would Apple like it if when they discovered a serious bug in OS X, instead of releasing a software update immediately, they had to submit their code to an intermediary who sat on it for a month and then rejected it because it contained an icon they didn't like?

By breaking software development, Apple gets the opposite of what they intended: the version of an app currently available in the App Store tends to be an old and buggy one.

And this is where Apple is failing its users, developers, and, ultimately, its shareholders:

A buggy app on the App Store means lost sales for the developer and for Apple.

Apple has to realize that – like it or not – it is in bed with developers. This is an intimate relationship. If Apple's policies mean that developers and their apps get ill, Apple's eventually going to catch it too.

In the short term, it may feel like it's just a few disgruntled developers whining about their experiences but trust me, we're just the vocal ones. We act as the pressure valves, voicing concerns that a much larger group may share even if they don't necessarily have the platform or desire to voice them as loudly. Apple's worries will truly begin when the silent developers simply stop developing for the iPhone and take their efforts elsewhere.

The problem with that is that you don't hear it happen.

* * *

There is far more to Paul's post that I have addressed here so, do yourself a favor and read the full article.

Comments