
Third party mobile software success: development tools
Some pundits credit Apple's robust development tools, its market buzz and media attention, or its status as the first mover in its field as being the reason for the company's current success; these factors suggest that a challenger could simply swoop down and take Apple's business away by doing the same thing on a grander scale, an implication that frequently references how Microsoft Windows overshadowed the Macintosh in the mid 90s. None of those factors are really unique to Apple, however.
Apple's App Store success wasn't merely due to the availability of familiar coding tools facilitating new software. If that alone was the key to Apple's success, the much larger reach and far more entrenched ecosystem of third party developers behind Sun's Java ME or Microsoft's Windows Mobile would have resulted in similar success for those platforms. Java has a strong presence in server applications and has been one of the most popular languages and APIs in computing for over a decade; Microsoft's licensed Windows Mobile devices use a different operating system kernel than Windows PCs, but their apps are created using the same tools and very similar APIs to desktop Windows apps. Both mobile platforms have been available for well over a decade, an eternity in tech time.
Microsoft introduced Windows CE (the core OS inside Windows Mobile) back in 1996 with an SDK familiar to Windows developers. It invested lots of effort in making WinCE a viable mobile handheld computer platform in reaction to the 1994 Newton Message Pad, then a PDA platform in reaction to the Palm Pilot in 1998, then a smartphone platform in reaction to the Handspring Treo in 2002, then a portable media player in reaction to the iPod in 2004. Microsoft is now working to build touchscreen handheld devices in reaction to the iPhone and iPod touch. Despite years of massive investment, Microsoft has now reached its 13 year anniversary of WinCE without having attracted the same kind of attention as Apple's iPhone SDK in its first year and a half on the market.
Clearly, just having familiar and functional development tools is not enough, although it is essential. One of the problems limiting the software available for the Newton MessagePad was that Apple delivered largely unfinished and very unique tools that involved a significant learning curve for coders. Both Android and the iPhone provide adequate development tools, although Apple has a significant head start in having shipped its native SDK.
Third party mobile software success: buzz
The iPhone's software success wasn't merely due to favorable buzz either. The Palm OS once created such heady anticipation for devices running mobile software that by 2000, the company's IPO earned $874 million and the fledgling new company (built on a half decade of work within US Robotics and then 3Com) reached a market valuation of $54 billion, twice that of Apple at its own dotcom peak, despite having actual revenues that were only about a tenth of Apple's. That year, the Palm OS was powering 85% of all PDAs as the company broadly licensed its operating system to power some of the first advanced phones on the market.
Palm's unit sales were hovering around 5 million per year, nothing to sneeze at in an emerging market with so much potential. Palm even began licensing its Palm OS to Sony to create a new line of Clié handheld devices. The company also lined up an impressive roster of developers and at one point claimed a library of 50,000 Palm OS apps. And yet Palm's software business never resulted in much actual success for the company or its users, and is now a historical footnote.
Palm's second wind with the Palm Pre and its WebOS this year similarly caught an enormous wave of buzz, but that alone failed to actually result in a sustained success for its second attempt at a software store.
Similarly, Java was once the biggest buzzword ever to grace computing. But while Sun has earned lots of revenues from licensing its mobile version to phone makers, the widely deployed technology hasn't actually created a functional platform nor kicked off any sort of popular and viable marketplace for Java ME developers and phone users with Java ME capabilities, largely because the Java ME platform is so fractionalized between "almost compatible" variants.
It is critically important to generate excitement around a platform, and both iPhone and Android have created lots of buzz. However, Apple has targeted its buzz at iPod users and retail consumers and its own Mac OS X developer base, while Google's buzz has largely been confined to punditry and open source advocates who neither buy a significant number of products nor develop the commercial software that mainstream users want.
Google is not even advertising Android as a brand name. In contrast, Apple now has everyone from broadcast networks to insurance companies to newspapers to rival music services prominently advertising their apps for the iPhone and its App Store within iTunes.
Third party mobile software success: first mover
The iPhone wasn't just first time lucky either. Apple's previous attempt to float the Newton MessagePad in the early 90s as the first mainstream handheld computer platform wasn't successful. Palm or perhaps Symbian could be credited with first mover status in the smartphone industry, yet despite valiant efforts to establish third party development programs, neither has achieved the kind of success Apple has with the App Store.
Danger produced what may be the first functional app store, but could not attract enough third party attention to remain viable. Microsoft purchased Danger and largely dropped it into maintenance mode (without the maintenance), and lots of Danger's original talent has joined Google's Android efforts. However, the ideas behind the innovative software store Danger created have not been put to use by either Microsoft or Google.
Palm and Symbian are now retooling, along with Microsoft's Windows Mobile, to deploy software stores in imitation of Apple. Microsoft's efforts to copy the App Store are lifted clearly from Apple's blueprint, and Windows Mobile kicked off its new Marketplace with thousands of existing developers and their apps created over the past decade and an installed base similar to the iPhone's. Still, Microsoft's store opened with barely a trickle of interest.
The history of high profile failures and reversals of fortune in the mobile business suggest significant potential for Android as a third party software platform, if it can copy what Apple got right and improve upon that. Unfortunately, Google has not copied many of the factors leading to Apple's success, and has instead emulated the course of mobile platforms that haven't done well. The following page outlines how Google's platform strategy differs from Apple in key areas.
Apple's third party platform strategy
First, take a look at what is unique about Apple's mobile software store. Importantly, it builds upon experience and previous successes. Well before it even launched the iPhone, Apple began selling iPod game software on a small scale to work out the kinks in packaging and delivering mobile software securely in a way that avoids casual theft. Apple also perfected micropayments for music and video in iTunes, paving the way for a high volume, low cost mobile software store. Apple also built on its decade of progress in developing Mac OS X as a desktop platform, so it was able to release development tools that were both mature and familiar to a large number of coders. The iPhone's hardware also clearly evolved under the influence of lessons learned during the development of the iPod.
No smartphone vendor is building upon a success similar to the iPod and iTunes, and certainly not Google, which has never before even sold consumer hardware nor the software to power it. Google's Android business plan is firmly in the beta stage of development. In contrast, Apple's "preexisting conditions" allowed it to deliver the iPhone to a primed audience with all the parts in place to enable lush growth in software. Considerable thought had backed up every element of Apple's strategy. Very little was left open to experimentation, even if Apple executives still expressed surprise in the amount and type of interest the store received. The iPhone was building upon a combination of iPod 6.0 and iTunes 7, not a fledgling new beta concept.
Additionally, the company carefully staged the iPhone's deployment to only deliver what it could reasonably achieve. Apple shipped the iPhone for a full year before launching its SDK and store, building up an installed user base of about 5 million users. Once it opened the store, it could unleash a flood of new software and new buyers, creating a tidal wave of positive coverage. The company then continued to rigidly follow its own strategic plans, largely ignoring pundit demands that it do things differently.
As important as what Apple did was what it did not do. The company didn't announce all of its future plans in advance, didn't attempt to instantly achieve feature parity with existing smartphone platforms at launch, and didn't allow third parties to set expectations or minimum standards for its own platform's software titles. Instead, the company frequently surprised users with positive news of new features, deflected comparisons by focusing on the platform's strengths, and carefully guarded how its App Store library developed. That involved taking heat from critics who fumed about yet unknown details, staying silent as pundits assailed the iPhone in specific niches (first in software, then in push messaging, then in hardware peripheral support), and acting out a role as the bad cop in policing app titles while bloggers turned themselves inside out about app rejections and store rules.
In retrospect, the company clearly made the right decisions. Rather than getting bogged down in efforts to explain its strategy, Apple kept its new store perpetually in the headlines with a series of status announcements timed to drop at regular intervals. Instead of desperately trying to defend comparisons of the iPhone platform to Windows Mobile in features or Symbian in reach, Apple focused on the unique value it was adding and its ease of use. And rather than ceding control of the App Store to third party developers, Apple maintained control over its development to avoid allowing the store to develop a reputation of being crass or seedy or sloppy or unfinished or full of nagware.

Third party platform management styles
While Apple was (and still is) roundly criticized for exerting too much control over its App Store, the flip side is that there are no real malware problems and, despite a lot of shovelware, there's lots of quality apps to pick from at reasonable prices. Still, the company has maintained a conservative stance that has frustrated developers who want the platform to move more quickly. Apple initially held back trivial titles and fart apps, hoping to establish a serious streak of software; that restriction has since been relaxed. Similarly, restrictions on mature content have been loosened following the company's unveiling of new ratings support in iPhone 3.0 that enabled parents to set management controls on their children's App Store access.
Apple is still busy hammering out policy in the App Store, and developers are still finding reasons to be annoyed with the company. Rogue Amoeba recently threw up its hands in frustrated disgust after Apple's app approval system flagged its Airfoil app as inappropriately using the company's own trademark icons and graphics, despite the fact that Airfoil was using these in an appropriate way that happens to be supported by Apple on its desktop Mac platform.
The company's task of setting reasonable rules to manage the influx of tens of thousands of new iPhone apps is frequently challenged and critiqued, but nobody in the industry is doing a better job. On one hand, Microsoft is seeking to exert even more control over its own third party mobile software store, asking its developers to pay fees for every app submitted to the Windows Mobile Marketplace and angering developers by denying apps repeatedly, charging new fees each time an app is rejected. This has resulted in stagnation of the Windows Mobile Marketplace, the absolutely wrong thing to do just as sales of Windows Mobile phones to users plummet. By the time the store becomes viable despite Microsoft's crippling rules and micromanagement, there won't be any customers left.
At the other extreme, Google enforces much less control over content or presentation for apps listed in Android Market. While Google reserves the right to block unauthorized distribution of its proprietary Android apps, it doesn't mandate that apps have to look great or have to follow any strict guidelines, and there's doesn't seem to be any sort of restriction on potential third party copyright issues, such as selling emulators designed to run other platform's video games.
This lack of restriction has resulted in clear difference between the apps available for Android and those for the iPhone. Android has become the tinkers' destination, not the place where developers go to make money. This has created a wide gulf between the slick, commercial offerings in the App Store and the experimental hobbyist offerings in Android Market.
Given Android's current installed base, Google can't really erect significant restrictions on software. Even without much management in place, Android's offerings are still pretty bare. The biggest problem for Google, however, is that once its market takes off, the latent problems of permissive platform management will grow into serious problems. Security, commercial legitimacy, and professional presentation are all factors Google seems to think will solve themselves. The history of Windows suggests otherwise.
Sloppy security policy: this all happened before
Unlike Apple, Google's business model is patterned after Windows Mobile, which itself is modeled after the desktop Windows. Microsoft has never exerted much in the way of quality control over Windows developers of any kind. On the PC, this has resulted in a platform that has a legacy of reaching backward to accommodate poorly written third party software. A significant reason why Windows hasn't been able to keep up with the pace of Mac OS X development over the last decade has been that Microsoft faced much more pressure to cater to third parties. Without decisive efforts by its vendor to move things forward, the Windows PC platform has repeatedly stagnated.
One example is Windows Vista's efforts to push the adoption of modern desktop operating system features such as an advanced compositing graphics engine like Mac OS X's Quartz. Vista's new changes resulted in reduced performance and compatibility problems with existing software that initially helped impede its adoption among users, which prevented third parties from leveraging the new features, which prevented users from gaining new reasons to try it. Balancing new features against legacy compatibility has long been a difficult issue for Windows, and promises to be critical problem affecting Android as well. Apple faces this too, but the degree of control it exerts over its platform helps to manage such issues before they can affect users.
Another problem endemic to Windows has been security. The platform's ubiquity, combined with Microsoft's initial naivety about security practices, resulted in a new low in expectations being set for PC users. Users accept security exploits as an inescapable eventuality, are conditioned to install and maintain background antivirus software from third parties, and have no reason to trust downloaded software. Software has always been exploitable; the new problem Windows introduced was a complete lack of any intuitive understanding about how users could protect themselves.
Rogue apps can install themselves for reinstallation in the Windows Registry after being cleaned away, and can hide invisibly in the background. On other operating systems, notably Mac OS X, users are simply more aware of when potentially dangerous things are happening because they must authenticate software installations and are warned about the source of software they attempt to run. The application firewall can encrypt and sign apps to prevent them from being modified without the user's knowledge.
On the iPhone, security has been ratcheted upwards another notch with all software being only available through a trusted source, co-signed by the developer and Apple as trusted parties. If an app goes rogue, Apple can pull it from the store and potentially shut it down remotely by revoking the developer's certificate. Apps can't install in the background and do things the user is unaware of after the app has been quit. Under Android, none of these practices have been applied. Google is running its mobile platform with the same mentality of Microsoft in the mid 90s: anything goes for now and we'll sort of the issues in the future sometime.
Google allows developer to "self-sign apps," which is worthless because anyone can sign their own malicious app. Android developers can also deliver their own apps from any source, so Google has no way to stop the sale of malicious code or to remotely deactivate apps that have gone rogue, such as malware with a time bomb payload or equipped with a viral propagation method. And just like Windows PC apps, Android programs can continue to run in the background and do virtually anything without users even being aware they are running. It took Windows several years before its malware potential blossomed into a full blown global network of spambots and regular virus eruptions causing billions of dollars of damage annually. No problems for Android today does not mean that serious issues will not develop along with Android's installed base.
For Windows on the desktop, Microsoft seemed to think it could simply stuff all this back into the box with some security software patches, but despite concentrated and expensive efforts throughout this decade, it has not been able to stop the widespread problems of viruses and worms on its desktop platform. And while experts like to focus attention on the sophisticated efforts Microsoft has devised to enhance security in Windows Vista/7, the majority of viruses and malware don't need some special operating system access to cause damage. The famous exploits that have targeted the Windows platform to create widespread damage, from Melissa to ILoveYou to MyDoom and Storm, have almost all been user-mode software that tricks the user into starting it and then makes itself very difficult to stop or eradicate. Fancy security features are all worthless in the face of such plain risks.
Apple addressed these security issues head-on in its iPhone software platform, while Google has simply suggested that they won't ever appear, and if they do, that there will be some easy way to clean things up. Microsoft has already spend tens of billions of dollars proving that this is simply not true.
Interestingly, Google's Chrome OS takes a stronger position in security, relegating all "apps" to run in sandboxes within the browser, and simply disallowing alternative apps. This model is much closer to the iPhone's, which similarly sandboxes apps. While Chrome OS simply distrusts all web apps it runs, the iPhone OS accords limited trust based on encrypted signatures. Android currently does neither, although it will likely move more toward the Chrome OS, although that's another year away. Google doesn't have another year to work out a basic security model for Android.
Open to exploitation
Android also shares other problems of Windows and Windows Mobile. One relates to the APIs available to developers. Microsoft is trying to get its mobile developers to migrate toward .NET (the Windows analog of Cocoa), but most Windows Mobile software is still built using the same old familiar Win32 APIs (somewhat comparable to Carbon/Classic on the Mac) that developers have been churning out for the PC desktop since the 90s.
In contrast, Apple created the iPhone to use only one new modern API: its mobile-optimized flavor of Cocoa. It simply gave developers no option to string along Carbon, Java, Flash, or other old API alternatives for building any new mobile applications. The iPhone has one API that every developer uses, creating familiarity and unity in how apps are created in the relatively small community of iPhone development. This makes it easier for Apple to support its developers, advance its platform, and keep control over where the platform is headed. Unlike the Mac, Apple doesn't have to try to accommodate Adobe's terrible version of Flash, for example, which results in most of the system problems desktop Mac users face on a daily basis.
Google introduced Android as a modified Java platform. It's now in the process of rolling out a native SDK for accessing the core OS. This means developers will have two official APIs from Google to weigh for advantages and disadvantages. Additionally, Google is supporting the development of runtimes to host Flash apps and Mono/.NET applications. This will enable Android to "run more code" at the expense of anyone needing to develop software expressly for Android. Why not write generic Flash games that can also be sold to users on BlackBerry, Symbian, and Windows Mobile phones? Why not target .NET instead of the Android SDK and develop software for two platforms? Why not just write Java applets and ignore the native SDK? There's a lot of options on Android.
Google seems to have forgotten the history of Sun's partnership with Microsoft, which was portrayed as a way to get Java on Windows, and instead became a way to tie Java to Windows exclusively, killing it everywhere else. When partnering with rivals, you have to make sure they aren't simply using your resources to do what they want to do. Google hasn't yet been victimized, as its naively simple approach to platform openness demonstrates.
If any company has learned tough lessons about the consequences of allowing third parties and rival vendors to hijack or destroy one's platform, it's Apple. In the last 30 years, it has fended off companies trying to clone the Apple II and the Macintosh, watched as Microsoft hijacked its own Mac apps to create Windows, and ineffectually chased after Sun's Java buzzword. But in the last decade, Apple has figured things out. You don't give away your platform if you expect it to remain around as a viable contender. You don't allow third parties to put you out of business, and you don't funnel your success toward rivals, unless you're in the business of giving away technology for free and closing up shop.
Google's permissive openness to everything betrays a great deal of naivety in its attempts to develop Android as something more than just another mobile alternative. This is because Google isn't serious about building a platform it controls; Google was only out to thwart the success of Windows Mobile in order to ensure that Microsoft wouldn't block its ads and search aspirations on mobile devices. If Android kills Windows Mobile and still fails on its own, Google still accomplishes its goal, and the company will happily continue supporting its Google apps on the iPhone, BlackBerry, Symbian, WebOS, and wherever else it can without direct competition for ads and paid search (as Apple, RIM, Symbian, and Palm are not in the ad and paid search business).
In contrast, if the iPhone were to fail as a platform, Apple would be completely out of the smartphone game. This is why Apple is fighting relentlessly to manage the future of its platform, while Google is simply keeping Android around as a hobby to see if it works out. This makes Android a lot like Apple TV; if that product fails for Apple, it can simply give up and begin licensing iTunes playback on the Wii and PlayStation 3 and Xbox and third party TVs. Apple doesn't live and die on Apple TV revenues, and doesn't really even make any money from its sales, so the thing is a hobby that gets just enough attention from the company to exist. Just like Google's Android.
How have these policies affected the real world software offerings in the App Store and Android Market? The following page outlines how the two stores compare.
Third Party Apps: iPhone
The result of Apple's iPhone App Store strategy of incremental advancement, building on the success of the iPod and iTunes, combined with its relentless efforts to manage its third party software platform and police it from both malware attacks and from third party hijacking efforts has resulted in the top destination for both developers and users. But all is not rosy, despite Apple's great initial success.
Apple restricts third party developers from creating apps that duplicate bundled app features in ways the company says will create confusion for users or for the platform. So, for example, while there are Webkit alternatives available to the Safari web browser, there are no rival third party browsers based on Firefox/Fennec, Opera, or Internet Explorer. Apple hasn't yet rejected any rival browsers, but the lack of any demand for an alternative web browser has prevented third parties from investing in the efforts required to begin one. It is still unknown if Google would bother to port Chrome, its own Webkit browser, to the iPhone to rival Safari, but the advantages to and motivation for Google to do this are pretty minimal. Mobile Safari already defaults to using Google's search, so there's no business reason for Google to compete against it.
Unlike Microsoft, which simply annexed third party developers' businesses to take over more and more of the existing applications markets on Windows PCs (starting with WordPerfect and Lotus 1-2-3 and continuing with Netscape and Java and QuickTime and Borland and Notes and RIM's BlackBerry Enterprise Server and so on), Apple has defined its own complete platform and given third parties a limited playground to add their own value outside of that. This is similar to Apple's Mac OS X strategy, where the company has created suites of first party apps which face little competition: bundled apps like Mail, Address Book and iCal; iWork productivity apps; and iLife creative apps.
Apple's third party developer issues
Apple's management style on the iPhone has also raised some ire among developers and users who would like the ability to install programs that work in the background just like Apple's own bundled apps can. Apple partially addressed elements of this need with a centralized Push Notifications System, but there's other applications that this feature does not address. Services like Pandora radio or VoIP apps or user location tracking apps such as Google Latitude all want to sit in the background and continue to work while the user does other things. Apple currently doesn't allow any of these things.
The company says the downside to allowing these types of features relates to battery life and system performance, and that it would also open up the platform to new types of malware attacks. Apple's current strategy to simply outlaw such practices has indeed prevented predictions of iPhone malware attacks from ever materializing. Certainly, any news of a real malware or spyware threat on the iPhone platform would outweigh the ability of iPhone users to constantly report their current position to Google so that friends could see where they were.
Google's Android platform doesn't have a malware problem yet, but it also has nowhere near the installed base of the iPhone. Both will grow together. If a high profile viral or spyware attack were to hit Android phones, it would cause a serious black eye for the platform that simply being able to run Latitude wouldn't make up for.
Apple's third party pricing model
In addition to efforts to block malware, Apple's security system for iPhone apps also greatly limits casual theft. This results in a broad, viable commercial market for iPhone apps of all kinds, supporting the high volume sale of software priced very low. Mobile developers have previously needed to set their app prices significantly higher in efforts to get something from the minority of users who actually pay. By spreading costs equally among all users, Apple has created a software store where users reward innovative development with dollars. In contrast, RIM and Microsoft have encouraged higher price points for software in their respective stores, hoping this will benefit developers. At this point, it only discourages users from buying new apps.
Similar to its sales of music and video in iTunes, Apple has deliberately set prices low to kill off rival efforts at short term profiteering. As a result, it erased the business model of rivals trying to rent music or raise song prices. The App Store uses the same low cost pricing strategy in mobile software to expose the overpriced ringtones and rental software that providers like Verizon have tried to market in the past. By keeping prices low and sales volumes high, Apple will effectively prevent other stores from turning a profit until they can either build up a similar installed base or raise their software prices, both of which are very difficult to do at this point. Software stores that actually want to compete will have to follow the course of Amazon and lower their own prices; the problem is that unique mobile software is much more difficult to create and sell for cheap than existing music and movies that have been licensed from a label or studio.
Finally, Apple's vigilant efforts to siphon all iPhone development through its own Cocoa tube has exercised Apple's own development platform and dealt a serious blow to Java ME, Flash and .NET as lowest common denominator development tools instead. All the excitement Apple has created around its own mobile platform has directly benefitted its own tools (something that spills over to benefit desktop Mac development as well) and its own software store (as Cocoa apps for the iPhone aren't trivially ported to other mobile platforms). This compounds every dollar Apple invests into the iPhone, creating a halo cloud around iTunes, the iPod, and the Mac as well.
Third Party Apps: Android
Android users hope that Google's openness (including allowing unsigned software from any source to run in the background) will result in a broader, more varied mobile software market than Apple's. This certainly has enabled Android to pick up the efforts of developers who can't sell their software to iPhone users due to Apple's rules. However, Google's ambivalence to the needs of serious, commercial development has also prevented mainstream developers from flocking to its mobile platform. Currently, Android has both lots of what the iPhone lacks, but very little of what the iPhone boasts.
The biggest problem for Android is that is it far behind the iPhone in market share and installed base. This problem is supposed to be resolved quickly as more phone makers release Android phones. However, the already fractionalized market for Android apps is becoming more and more divided as vendors release phones with unique features that tug at developer's attentions.
The new Verizon/Motorola Droid, for example, sports a very high resolution screen that begs for specialized development. However, the more popular HTC Android phones already on the market have conventional resolution screens, meaning developers will have to choose between targeting one or the other, or duplicate their efforts to reach an combined audience that is still a tiny fraction of the size of the iPhone.
Android version control
Additionally, as new Android phones are released with new versions of Android that last year's phones can't even install, the installed base of Android will fail to compound. A key facet to Apple's App Store success is that virtually all apps run on any model of iPhone ever sold, not to mention the iPod touch, which is now adding another wide swath of users to Apple's App Store installed base. The continual churn in differentiating features being sold among Android hardware makers will work against any snowballing of Android market share into a greater installed base. Instead, the modern installed base will keep resetting to zero, just as Windows Mobile repeatedly did as new versions appeared which only worked on new phones.
And while Apple has cleanly deployed new operating system features at annual intervals, Android's development is managed more like Linux, where new platform features are incrementally advanced, starting with partial support and gradually getting to the point of being refined and usable. This is another factor that works against a cohesive installed base, as different vendors introduce phones with different versions of Android, each with proprietary add-ons and modifications that prevent predictable upgrade cycles. The mainstream version of Android will always lag behind the latest version of Android, unlike the iPhone market where phones are rapidly pushed to the latest version under Apple's control.
Google offers its Android software to any maker, but it works exclusively with certain manufacturers to develop new phones that show off the latest features, a decision that continually undermines the efforts of other partners. HTC was Google's first major partner with the T1 running Android 1.0 and then Hero running Android 1.5. But when Google released Android 2.0, it did it in an exclusive arrangement with Motorola that made HTC's existing phones look dated and old. Even Sony Ericsson's new phone is expected to run Android 1.6 next year. That not just an issue for hardware makers, it's a problem for users and developers.
Android is for hobbyist shareware
Combined with the problem that the main attraction to developing for Android revolves not around commercial viability, but rather around ideological demands for unrestricted development freedom, this has resulted in a hobbyist developer base that has produced a library of software that looks a lot like what's available for desktop Linux users: homebrew games and niche apps that were shared by their original developer rather than titles reflecting the demands of users.
Just like the problem of its fractured installed base, this hobbyist developer community is poised to create more problems than time can work out on its own. Users who buy a T-Mobile G1 or HTC Hero or Motorola Droid in preference to the iPhone will quickly discover that Android apps aren't just a growing subset of those available for the iPhone, but a completely different type of selection.
Writing for TechCrunch, a site that frequently advocates for Android, Jason Kincaid admitted, "If there was a theme common to nearly every Droid review, it was that Android's app selection just doesn't cut it compared to the iPhone."
He added, "reviewers are finding that Android has a weaker selection of applications than the iPhone not just because some of their favorite apps aren't there, but because actually browsing the Market just isn't as enjoyable as what Apple's iTunes offers." Kincaid went on to recommend that Google completely redesign the Android Market to work more like iTunes.
Reading Android forums, you'll get the sense that one of the most popular Android apps is TasKiller, a utility to stop running apps in the background to free up system RAM, similar to Task Manager on Windows Mobile. That's the app that Scott Forstall, Apple's senior VP of iPhone software, boasted that iPhone users wouldn't have manually manage. He referred to it as a game that tests users' computer science skills in identifying programs that are safe to kill.
There are other major differences in what's available in the App Store compared to Android Market. For example, despite having around ten percent of the number of titles of the App Store, Android has no significant, advanced games. In fact, it really doesn't have any great games at all. But this isn't just because of Google's Android Market hobbyist-oriented policies and casual platform management.
200MB should be good enough for anybody
Android Market has no real games (or other significant apps) because the platform was designed around phones with a tiny amount of storage for apps, the same specification that most Windows Mobile phones use. That's because Google didn't really create a modern reference design for Android phones, it just made its Android software work on the existing Windows Mobile reference designs that Microsoft created. It should not be a surprise that Android leader HTC is a Windows Mobile shop, and that the Motorola Droid originated as a Windows Mobile device that was co-opted to serve as the flagship for Android 2.0 via Verizon's marketing budget.
All commercial apps for Android phones currently have to fit into the 256MB of onboard storage (512MB on the Droid), a limit in both phone design and in Android software. Since Android itself uses up most of this memory (the 512MB Droid has about 200MB free after loading Android 2.0) this limits users to theoretically installing a maximum of 20 apps at around 10MB each. That's a pretty severe limitation, but a ridiculous roadblock for games that are anything more than doodle puzzles.
The iPhone and iPod touch supply at least 8GB of storage, which is 32 times as much memory as most Android phones provide. Considering that a game can easily weigh in at tens of megabytes (Aurora Feint is 41MB; SimCity is 30MB; Spore Origins is 98MB; Super Monkey Ball is 125MB; Apple's Texas Hold'em is 130MB; Modern Combat: Sandstorm is 271MB; Monkey Island is 426MB; Myst is 727MB), plenty of iPhone-quality games couldn't even load on an Android phone, let alone install along with a dozen other sophisticated games.
From the start, Apple created a design wholly independent from other smartphone makers. Rather than shipping a device with the least amount of storage possible and including an SD card slot, the company used its massive iPod leverage in buying Flash RAM to pack the iPhone with plenty of storage, something that other vendors only began to do later. Even today, few vendors provide nearly as much RAM storage as the iPhone 3GS. The BlackBerry Storm 2 only provides 2GB of onboard storage. The Palm Pre uniquely packs on 8GB, an indication that Palm inherited the influence of Apple's iPod hardware developer.
讨论
把此链接加入于...
与朋友分享
已已沉
评论/ 意见