Developing a mobile game for the app store use to be so streamlined, mainly because there was only one. Things started to get complex when Android surpassed iOS, and you had to publish and maintain games on two different stores. Then Microsoft jumped on the band-wagon with their app store. Interestingly enough, that wasn't the straw that broke the camels back. Soon enough every OEM had their own app store for their televisions, set-top boxes, and even a game console thrown in the mix! Developing for mobile became a hell of a lot more "impossibler".
Last October we released our first self-published, multi-platform, mobile game, Count Crunch's Candy Curse. We published it on iOS, OSX, Google Play, Amazon, Windows Phone and Windows Store (that's a mouth full), but how each of these different platforms did for us is a rant for another day. We are a team of two (artist and programmer) so there was a lot involved for both of us to make that happen. There were quite a few late nights and early mornings towards the launch date to get all the uploads prepped, assets ready, and game tested. Developing the game from the start with the right engine was the most important decision and we chose to go with cocos2d-x. This was an engine that we had used for various other projects, for numerous clients, and it always performed the way we wanted it to. Sure there are other cross-platform engines, but for what you get I would definitely recommend it. Cocos2d-x is open-source, has a large community, tons of documentation and tutorials (especially check out raywenderlich.com), plenty of available sample code, its own editor, and best of all it is FREE! And as an indie developer it is hard to argue with free.
Having an engine that enables us to only have to write code once is great and all, but what about testing all of the different devices? What about all of the different developer accounts you need? That's where the rant starts! We've been mobile developers for a while so we have a collection of devices, but nothing compares to the amount we had to add to our collection when we decided to go cross-platform! Each device also has its own resolution and own hardware capabilities (which will effect your code). So even though you only have to write your primary game code once, you will still have to modify your code to support each OS's awesome quirks. If you think for even one second that you can just use an emulator/simulator for all your testing, then think again ma'am (or most likely sir)! While a simulator might be 'good enough' for testing resolution, you haven't even thought about performance issues. So test your game on physical devices for all the things you plan to support!
Deploying to and managing each app store is a job in its own. We have a vault just for keeping track of our username and passwords for all the different accounts. Then there are different screen shots and different size icons for each store. On top of that there is the task of testing each build for each store and uploading it. Once all of that is done, you'll have to do all the testing and uploading anytime you have an update for a feature (or bug). Most of the time uploading builds will go rather easily, but in our case, the game was over the size limit for the Google Play Store, so we spent extra time dealing with that. The other stores were mostly straight-forward, especially since Apple has fixed most of their provisioning profile issues. Amazon was surprisingly the easiest to deal with. The Windows/Windows Phone stores had slightly different ratings hoops to jump through, as well as company verification. But we did it and it was quite the experience! But will we do it again? Unsure.
Developing for different devices and different platforms is as difficult as herding cats. Having the right tools makes it easier, but there is still not a good answer for managing five (or more) different stores or easily testing each device. If Doc Brown would hurry up with that time machine, I would go back to the easy times of 2008 when there was only one store (worth publishing to) with only one resolution. Until then, I have yet to discover an easier solution, but at least we have engine choices that make it mostly manageable.