:format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/33831757/115288537.0.jpg)
Longtime Apple-watchers had a sense of deja vu Monday when Apple's Craig Federighi announced iCloud Drive, a new product that will allow users to store files and keep them synchronized across all of their devices. The product is a direct challenge to products already on the market such as Google Drive, Box, Dropbox, and Microsoft OneDrive. But it's also uncannily similar to iDisk, a cloud-storage service that Apple released in 2000.
iDisk was introduced as a free part of iTools, Apple's first online service. iTools was re-branded as a paid service called .Mac in 2002, and then rebranded again to MobileMe in 2008. The frequent rebrandings reflected Apple's struggle to find a successful formula for its online services. iTools and .Mac didn't catch on with users, and MobileMe suffered from serious performance problems. Steve Jobs acknowledged in a 2008 email that MobileMe was "not up to Apple's standards."
Apple rebranded its online offerings once again in 2011, re-christening them iCloud. And in the process, the company dumped iDisk. iCloud would sync users' music and calendars, but it didn't offer generic file-syncing capabilities. Now, three years later, Apple is essentially bringing iDisk back.
Why Apple is bad at online services
So will iCloud Drive do better than iDisk did? I wouldn't hold my breath. Developers have vented their frustration with the other components of the iCloud service. Apple's corporate culture seems to make it congenitally bad at building fast and reliable online services.
Apple's poor track record at creating online services is a reflection of the same design-focused development process that allows Apple to create beautiful gadgets. Apple obsessively focuses on the user experience, ensuring that everything the user sees and touches is excellent. Apple tries to make a perfect product before it leaves the factory.
That works great for designing gadgets like the iPod and iPhone. The problem is that creating reliable online services requires paying attention to a lot of details that aren't apparent to the user, and in many cases can't be predicted in advance. Services like iCloud depend on a lot of complex behind-the-scenes infrastructure that can't easily be tested in a laboratory.
A key issue is what engineers call scalability: an online service that works flawlessly when tested by 100 people may grind to a halt when it has to serve a million real users. There might not be enough servers to handle all the load. There might be key unexpected bottlenecks that only become apparent when the service is used "at scale."
Scalability isn't an issue for a gadget like an iPod because there's just one user, so Apple's intensive pre-release testing is a good way to make sure the product is ready for market. But no amount of pre-release testing will reveal scaling problems, because by definition these problems only become apparent when the system has millions of users.
A different approach
Companies like Google or Facebook that specialize in online services take a different approach. They do some pre-release testing, of course, but they're also organized to ensure rank-and-file engineers can think on their feet. That allows them to jump in and fix scaling problems as they're revealed in real-world use. That requires a flexible, decentralized structure — exactly the opposite of Apple's tightly controlled and regimented approach to product development.
Could Apple re-organize itself to become better at online services? Perhaps, but doing so could undermine the very thing that makes Apple great today. Apple's rigid hierarchy is what allows Apple to produce the elegant, minimalist user interface of its products. If Apple tried to adopt Google's free-wheeling engineering culture, it might wind up with the cluttered and confusing interfaces that too often characterize Google products.
Building beautiful gadgets and building reliable network services are different problems that require different kinds of organization. It may be impossible for a single company to master both.
