The culprit, ultimately, is Apple's corporate culture. Apple is a designer-centric company that obsesses over every facet of the user experience. That user-focused philosophy makes Apple the best in the world at producing sleek hardware and beautiful, intuitive user interfaces. But that same design- and user-focused approach becomes a liability when it comes to building network services that require attention to detail in areas far removed from the user interface.
Try, try again
In 2000, Steve Jobs announced iTools, a suite of online services that included iDisk, a precursor to Dropbox. The service was rebranded .mac in 2002, rebranded again as MobileMe in 2008, and was finally replaced by iCloud in 2011.
These services have been plagued by reliability and performance problems. In 2008, shortly after the launch of MobileMe, Steve Jobs called a meeting of MobileMe developers. "Can anyone tell me what MobileMe is supposed to do?" Fortune quotes Jobs asking. After someone described how MobileMe was supposed to work, Jobs asked: "So why the f**k doesn't it do that?"
Apple hasn't fared much better with iCloud. The service had many of the same launch problems MobileMe did; my colleague Hayley Tsukayama reported that iCloud was plagued by "service disruptions," and that "users had reported problems with authenticating their accounts and accessing their Mail and Notes." So far this year, Apple has had major outages in February and August.
Running online services is hard, but it's not that hard. For example, Google has a much better track record. Apple's outages are often measured in hours, while Google's are more likely to be measured in minutes. Recent Apple outages have affected 1 to 3 percent of users. One of Google's most serious outages affected 0.02 percent of users.
"The designers speak for Steve"
"In concept, [iCloud] is pretty simple," a mobile developer told Ars Technica earlier this year. However, "a lot has to happen behind the scenes. What we casually refer to as iCloud is many parts, each with a role to play."
If any one of those parts fails, the whole service will grind to a halt. To avoid that, Google organizes its engineers into many small teams and gives each team the resources and autonomy they need to make sure their corner of Google's vast software infrastructure will be efficient and reliable. Google executives avoid micromanaging their employees. Instead, they obsessively measure everything they can, and hold teams responsible for their performance.
This decentralized approach is a liability when it comes to user interface design. With engineering decisions being made from the bottom up, there is often no one to make sure that Google apps have simple, consistent interfaces. As a result Google apps are often cluttered and confusing.
Apple takes the opposite approach, starting with the user experience and working backward toward technical decisions. Apple CEO John Scully has said that "the designers are the most respected people in the organization. Everyone knows the designers speak for Steve because they have direct reporting to him."
That kind of hierarchical structure, with engineers subordinate to designers, can produce beautiful, user-friendly products. Designers can intensively test the user-facing aspects of a new product, making sure that the software feels responsive, that menus and buttons are logically organized, and that an entire product has a consistent visual vocabulary.
But this kind of top-down, design-focused testing isn't going to uncover problems with network services. A system that might work flawlessly with a thousand users can grind to a halt with 10 million. Making engineers subordinate to designers may make it difficult for engineering teams working in the depths of Apple's infrastructure to get the time, autonomy, and resources they need to make their services bullet-proof before they're released to the masses.
When Apple is developing the next iPhone, it can hire a small army of design-focused testers to make sure that every aspect of the user interface is up to Apple's standards. The product will work for consumers basically the way it did in the lab, so this style of testing works well.
But no amount of pre-release testing will uncover bottlenecks in the infrastructure that makes iCloud work. Making reliable network services requires different techniques. Those techniques come naturally in Google's engineer-centric culture. But Apple's development process, honed by years building iMacs, iPods, and iPhones, simply aren't well-suited to the task.
Do one thing and do it well
There probably isn't much Tim Cook can do about this. I made a similar argument in 2011, and there's no sign Apple has gotten better at cloud computing since then.
Corporate cultures change slowly, and no company is good at everything. Microsoft dominates the market for corporate IT software. But it has struggled to compete both on Apple's turf of consumer-focused mobile devices and Google's turf of online services. For its part, Google's efforts to ape Apple by producing its own Android devices have largely fallen flat, as has its effort to challenge Facebook with Google Plus. Each company is built to do a specific thing extremely well, and each company struggles when it ventures outside its comfort zone.
So you shouldn't expect Apple to conquer its problems with cloud computing any time soon. And if you love Apple's gadgets, you should hope they don't. Because the characteristics that allow Apple to produce great hardware devices are a major factor in the mediocrity of its online services.