Being a mobile app developer may often be compared to going to Las Vegas. But at least in Vegas you typically get much better than 1 in a million odds, but with both Google Play and iTunes reaching 1m apps each, dropping your app in the app store means absolutely nothing (unless you hit the jackpot = getting featured). So the alternative is to spend (pay per installs, CPMs, or any flavor you can think of) or to increase your distribution (be in every app store possible).
Now the latter option, increased app store distribution, is fine if you have a free app that is ad financed based, or an app that is pay for download, but with momentum and user preference clearly moving towards in-app purchases, the number one pain point facing the industry is payments. App stores want their 30% cut for putting in all the effort of acquiring users and managing the stores (granted there are plenty of stores that have come up with different business models, but taking a cut of the revenue is still the dominating model among the big ones). For the developer this means multiple payment SDKs, with lots of effort going into development, QA and code base/SKU management and general headaches. As one developer told us, even though it may only presumably take only half a day to drop the code in, it always ends up taking 2 weeks for a key developer when all is finished – precious time often needed for developing the next app.
Up until now, there has been no way around this. But the Open Platform Foundation, backed by Russian giant Yandex , is taking charge on this with the Open In-app Billing project.
1. One SDK saves time
For the reasons mentioned above, if you as a developer only need a single SDK for billing it means you will save a tremendous amount of time for obvious reasons: One integration, one QA process, and possibly even a consolidated revenue view.
2. App stores should love it
Besides Google, we would venture to believe that the likes of Samsung, BlackBerry, heck even Amazon, do not really want to be in the payments business. Yet they have had to build up a payments SDK in order to collect the app store toll. While the 200m credit cards on file were key for Apple’s App Store, and continues to be a major strategic asset (now with 500m cards on file), the others have proven you can have success without that – and simply the key is ease of payment (and revenue collection), not how you do it. Consumers could not care less. They just want to click a button, pay and get on with it.
3. One SDK could make the app store world explode
If the Open IAB project succeeds, which largely depends on the acceptance of the major app stores (they will still be using their billing, so there should not be a compelling reason not to), it means that this can finally open things up for all app stores. All an app store would need to do is simply drop their SDK into Open IAB, or if they don’t have their own payment SDK – cooperate with one of the partners that are available in the project – so that they can be the Merchant of Record in their own store without asking developers to create a special binary for them. This will grow the pie for everyone, as apps can more easily be published to stores without any special requirements, and stores who do not have payment SDKs, suddenly have one and can start taking a cut of the in-app revenue stream.
Enabling app stores all over the world to make money on in-app billing will open up a host of new ways to sell apps, such as affiliate networks, direct selling networks, niche sites dedicated to certain types of apps (for instance the Sports App Store etc) – that will make a much better job for the individual developer than the mega app stores can.
We’re also excited about the App Description File project, as it will simplify distribution quite a bit for the stores that will support it. This is why CodeNgo is an early AppDF supporter, and we encourage developers to try it.
Share this article on