Quality by Design through Apple's App Store

Anytime you try to impose a quality control standard on a group of professionals, they wail and scream. This happened when Dr. Peter Pronovost tried to have ER doctors follow a simple five-step checklist for inserting a central line into a patient. The mere fact of the checklist insulted their professional sensibilities and they resisted vociferously. Until the state of Michigan, impressed with a trial run's results at Johns Hopkins, adopted the Pronovost Checklist and gave nurses the authority to body-check doctors who didn't follow the procedure, backed-up with support from the administration in case a doctor tried to make life hard for the nurses who followed through.

The average infection rate from central line insertions in Michigan hospitals, statewide, went from 15% to zero.

But doctors are certified by a rigorous exam and 8+ years of intensive education and on-the-job training. Software developers, like, read a book or something. Some have degrees in software engineering, but they're outnumbered.

Apple's App Store is analogous to Pronovost's checklist, but it has advantages that developers should take advantage of to make their software better and more profitable. There has indeed been a considerable amount of grumbling, for two major crimes:

A review board has to approve every app

You can't use a meta-platform

Crime #1 lengthened time-to-market and put investments at risk, because a product could be rejected for what seemed to be Apple's whim. Crime #2 meant you couldn't use your wubby blanket favorite language or platform to author programs with. However, from a quality perspective, both points are absolutely groundbreaking in the software development industry, and quite possibly one of the most important advancements since managed languages.

I shall now use hyperbole: these two policies are going to make the iPhone OS platform kick the shit out of Android and go on to fuck the Prom Queen. In the process, it will make software development join the same ranks of respectability as civil engineering.

Eliminating causes of mass defect

Banning the use of meta-platforms, which come in the form of cross-compilers such as Adobe's Flash-to-iPhone and MonoTouch, but also in interpreters, means eliminating a huge source of recurrent defects in both implementation and design. So does banning the use of unpublished APIs, which are unpublished precisely because Apple isn't convinced they are the best way to deliver the function yet.

The ban on cross-compilers is the most recent that Apple has imposed, as I write this, and many developers are quitting teh fandom forevar. Well, to those guys, don't let the door hit you on the way out. Meta-platforms do three bad things:

They replicate the same bad design decisions and bugs across every piece of software they infect

They spend the phone's RAM, CPU and battery to deliver abstractions that are only valuable to the developer

There's also a fourth reason seen by John Gruber: that they take away control of the platform from Apple. If they advance the core platform then nobody will be able to take advantage of it until the interpreters and cross-compilers catch up. This is a business problem and a user experience problem.

But it's also a development problem. Abstractions may be the key to good software, but only when they're designed in support of the software's function. Abstractions that only support the developer come at a cost to the quality of the product, and while we need them--and readily pay that price to get products to market quicker--we must also keep them at a minimum. Meta-platforms are an unnecessary layer; we should not be eager to distance ourselves from the real platform, it has not been improving quality, only quantity.

The majority of the developers who've come to the iPhone platform have never done embedded systems programming before, and it's important that they get used to the restrictions. Cross-compilers cannot do the level of optimizations that are necessary for a good user experience (and a long battery life). You can't slosh resources around, fat and happy, like you can on a desktop computer. Coming to the world of pocket-sized battery-powered devices is certainly going to feel like a slap in the face, but not the way Lee Brimelow thinks.

It's time to learn how to implement your ideas in the same Turing Equivalent environment that everybody else has. It's not even like it's a bad one, either.

Enforcing basic quality

Forcing products to go through a review process is a step that has been desperately needed in the software industry since the beginning, and any review process--even young ones with staff who are just beginning to learn how to do this difficult job--is better than none.

The software industry has been trying to fix its problems with something called methodology, which says that development practices are the key to software quality. This is only half right, because while the developers may have instituted quality control at the source, there has never really been a complementary force acting on behalf of the user. The marketplace is not a satisfactory agent either, because it doesn't decide by product quality alone. What we've needed is an equivalent of the Underwriters Laboratories for software.

Apple's App Store is not a complete solution, but it's right for the level it operates on. It ensures the basics:

Does it, like, actually run?

Will it harm the customer?

Can the customer expect to use it?

Will the customer be able to use it in the future?

Apps are being eliminated because they're too buggy to run properly on the review board's test platform, because they harbor malware, because they require special access to restricted services, and because they use APIs that aren't fully baked yet.

Apple's criteria also eliminate apps for having adult content, which is not so much about protecting the user but of protecting the marketplace they're building, and I'll talk more about that later.

The sub-platform and unpublished APIs

For those wanting to implement an API that will be used widely, one could only dream of being able to thoroughly test the API and its assumptions in the wild before committing to it. Usually it's the other way around: you commit to an API and then you test it in the wild. Apple is adamantly doing the former in the interests of both users and developers. Apple is making use of unpublished APIs in its own products, but denying their use to third-party developers at first. The original iPhone had no SDK, and then there was an SDK but it didn't have everything, and then a new SDK brought more, and now the 4.0 SDK is even better.

This is how it should be done. Even though third-party developers are forced to develop for a sub-platform, perhaps in perpetuity, that sub-platform is a finished product that's superior to any API experience we've had on Windows. API rot has forced Microsoft to re-invent its API dozens of times, most recently as .Net, and it keeps forcing developers to abandon entire codebases and re-write their work from scratch. Even Apple has been forced to do this in the migration from Mac OS Classic and Carbon to OSX and Cocoa. We won't ever stop running on this treadmill, but Apple is showing that it can be slowed down to give quality time to catch up without suspending progress.

It is hard for non-API designers to appreciate how important this step is. Where Microsoft and RIM both thought it was obviously beneficial to let apps run in the background of a battery-operated device, Apple waited and cogitated. The design that it has now brought to the phone had already been tried out with the iPod and phone apps, and gradually extended so that the functions which interest the user can be implemented without costing him a prematurely dead battery. The other phone platforms do not have this finesse, and they are going to suffer for it.

The money

Apple's decisions are in service of both the user and its own business, and a smart developer can take advantage of them to improve his lot, too. The App Store has made it possible for unemployed programmers coding on a laptop on their couch to reach a market of tens of millions and make hundreds of thousands of dollars within a few months. The cost for entering such a market are something in the ballpark of $99/year, plus hardware. Considering the size of the opportunity, it's unprecedented.

By enforcing basic quality, Apple has made the App Store an impulse-buyers paradise, directly improving everybody's bottom-line. Try seeing Apple's restrictions, then, not as encumbering you with any limitations, but as preventing jackass developers from spoiling this rich and growing market with software pollution.

Programmers like Paul Graham lament the loss of the rapid-iteration model that served him well in the web application market, others are losing their shit because they can't write iPhone apps in Lua. But they are not trying to see the value-end of the trade-off. Apple has eliminated a barrier-to-purchasing (fear, uncertainty, doubt), by converting it into a barrier-to-entry for the developers. If you don't see how valuable this is--profitwise--then perhaps commercial software development isn't for you.

Consider a longer product cycle to be a blessing: these are cell phones (for crying out loud), they have a fraction of the resources of a desktop computer running a modern browser. Using them is hard, in spite of Apple's improvements, because the screens are tiny and the input device is a clumsy sausage of flesh. It's a pain in the ass to keep updating the apps you've installed because the developer forgot to implement the save function or something.

This means you should embrace the longer development cycle and take advantage of the fact that your competitors have the same constraint. Take the time to finish it. Contrary to what the pundits say, most users do not enjoy being your unpaid QA staff.

Apple did not have to extend this product to third party developers. It was making a sizable profit on a phone that was, out-of-the-box, the best phone in the world. Now it's let the rabble in, and they're acting--to be blunt--like pompous dicks.