Is it a revolt against the app store fee, or against new privacy and security rules, which demand that they change their target SDK level to something modern which doesn't allow as much data collection?
You have always been able to collect subscription fees on your own website and distribute your app for free.
>TechCrunch learned this week that Netflix is testing a payment method that bypasses iTunes in 33 countries. Until Sept. 30, new or lapsed users in select European, Latin American and Asian markets will be unable to pay using iTunes. Instead -- like with Spotify -- they will be redirected to Netflix's website to enter payment details directly with the video streaming service. In May, Netflix made a similar move prohibiting new subscribers from paying via Google Play.
https://www.billboard.com/articles/business/8471988/spotify-...
>> 2.3.2. If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
Your app will be booted off the App Store if you try to redirect users from your app to an out-of-app purchase system
Netflix and Spotify do not actively redirect users to their own payment systems (in the U.S., at least). They do not provide any links, nor do they offer any instructions on how to sign up outside the app. They just say this:
Netflix: "You can't sign up for Netflix in the app. We know it's a hassle. Join and come back to start watching TV shows and movies."
Spotify: "You can't upgrade to Premium in the app. We know, it's not ideal."
The user is left completely on their own to figure out the subscription process. Netflix and Spotify are apparently big enough, and have enough consumer awareness of their services, that users will put in the effort to go sign up. For your app, this is almost certainly not the case.
The kindle app offers no way to purchase for this reason.
Neither Google or Apple do that.
Of course, even if you set up your own payment infrastructure you are going to be paying somebody a cut.
Visa, MasterCard, PayPal, and Stripe et al. are going to take a cut of any transactions they process.
You have to decide if the fee they charge is worth the additional sales accepting that method of payment might bring in.
Which is why Prime Video on the App Store doesn’t allow any rentals for example.
I have worked for a major music streaming service for a long time and publishing the app on iOS has been a constant pain.
Sometimes the app was not updated for months because apple would not validate it.
Each time the source of contention was that you could subscribe without using apple solutions (paying them) and that the subscriptions covered all platforms.
Google already has special deals for companies that lowers the 30% fee significantly.
(I think even 2-3% fee is too much for doing basically nothing, but that is another discussion).
My guess is that the play store fee works more like a tax on a closed ecosystem than a price for a service. For example, when the government needs to pay for a more expansive healthcare bill, they may decide it makes more economic sense (or is more politically viable) to raise the additional funding through a tax that doesn't go back to most of the people who receive the benefits. So maybe they raise capital gains taxes, etc.
Likewise, while Google is an ads company, and running Android does benefit them some in that regard (e.g. ecosystem lockin), they're not running it as a charity. Android being given away for free, and many phones being subsidized, both benefit a lot of people, and because Google has more or less complete control of the market, they've decided the best way to pay for it is to tax the Play store, instead of charging those people for the benefit.
They important thing I'm trying to point out here is that they could do it differently - they could charge for Android, or require subscriptions to use more of their services, but they've decided the best way to monetize is through the store. In this case, the question of whether the fee is "reasonable" for what Google provides to app developers isn't quite as significant as it would be were Google simply providing a product on the free market.
But in this case I suspect you're both right, anyway, and this likely has more to do with data collection.
It's not a closed ecosystem anyway, I think. As far as I can tell, all the devices that officially have Google Play, also allow other applications to install APKs; now in a very fine-grained and straightforward way (as of Android 9).
30% is ridiculous for Apple and Google. It's an arbitrary number that they could get away with when the Appstore came out nine years ago and everyone ran with it ever since.
I don't know what a fair amount is. But I doubt it's in the two digits.
You just have one large customer in one country instead of thousands/millions in many different jurisdictions each with its own tax and consumer protection laws. That's worth more than 2.5% but it's not worth 30%.
I would say fair is somewhere between 5% and 10%, considering they also provide some distribution infrastructure on top of payments, billing, taxes and compliance.
Well, I guess Symbian got N-Gage and the Ovi Store towards the end, but they never tried to lock it down against third party sources.
When Apple announced 30% cut, mobile devs where cheering, because many providers were charging way above 50%.
Developing The Android platform is a benefit for Google, not for the app makers.
If Google came up with a magical technique to get rid of all malware on their app store that didn't cost them a dime, you could still argue that they're adding value to justify the 30% cut.
If Google spends a billion dollars to get rid of all the malware on their app store, and it doesn't work, and using the app store is not significantly less dangerous than sideloading apps, then they're not adding any value to justify the 30% cut.
Note that I don't think Google's efforts are completely fruitless. At the very least, they seem to help with taking down duplicate apps, and that's something. But whether or not moderation is valuable only depends on whether they succeed or not -- their effort is irrelevant.
<1% ?
With nobody to filter out impersonators and repackaging of an app with added malware ?
Google will probably approve anything that's not an obvious malware but not much more than that
For example Chinese hackers added hidden code to 34 legit apps totaling 500 millions downloads and Apple didn't notice a thing.
https://www.macrumors.com/2015/09/20/xcodeghost-chinese-malw...
Happy now?
The ecosystem may be better off with something like 20c + 20% transaction fees. But, a flat percentage needs to be surprisingly high just to breakeven.
They can start their own currency, but only facebook is going that way and it takes a long time.
Yes, you shouldn’t float a balance on your card - but the average person often does.
Handling publication, payments, giving exposure and direct access via the play store, approving the apps, rejecting impersonations, the play store platform actually does a lot of stuff.
I agree that a 30% fee is a lot and probably way too much, but claiming that they do nothing is just ridiculous.
Yea 2% fee is too much because bandwidth is free.
Source?
IIRC this change was introduced in API 23 (marshmallow), now a while ago.
Before that Android version, permissions (such as accessing your contacts or your calendar, using the camera sensor, etc) where requested and given at installation time.
23 introduced runtime permission : now you don't get the permissions at install time but at runtime : while the app run it incrementally asks to access your contacts, camera, or whatever else it needs.
But there is an issue : how to handle all the existing apps ?
What happens is that apps declare which sdk version they are targetting when they are compiled. If that version is 23 or higher, they get the new behavior.
For apps targeting 22 or less though, the system fallbacks to the previous behavior.
This way apps don't suddenly break when you update your phone and apps already published on the play store don't have to handle this change right away.
Most apps, especially popular ones have been pretty quick to follow these new targets.
However, some apps (cough like snapchat cough) have seen a loophole there and have been keeping their target sdk very low so they don't have to follow new behaviors.
So a couple of years ago Google decided to address that : now if you want to publish a new app, you have to target an android version that is at most one year old. App updates have the same rule, although IIRC the period is a little bit longer.
So it is no longer possible to game a system that is only there to gracefully handle old apps.
I have mentioned runtime permission because it is one change that is easy to explain, but each Android version has several behavior/security changes like this one, so enforcing this rule is definitely for the best.
2nd paragraph: > The online dating site launched a new default payment process that skips Google Play and forces users to enter their credit card details straight into Tinder’s app, according to new research by Macquarie analyst Ben Schachter.