Long post previously posted on G+ as well, but I'm feeling the need to rant in multiple places the further I get into Google Play.

I'm developing a mobile app using Flex to speed the cross-platform development cycle. So far, so good: Flex is a productive environment, and the app looks and behaves very nicely. Had we gone with native implementations for each platform our release cycle would be considerably lengthened.

Now for the fun parts. While Flex takes care of most of the issues dogging cross-platform development, like basic network functionality, display issues, hardware interaction, and so on, there are still some things that are left to the developer.

For example: on iOS the developer is responsible for marking application data files as no-backup if they are not user-created; this includes cached data, cached images, and other non-essential information. There is no built-in Flex functionality for this so it's up to a native extension to make it happen. Not that big of a deal.

Another example: push notifications. Again, there are free and commercial extensions (or roll your own if you hate the principles of reuse ;-) that can take care of this functionality, given proper support on the server (or Urban Airship, take your pick).

However, monetization in the mobile application world these days is being taken over by in-app purchasing. Our application is no different: a certain amount of data and images comes with the app, but if you want to get the whole thing we charge extra for the work that goes into assembling the data and creating the images. For the privilege of using pre-existing fulfillment infrastructures and access to millions of customers, we can pay 30% of our revenue to the app store owners and charge for extra functionality within the app. Not great (and sorry, guys, it doesn't cost you any 30% to support the infrastructure, but that's another rant) but there you have it.

So first up: the Apple app store. Apple provides an API named Storekit that gives the developer access to Apple's billing and fulfillment processes. Register the purchases in the store with a SKU, call the purchase APIs from the phone, verify the receipts you get by making a call on the server, and everything works. Locale and localized pricing are supported and you can sell your stuff in many countries without any extra code. Lots of moving parts but it works fairly well.

Next it's time for Android . Here's where the fun starts. First of all, there isn't a single world-wide Android store. Google Play is large, but it requires Google Mobile to work. If you don't have a functioning Google Mobile account, you're hosed. The practical upshot of this is that Google Play isn't supported on the Kindle Fire. Sure, you can root your device, but most people don't do that and as an app developer I have to support the Official Way of Doing Things. Additionally, if you want into the Chinese market, Google Play isn't supported there at all because their store isn't curated and China isn't down with that.

Now, there are alternative markets. Amazon has a new but fairly nice market that makes use of their existing e-commerce stack. If you have an Amazon account, you can purchase things on your phone via the Amazon App Store. While they aren't all that much international yet, several other countries are supported (UK, Germany, France, Italy and Spain) and movement is happening.

Since I've mentioned it once already, let's talk about China. China on Android is a freaking nightmare. There are dozens of Chinese app stores, including manufacturer sites (Samsung and HTC, for example), homegrown sites, carrier sites, and even direct download from the app makers themselves. Since Google Play isn't available in China you're stuck with either supporting at least some of the many in-app purchase APIs or going your own way. If you go with the available APIs get ready to give up 70% of your revenue. If you write your own, you have to figure out how to charge people who don't generally have credit cards. Add to this the fact that the vast majority of Android apps running on Chinese phones are pirated, and it's a real problem. More here: http://www.insidemob...s-android-market/

So with Android, not only do you have to deal with the utter fragmentation of the device base itself (yes, Android fans, it's there: http://opensignalmap...fragmentation.php), but also the fragmentation of the store and distribution opportunities. And on top of that, people with Android phones simply don't buy as much stuff. Why am I telling you all of this? Because, as an independent developer, supporting the Android platform and still managing to pay my mortgage is a difficult road to travel. And independent developers are exactly the kind of people you want on your platform, because that's where the innovation and cool stuff comes from.

However, I'm getting off track. This was actually supposed to be a technical rant. Back to the Android stores and the two practical choices at this time: Amazon and Google Play.

Amazon has a much higher percentage of people actually buying things than Google Play, but not as great a reach. Practically speaking, you really need to support both if you're going to make it in the Android world. Once you decide to go down the route of supporting multiple Android stores, the real fun starts.

The three major stores have very similar in-app purchase APIs: register your products, provide a button to click in the app, call the equivalent "doPurchase" call, handle the asynchronous responses, check the receipt on the server side to prevent fraud, and so on. Where they are very different is in ease of testing.

Apple has this part down. To test all of this, use a test user ID set up in your Apple store account for just such a purpose, log in as the user on the phone, and make sure to use the sandbox URL for receipt verification instead of the main purchase server.

Amazon ramps up the pain. First, install a special testing app on the phone and configure it using JSON to reflect the product information you already configured in the app store. To be fair, this allows some better, more controlled testing scenarios, so overall I'll call this a positive. It's not terribly straightforward, however, and it doesn't present the various interstitial dialogs as part of the purchase process. The next piece of fun comes with testing the receipts on the server side. Instead of providing a special sandbox service like Apple, Amazon provides a Java WAR that the developer has to install and maintain somewhere locally. For added fun, it only checks the receipt itself; there's no way to make sure your developer secret and the user infrastructure are functioning properly until you go live. All in all, I'm not a fan of using only mock functionality for integration testing, because invariably the mock isn't a true simulation of what production will look like. For Flex developers there's another bit of pain in that the Kindle Fire doesn't support AIR 3.x, so there's no way to actually debug a Flex application on a Fire.

Amazon has nothing on Google for developer pain, though. First, Google provides static test purchase SKUs. Great, except now I have to change my application's internals to test with products that aren't mine. And while you can create a test user for Google Play, it's a live user. When you execute a purchase in your test account, it makes its way into your merchant account as an actual purchase. That's right, you have to then go into the developer account and refund the purchase so you're not charging yourself to test your own functionality. But it gets even better: to use that test ID on your Android device, you have to do a factory reset to change it from the real account you may have set the device up with to start with.

But it gets even better better! In the Apple and Amazon stores you can manage your in-app purchase prices in the online app store and request a current list from the store API to use in the app. The prices get localized for you and all you have to do is display them. Google Play? Nope, sod off. Maintain your own localized price list separately, detect the locale on your own, make your own server call to get the list for that locale, figure out what price to display. And it doesn't matter, because Google is just going to use the localized price you have on their store regardless. It's a complete and unnecessary duplication of effort. Google has completely screwed this up.

So in my opinion from a developer's perspective there's more to recommend iOS: small, stable device base; little to no OS fragmentation; higher monetization rates (4:1 in the case of Google Play); better internationalization; better store API; and for the most part a better developer experience for testing. Unsurprisingly, Objective C has moved up 3 spots in one year on the TIOBE index to become the 3rd most popular programming language.

I'll also post my treatise on why Linux fragmentation doesn't piss off developers any where near as much as Android (which is Linux, basically) fragmentation does.

See the hyarge post I just laid above, but the short version is that it comes down to control of the environment. If you're developing for Linux, it is overwhelmingly likely that you are probably creating applications that run internally to a particular organization, and that organization has (or should have) a very controlled, homogenous environment.

When you're developing for mobile apps, you have to hit every possible environment out there.