apples-mistake.mov

Apple's Mistake

by Paul Graham · November 2009 · 5 min · read the original ↗

chapters

    transcript

    Apple's Mistake. An essay by Paul Graham, November 2009.

    A karma leak

    In 2009, Graham argued that Apple didn't grasp how broken App Store approval was. Or rather, how much that mattered.

    Programmers used to adore Apple; the usual gripe was that its fans admired it too blindly. Now many saw it as evil.

    How much goodwill was gone? Graham guessed a third, maybe half. And the App Store was still leaking it.

    Software isn't music

    How did it go so wrong? Graham's diagnosis: Apple doesn't understand software. It treats apps like the songs it sells on iTunes.

    In music, Apple is the middleman that owns the customer. You play by its rules, and the record labels went along, grudgingly.

    But software tried publishers in the early 1980s, with firms like VisiCorp. It failed: software is too complex for a middleman.

    Yet that's what Apple made itself: a software publisher. And an overbearing one, with picky taste and a strictly policed house style.

    Launch fast, then iterate

    And software has changed. It used to ship in a few big releases. Now it ships as a steady trickle of small updates.

    Apple thinks like a hardware maker: build until it's finished, then ship. But software is easy to change, so it can improve by evolving.

    So long, random delays on every release are a disaster. Programmers don't iterate out of laziness; they do it because it works best.

    Graham turns it around: what if Apple's own urgent OS X fix sat with a gatekeeper for a month, then got rejected over an icon?

    Old, buggy apps

    So Apple gets the reverse of what it wanted: the copy of an app in the store tends to be old and buggy.

    One developer shipped betas almost daily while his store version went stale. Another said a bug fix could wait four to eight weeks for approval.

    So users decide iPhone apps are just flaky, though the same apps run fine on platforms that approve updates at once.

    Why doesn't Apple worry? Suppliers always complain, and the iPhone was selling better than ever. Graham calls that one more misconception.

    Great hardware, uneasy buyer

    For now Apple gets away with it, because the hardware is so good. Graham had just bought a 27-inch iMac, and it was gorgeous.

    Yet for the first time, he bought from Apple with misgivings, the way he'd feel buying from a regime with an ugly human rights record.

    Buying Apple used to be pure delight. Now it felt like a deal with the devil: wonderful machines, from a company he wasn't sure he should support.

    The people they never hire

    Should Apple care about a small minority of its users? Graham gives two reasons. First, they are exactly the people it wants to hire.

    Microsoft learned this in the 1990s. Working there began to feel like selling out, and the real cost was the people it never got.

    Top programmers can work anywhere, so they can afford scruples. And evil breeds stupidity: win by force, and you forget how to win with better work.

    In Apple's famous 1984 ad, a woman hurls a hammer at a dictator on a giant screen. Now, Graham says, Apple looks more like the dictator.

    Developers make platforms

    Second reason: a platform lives or dies by its developers. Apple should know. A spreadsheet, VisiCalc, is what sold the Apple II.

    Programmers build for machines they use themselves. Wozniak wanted a computer of his own; Gates and Allen wrote for little machines they loved.

    Why so many iPhone apps? Because programmers carry iPhones. They may know BlackBerry's market share, but to them it barely exists.

    So they stay, like someone stuck in a bad relationship, eyeing the exit. Palm and BlackBerry offered no hope. Android might, but Google barely cared.

    How the lock could break

    Graham feared another monoculture, like the 1990s, when writing software for users meant writing for Windows. Dread of that had pushed him to web apps.

    What would break Apple's lock? Prying the iPhone away from programmers. You can't out-design Apple, so a rival must win on what programmers want.

    Maybe an app they can't live without that the iPhone won't allow. Best of all: a pocket device that works as a development machine.

    Graham coded on a MacBook Air, about four times too big for a pocket. He thought the gap could close, and asked founders to try: “Wanted: Woman with hammer.”

    In short

    Apple ran apps like iTunes music, as a middleman: a model that fails for software.

    Slow, random review breaks fast iteration and leaves old, buggy apps in the store.

    Lose programmers' goodwill and you lose the best hires and the apps a platform lives on.

    Apple's lock breaks only if programmers carry something else.

    The original is short, and better than this. Read it: paulgraham.com/apple.html