Why Apple keeps iPhone specifications quietIn marked contrast to the PC market, where differention primarily centers around gigabytes, GHz, and Intel Inside branding, Apple is working to keep attention on the iPhone's software, with a curious avoidance of any mention of the make or specification of its internals, apparently for competitive reasons.
The specifications of the iPhone and iPod touch, as well as the internal details of other integrated products sold by the company such as Apple TV, aren't being kept secret to keep competitors from knowing what's inside, as the components are quickly discovered in a simple tear down. Instead, Apple is working to keep consumers' attention focused on what's unique to its iPhone and other devices, which is often the company's unique software, rather than the commodity hardware the company commonly uses and which competitors can much more easily duplicate.
The unique software capabilities of the iPhone, including its ability to run the 50,000 titles on the App Store, is far more important from a marketing standpoint than the hardware specifications of the iPhone that any manufacturer can match or exceed with little effort. The company faced similar issues in working to sell the original Macintosh against DOS PCs, which were marketed primarily as having a given number of megabytes and MHz rather than having the functionality or usability of the Mac's graphical user interface.
Rather than being compared on the basis of MHz and MB of RAM, the numbers Apple would prefer to have consumers and pundits contemplate are the installed base of more than 40 million users, the tens of thousands of apps available from thousands of developers, and the number of free regular updates that Apple ships to enhance and secure the iPhone's operating system. Those are numbers that phones using Android, BlackBerry OS, Symbian, WebOS, and Windows Mobile are hard pressed to match.
While RIM, Symbian and Microsoft advertise sales of more phones than Apple, none of them have a comparably large installed base of modern phones that all run the same software. That's why Apple could compare its iPhone app library against only 5,000 apps for Android, and even fewer software titles for phones such as Nokia's, which sell in much greater quantity but have fractured software platforms where each phone only runs specific titles.
Similarly, Microsoft's highly publicized 50 million Windows Mobile phones are fractured between Pocket PC devices with a full touch screen and those the company referred to as "Windows Smartphones," which have no touch screen and only limited button control. Writing software to take advantage of both form factors requires more work with little payoff for developers.
Apple's cohesive iPhone platform is now being tested to see how well the company will be able to introduce significant new hardware features without similarly fracturing its platform, potentially resulting either in software titles that only run on specific models or, alternatively, a "lowest common denominator" barrier that prevents developers from really using any of the new features.
The iPhone upgrade cycle
Last year, Apple improved upon the original iPhone's hardware by adding key missing features, including GPS and 3G mobile data service. It also added the increased overhead of push messaging and installing and running third party applications and graphics intensive games, without addressing any of those processor intensive software functions with hardware processing improvements.
This year's iPhone 3G S focuses on hardware performance improvements with its faster general purpose ARM and PowerVR graphics processor cores and increase in its internal RAM from 128MB to 256MB. Apple has oddly enough kept the internal specifications of the iPhone hidden, which is curious given the fact that they won't be secret for long once the device goes on sale.
It's also a bit unusual in that specification numbers have long driven purchasing decisions in the PC market, often pointlessly. A decade ago, consumers were so driven by marketing efforts to demand greater clock cycles regardless of actual performance that it coined the term "Megahertz Myth." Intel was eventually forced to back down from its marketing-oriented clock cycle engineering on the Pentium 4 and start over with a new design that delivered real performance and efficiency at lower clock speeds with the Core architecture.
Apple's marketing has focused on the usability and utility of the iPhone, particularly its extensive library of mobile applications on the iTunes App Store. The company is pushing developers hard to ensure that their existing apps work without a hitch on the new model and under the new iPhone 3.0 software release, giving them early access to the golden master version of iPhone 3.0 and allowing a couple days between the new software release and the first sale of new iPhone 3G S. People familiar with the gold master say the included App Store application will identify which applications have been quality tested with iPhone Software 3.0 and which have not, as can be seen in the below image.
Keeping software compatible isn't easy
Last year, the introduction of new hardware features such as GPS did not result in two classes of software, one that required a GPS model and one that could not take advantage of the new feature. Instead, Apple paved over the differences in the platform using hardware abstraction. In the case of GPS, the iPhone's Location Services allowed devices with GPS to obtain more accurate positioning, while devices lacking GPS could still triangulate their position using cell phone towers and WiFi base stations with known positions.
Similar efforts have kept other hardware changes from causing serious software incompatibilities. By making new technologies optional but accessible in the platform, Apple's third party developers can easily incorporate the latest features in the iPhone 3G S while leveraging the large base of existing users by remaining seamlessly compatible. That solves a major Catch-22 that has commonly plagued computing platforms: how to introduce something really new without losing your existing users. Apple has been learning how to do that for over thirty years. It's not easy.
The iPhone OS has to seamlessly manage the new phone's faster processor speed to accelerate the animated interface while preserving proper timing for things that can't run twice as fast, such as video playback and certain animations. While these are fairly elementary aspects of managing a software platform, rival software platforms from Nokia, Microsoft, Google, RIM, and Palm have demonstrated serious problems in delivering both developers and end users a simple, cohesive, and yet progressive platform.
Palm's early design decisions in its Palm OS devices resulted in the platform tanking as the company shifted back and forth on strategies for moving it ahead, ranging from migrating the old interface from the 68000 chip to a new ARM processor without being able to take much advantage of the new CPU, to introducing new operating system revisions that the market and developers simply ignored, such as Palm OS Cobalt 6.0. During all of this the Palm OS was allowed to stagnate in terms of new features.
Microsoft experienced similar problems with Windows CE/Windows Mobile. First, it attempted to support too many hardware configurations, from Handheld PCs to Pocket PC PDAs to several smartphones form-factors, non of which really became popular enough to support a viable software business. The company also chose to make major architectural changes in Windows Mobile that jettisoned support for previous devices' hardware, forcing developers to either cater to a tiny installed base of new models, or the now obsolete market of existing devices.
RIM advertised its new iPhone-like Storm as "the first touchscreen BlackBerry," but it was only a BlackBerry in marketing. It didn't work much like earlier models, didn't run the same software, and developers needed to write all new titles to take advantage of its features. Most importantly, potential developers couldn't benefit from the large installed base of other BlackBerry users, giving them little reason to write apps for it until enough people had bought one, while potential buyers were left to realize that there was no real potential for a wide variety of Storm apps approaching that of the iPhone's.
Managing the platform
Another aspect to keeping technical specifications out of the limelight is that Apple is careful to expose access to hardware components in a manageable, sustainable manner. If developers are allowed to write "to the hardware," the result is a broken platform where the vendor can't move forward without breaking the apps.
Apple experienced this problem in the clever hacks to the classic Mac OS which resulted in destabilizing the system, a problem that got progressively worse after the company sanctioned the system patches in System 7 under the name Extensions. In Mac OS X, reference releases have been plagued by Input Manager hacks that similarly caused some serious compatibility problems.
That has led Apple down the road of a tightly managed iPhone platform where the execution of third party software requires code signatures and sandboxing, and where access to hardware has been roped off until the company could perfect abstracted public access to features in a way that can accommodate new underlying changes as future models are released.
Users shouldn't need to know how much RAM is available to the operating system of a mobile device, or how fast its primary CPU core is clocked at; what they should care about is how usable the device is and what it allows them to do. That's the message Apple is working to control.