Apps

The hidden costs in distributing Android apps to multiple markets

Mobile developer Tim Mackenzie details the costs and challenges related to releasing your Android apps to various app stores.

You got your Android app into Google Play, and now you're ready to distribute it far and wide to every app store you can find. Free money, right? Not quite.

It's best to know what you're getting yourself into. Releasing an Android app to a new app store may seem like double the profit for an app that's already been developed. Unfortunately, there are costs associated with getting an app into each new market. These costs may include direct payments and development time. Even if you're able to do everything yourself, each hour spent on these tasks has an opportunity cost.

Known costs

Many developers are familiar with account fees for app stores -- like the Apple App Store, there are fees for some Android markets. Amazon copied the model of Apple directly, charging $99 per year, but they give you the first year free. Google is far cheaper -- just a one-time fee of $25, and you're good for life. While a few app stores charge a testing fee per release, many are free for developers.

What about development costs to prepare an app for a new app market?

Each app store can impose its own restrictions, which can range from missing software (e.g., Google Maps) to missing hardware (the camera, GPS, etc.) and beyond. Sometimes big changes need to be made, and some apps may not be compatible with the target Android app market.

Additionally, many app stores require that all apps link only to apps within the same app store. For example, an app on the Amazon Appstore can't link to another app on Google Play.

Particularly for your first app to port to other app stores, you will need to investigate the limitations and provide workarounds. For example, it might be necessary to:

  • Change all links to link to the target app market.
  • Remove certain features that aren't applicable to the target platforms.
  • Switch from Google-centric apps like Maps to achieve similar functionality on other platforms.

Incidental costs

After you sign up for the market and crank through the necessary changes, everything is good now, right? Unfortunately, there may be additional costs before the app can be released.

First of all, the required graphics differ by app store. Developers and publishers may not realize this until they go to deploy, at which point some rework will be needed for the icon and the promotional graphics.

The testing process is even more time-consuming. Unlike Google Play, submission to a curated market such as the Amazon Appstore or the Nook Store requires approval from the testing team. This can be an interactive process during which you are required to make changes and resubmit an updated version of your app. The overall process can involve weeks of waiting, in addition to the development time to make changes. (Read the TechRepublic post Getting your Android app on the Nook Apps store.)

Hidden costs

A number of the costs are harder to quantify and identify. For example, what is the cost of the app release being delayed a week or two while you are in testing limbo?

Beyond the initial release, there can be long-term costs that build up. Maintaining the tweaks and changes for each app store can add a bit of effort, depending on how they are set up.

Even harder to identify are the costs of choices made to satisfy app store requirements. If you decide not to pursue some features because they won't be available in all app stores, the overall success of the app on Google Play could be affected. This kind of thing tends to creep up over time.

Don't give up just yet

Knowing these costs and challenges related to releasing apps to different Android app stores, you may be tempted to conclude that it's not worth pursuing. Each developer must make that decision for him or herself.

However, it's worth noting that my success on Google's market was surpassed quite a while ago by success on other app markets. I wouldn't want to be without the income my apps have earned in these other app stores.

I hope that understanding what costs are involved in distributing Android apps to multiple markets will help you plan accordingly.

About

Tim Mackenzie, author of the Android Income Series books, is a software engineer that escaped the cubicle world at a large company to go solo with Android app development. He uses this freedom to teach others how to make money with Android apps. Visi...

2 comments
danbi
danbi

One of the major reasons for lacking certain software on Linux (as opposed to Windows and OS X) is it's fragmentation. That is already without considering the different App Stores and their policies.

Neon Samurai
Neon Samurai

Distributions based on Linux tend to provide there own curated repositories (any of the well managed major distros anyhow). The distributions are the product; multiple distributions compete just like any product category with more than one product brand. Ship your software with an open source license and the distributions will do the work to include it; you target one standard build. Ship your software with a closed source license but target the major parent distributions; get it into the Debian non-free repository and all those distributions based on Debian will inherit your software also. You target the major distribution build and you also get Ubuntu, Mint and the rest of the forks. Build for Debian and Red Hat allowing child fork distributions to inherit the software and your covered. Easy-Peasy. Basically the "oh nos, there's all these different products based on this one kernel and we have to target them all individually" argument is crap. Fragmentation would be several separate distributions claiming to be the same brand name and claiming to function out of the same repositories. Which is actually what we do have with Android; multiple customized OS distributions with vendor specific changes and limitations all claiming to be the original parent Google Android version. If it doesn't have Google's standard interface and doesn't get it's updates directly and promptly from Google's repository then it's not Google Android.. it's a child fork OS distribution which happens to be based on it. Amazon at least does it right. When they forked Android to make there own embedded OS, they said "this is our product and it uses our software repository".. and you get updates from amazon (not sure how promptly but at least you get updates). They don't say "this is Android.. on some device or another.. buy it", they instead says "this is Kindle Fire.. our device that does these neat things." For me, the distribution is the product regardless of what OS kernel it may or may not use. And, if it's not a Nexus device with Google's stock os and direct updates then it's not Android.. some other distribution based on Android.