play-billing-samples
play-billing-samples copied to clipboard
android
Question for App Developers: How good is Google Play Billing client library?
This question is mainly for app developers who use Google Play Billing client in production apps.
Implementing billing had been quite challenging historically in Android. I had my episode of struggles with AIDL then settled for android checkout. Now that we have AIDL deprecated, Google Play Billing client seems to be the only way available now.
I understand google released many versions of this library. Looking at the release notes, google issue tracker, and issues reported here, I get a feeling that there are still lot of rough edges. I see billing service connection issues, threading issues, etc are still being reported. I think these are the kind of issue which should have been ironed out during the 3 years of this library's existence. I could be getting a wrong impression, as I haven't tried this library yet (I tried IabHelper of the old days, and I thought it was terrible to use and clunky for production purpose. To be fair, it was only a sample code though).
Anyways, now the documentation looks good. API looks neat and straight forward enough. But how good is this under the hood? I don't think this is open sourced. So
- How well does it work in production, where edge cases are a norm?
- Do you experience weird purchase failures, end up spending hours on support and/or struggle with hard to reproduce bugs (billing connection issues, for example)?
I don't know where else to ask this except here. I hope, your overall experience and specific feedback will also be heard by the people responsible for this critical library. Looking forward to learn your experiences.
I'm not sure how to chime in here without appearing biased, so I'll leave this issue open for now to see if any other developers have thoughts. This would indeed be a good way to see what people like / don't like about the Play Billing Library 😄
It's always been a very convoluted billing system, and efforts to make it easier have made it worse. The samples here are too complex and also incomplete (Trivial Drive Java???)
It's always been a very convoluted billing system, and efforts to make it easier have made it worse. The samples here are too complex and also incomplete (Trivial Drive Java???)
Yes, it is rubbish, it has been over engineered into a convoluted mess. It takes too long to implement and debug. None of the developers in our team want to touch it anymore.
Also, the absence of Trivial Drive Java is a complete joke. Issue #278 is being completely ignored, despite there being significant demand for this.
The only reason to build apps is to make money, so the Billing API is crucial. There is no justification for not having an up to date Java sample.
I think people will just give up on Android Development, particularly the Indie devs. Why bother with this nonsense? Nothing in life is without adversity. But for Android, Google seems to deliver one garbage API after another.
I agree. Comparing with ios android development is much harder. A lot of things we are doing on our side, have been already taken care of in ios. Also we must support a lot of different devices and lots of custom operating systems, especially a lot of pain in the ass with Chinese manufacturers like xiomi, oppo, zte, huawey, etc. This particular approach of billing is a disgrace. Still, I'm grateful to google that we can at lease earn money on the platform, though current implementation is complex and not easy to implement.
It's also worth mentioning that iOS now has the "Small Business Program" which cut their commission down to 15%, instead of 30%, as long as you do less than $1M USD in sales per year. You can make a LOT more money building apps for iOS, and skip the headache of this over-engineered billing library.
iOS is a niche player with just 12% of the market. Everything else is Android. You aren't going to make ALOT more money. You are however going to spending ALOT more time making your apps work across their different device configurations, with an OS that was never designed to be flexible in that manner.
@fourofspades that's just not true. We need 2 Android developers for every 1 iOS developer to keep feature parity. There are literally thousands of Android devices, and just a handful of iOS devices to support. iOS development is significantly faster and significantly easier to test. Not to mention that over 85% of iOS devices run the latest version of iOS. Android fragmentation has gotten better in the last few years, but we still have to support OSes that are 6+ years old on Android.
We make a very popular app and the split used to be 60/40 Android/iOS and in the last couple years iOS has surpassed Android. Not to mention with the small business program, iOS revenue is almost double Android revenue.
Don't get me wrong - I love Android, but if you're picking a platform to start with and most of your customers are in the US or Western Europe, start with iOS.
Hopefully Android follows suit and reduces their commission soon to be on the same level with Apple.
In our case it's a bit different, we have 70/30 Android iOS but the 30% of ios users make the same revenue as 70% of android users. Usually ios users are more willing to pay. I think Android should restrict some manufacturers to rewrite pure android os, as we have a lot of additional work in order to handle xiomi, zte, oppo, etc. Apple is like "You can do it only this way and not any other, and only inside apple infrastructure". Android is like "we are open-source, you can go different ways, we are compitable with any device" Of course, that's why it's more difficult to support.
We've definitely noticed that iOS users are more willing to pay for things. Mobile is super fun and Android and iOS are both great, it's just frustrating, like you pointed out, to support all the highly customized OSes. Apple is locked down which isn't ideal for enthusiast users, but much easier for developers to build consistent experiences. I'm glad there are 2 very different dominant operating systems, and Android does some things much better than iOS, but from a financial/ROI perspective, iOS still wins.
It's never been proven that iOS users are "more willing" they may just be "more forced". Android's open source culture leads to many more free options when it comes to apps.
If you are going to make a pay for app Android, it's going to have to be substantially better or innovative that the free offerings that are out there. Sorry to break the bad news, of you aren't getting Android revenue, it's likely to be down to what you are offering,. Stop taking the easy blame route and blaming the users.
it's not only our experience, you can check uber, tinder, etc. The same situation. @fourofspades
Look at that! Google is reducing their commission to 15% for the first $1M in sales every year starting July 1. Thanks for listening!
Look at that! Google is reducing their commission to 15% for the first $1M in sales every year starting July 1. Thanks for listening!
thanks, Google) Good news! <3
It wouldn't be bad if there was concise documentation in one place. Here is where the issue of googles scattered documentation structure really shows it's flaws. Some of the information is out there but it's all over the place and most of it isn't there at all. There's been many many parts of the GoogleBilling integration where I've experienced somethings that are completely undocumented and had to rely on years old stackoverflow threads like this was just some random repo. There's also no easy way to test these subscriptions the flow is to increment the version number, create a new signed bundle, publish to a release, and update the app locally on a physical device, all just to test an api. Seems absurd. I would also like to add that if you are setting up the api for the first time you will have to create a store listing, fill out serval questionaries about ads, data safety, audience your app targets, you'll need to provide a privacy policy, screenshots of your application, shall I go on? All this to test an api. We need to be able to do this on an apk. All this has nothing to do with GoogleBilling
What's worse, Google isn't playing by their own rules: they force everyone onto 2 year version update cycle, yet with their endless money flow they themselves don't have enough resources to keep their samples updated in step with the billing library releases. I bet these samples don't even have owners inside Google!
Hey, Google! Care to prove me wrong?
It took me a total of 2 or 3 days to integrate Stripe subscriptions into my website for delivering premium content, in a flow that "just works" using simple components like serverless functions in Cloudflare.
Now, trying to make an adjacent Android app that uses the Google Play Billing system for the same premium content and I'm just shocked at how unintuitive it is.
