Windows Phone 7 App Store Still Lags Behind Apple, Android

Microsoft has bragged about its growing app store for Windows Phone 7 devices, but the store's offerings are still puny compared to Apple's or Google's stores. The Windows Phone 7 app store has around 10 times less apps than the Android Market and around 30 times less than Apple's App Store. Will Microsoft ever catch up?

Since the store's introduction, Microsoft says that out of the 11,500 apps for the Windows Phone 7 platform, 7,500 are paid apps from around 36,00 developers. Some analysts are predicting Windows Phone 7 will boom in the coming years, overtaking the iPhone by 2015, but the outlook, at least for app stores, is not that bright.

For example, Apple reached the 100,000 apps milestone for its store in 15 months. Microsoft will be hard-pressed to hit that mark by the time it celebrates the 15-month anniversary of the Windows Phone Marketplace in January 2012.

The discrepancy between Microsoft's and Apple's app stores grows ever more when looking at the more than 350,000 apps in Apple's store. The Apple App Store has more than 30 times more apps than Microsoft's.

Even Google, which is activating more Android devices than Apple does iPhones lately, is having trouble catching up with the iOS app store. The Android Market has around 150,000 apps, less than half the amount of apps for iOS. The contrast between Google and Apple is starker in the tablet area, where Android has dozens of Honeycomb apps, while there are more than 60,000 for the iPad. Regardless, the Windows Phone 7 app store has still 13 times less apps than the Android Market.

Meanwhile, Microsoft is taking the playground route to fight Apple's App Store supremacy: they're taking them to court. Microsoft started the fight in January, when it asked the U.S. Patent and Trademark Office to deny Apple's 2008 trademark application for the term "App Store." Apple is fighting back against claims that the term is too generic to trademark, and says that Microsoft should know better.

Technorati Tags: WP7, Windows Phone 7, Microsoft, Apple, iPhone, iOS, Android, Google, Smart Phone, Mobile Phone, App Store, Android Market, Market Place, iPad

Android

First of all, as Dan Morrill memorably explained in On Android Compatibility, “Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device.”


Linux · Underneath everything is a reasonably up-to-date Linux kernel (2.6.32 in my current Nexus One running Froyo), with some power-saving extensions we cooked up; the process of trying to merge this stuff into upstream Linux has been extended and public and is by no means over.

Android runs on Linux, but I’d be nervous about calling it a distro because it leaves out so much that people expect in one of those: libraries and shells and editors and GUIs and programming frameworks. It’s a pretty naked kernel, which becomes obvious the first time you find yourself using a shell on an Android device.

If it were a distro it’d be one of the higher-volume ones, shipping at 200K units a day in late 2010. But nobody counts these things, and then there are a ton of embedded flavors of Linux shipping in unremarkable pieces of consumer electronics, so there’s a refreshing absence of anyone claiming to be “the most popular Linux”. I like that.

Dalvik · The next big piece is Dalvik, comprising the VM and a whole bunch of basic runtime essentials. Its design is fairly unique, and judging by recent history, seems to be working out pretty well as a mobile-device app substrate.

All the standard APIs that you use to create Android apps are defined in terms of Dalvik classes and interfaces and objects and methods. In fact, some of them are thin layers of Dalvik code over native implementations.

It’s possible, and common practice, to call back and forth between Dalvik and native code using the JNI protocol, which is a neat trick since what’s running on Dalvik isn’t anything like Java bytecodes on a Java VM.

How It’s Generated · Native code is currently produced more or less exclusively by compiling C or C++ code; but there’s no reason it has to be that way. Dalvik code is currently produced by generating Java bytecodes and translating them; but there’s no reason it has to be that way.

I want to emphasize this point a little. Android apps are defined as code that runs on the platform and uses the APIs. As long as an app does these things properly, it’s really nobody’s concern how it got generated.

Special Apps · The picture is a little misleading, because some of those Dalvik-based apps are provided by Google and sometimes are seen as “part of Android”. I’m talking about the Dialer and Contacts and Calendar and Gmail and Chat and so on. Most of them are open-source and replaceable (and have been replaced by handset makers); a few are closed-source and proprietary, like Google Maps and Android Market.

That Open-Source Thing · In the big picture above, most of the stuff in green is Apache-licensed. The rest is a mixture of GPL and LGPL and BSD, with some Apache in there too. This excludes some low-level device drivers and of course the majority of non-Google apps, which are closed-source.

The Framework · This is the stuff that uniquely defines Android; more or less everything that Google wrote and you wouldn’t expect to find on a reasonably-configured GNU/Linux box. Its proper use is the subject of all the many pages on display at developer.android.com and of endless mailing lists, sample sites, and a growing number of books.


Libraries · The word “standard” here means “generally available to programmers working in an open-source environment”. The picture isn’t comprehensive.

Quite a few people, including me, have over-emphasized the role of the Harmony libraries. To start with, the Android selection excludes lots of stuff, for example AWT and Swing and OMG CORBA; all superfluous for apps using the Android framework.

Also, just counting roughly by code bulk of all the sort of stuff in this picture, the Harmony code comprises less than half the total. I don’t want to diss Harmony, they’re a wonderful project and I’m a huge fan; but it’s inaccurate to give the impression that Android is just Dalvik plus Harmony.



What’s In an App? · An Android app lives in what’s called an APK, which is simply a ZIP file, with a particular internal file layout that allows it to be run in place, without unpacking. There’s nothing magic about them, you can email them around and drop them on USB keys and extract pieces with unzip.

The Android Manifest is the interface between an app and the Android system, and that’s all I’m going to say here because it’s a key piece of the puzzle and deserves lengthy discussion if any at all.

The resource bundle contains your audio and video and graphics and so on, the pieces that come with the app as opposed to being fetched over the network.

Native or Not · Most apps these days are written for Dalvik. When I say “most apps” I mean “everything that isn’t a game”; game developers typically want to code in C/C++ and that’s it. Dalvik offers a nice fast gateway to OpenGL and all the phone’s hardware, but game devs just don’t want to hear about virtual machines, so they use the Android NDK.

If you’re writing code in the Java programming language you can use Eclipse and a pretty nice toolchain that makes the barrier to entry remarkably low. If you’re coding to the NDK, you’re going to be doing a lot of the build-time machinery yourself and living without some of the nice debugging and profiling candy, not to mention signing up to port your code to other CPU architectures if they run Android and have lots of users. But game developers revel in pain.

And that’s what Android is · Hope you liked the pictures.

Source: http://www.tbray.org/ongoing/When/201x/2010/11/14/What-Android-Is