May 232012
 

It looks like Amazon has rejected Neil Rajah yet again, this time because it uses a Swarm virtual goods store. I don’t have confirmation on this yet, but it looks pretty likely. They approved the latest update for general devices almost 2 weeks ago. Yesterday I submitted a support ticket, asking if it was still in the queue to be reviewed for the Kindle Fire, because I hadn’t received any email telling me if it was approved or rejected. The response I got basically said “Apps sold through Kindle Fire should use Amazon’s In-App Purchasing API.” I asked for clarification, but I’m guessing this means that they rejected it for the Fire, but neglected to tell me.

This isn’t a big deal for me to work around. I already have a Swarm-less version for the NOOK tablets, so that version should work for Amazon as well (with the ‘go to store’ link switched to the Amazon link). That will be a lot less work than writing a new storefront screen, and integrating their IAP API. So I’ll probably make that change and submit it to Amazon again.

But the more interesting thing here, for me at least, is how this is another aspect of fragmentation. Yes, it’s completely optional, because I’ve chosen to list the game on all these different stores. But look at the variety of IAP implementations and requirements out there:

  • Google Play – They have an IAP system, but usually don’t enforce it. Although there have been some reports of them threatening to pull apps that use something other than Google Checkout for IAP
  • NOOK – They don’t have their own IAP system, and they don’t allow 3rd party IAP systems. So basically, no free-to-play games on the NOOK tablets until they come up with their own IAP infrastructure (and it’s not clear that they’re planning to)
  • Amazon – Recently released an IAP SDK. From the accounts I’ve heard, it is pretty easy to use. They’ll apparently allow 3rd-party stores for their general devices, but not for the Kindle Fire. Which basically means that it’s not allowed – by my metrics, hardly anyone is using the Amazon app store any more other than Kindle Fire owners

The takeaway for me – on my next game, if I want to list on these stores, I should plan to implement my own store, and abstract out the backend so I can use multiple IAP implementations. And then I should ideally implement Google Checkout, Amazon, NOOK (if they have something by then), and a 3rd party solution like Swarm/TapJoy/etc. for all the rest of the stores.

  4 Responses to “In-app purchase fragmentation”

  1. I’ve been looking into implementing in-app purchasing, but alas it looks to be a lot of work considering the fragmentation. Have you brought in some decent revenue from Neil Rajah from utilising it (if I may ask)? I feel I need to better monetize my apps, but am unsure as to the benefits of in-app purchasing at this point.

    • So far I have had exactly zero purchases on Swarm :) The IGM review noted problems with signing up, so I can’t say if that’s because people aren’t able to make purchases, or people don’t like Swarm (i.e. I would have had more sales if I’d used platform-native IAP libraries), or if this is another aspect of my demographics distribution (about half my users are in India), or I just haven’t provided a compelling enough reason for people to spend money, or something else. In other words, I don’t know how far I can extrapolate my results.

  2. GetJar has released their own inApp SDK which uses virtual money.

    Its a game changer

    https://developer.getjar.com/android/sdk-sign-up/

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>