Google Play permitting alternative billing systems for users in South Korea
developers-kr.googleblog.com
developers-kr.googleblog.com
The Android OS is intentionally crippled to work only with Google Play push notifications, and there are no 'stock' ways to use an alternative without modifying the OS. The best alternative is to do it via persistently running app, which is less reliable and bad for UX.
This notifications problem also applies to iOS: even if users will be eventually allowed to install apps bypassing the AppStore, these apps would just sit idly until opened by a user, which is unacceptable for a very wide range of communication apps.
However, there is a difference with Android: iOS was crippled from the start, but first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip, so Android now closely resembles iOS in this regard.
Even if you want users to give indication of something running in background there are far less intrusive ways to achieve that. But if you can't come up with those ways and persistent notification is the best you could come up with then at least give the user the ability to turn it off without turning off background process?
They know the tendency of people to clear notifications as they clutter the phone and they use this small knowledge to push their own Software. At least follow same practice for Google apps but no because then that notification area would be complete mess.
I still think my Sony Ericson p910i the best smartphone. Multiple human interfaces (the multi directional wheel is the greatest invention to be abandoned) in particular and a near fully functional OS that could do anything my computer could do
This was absolutely terrible for battery life, though. Accidentally leave the IRC client open in the background? There goes your battery. There are non-nefarious reasons why smartphones work they way they do nowadays.
"My Android phone just died at 1pm with empty battery, I don't know why! I'm buying an iPhone!" complaints are something noone from the Android side of the market wants to continue hearing. Even if that means that you now need to have a notfication clearly telling you your battery is being drained.
So modify the OS… it’s open.
If it were that easy as an overall solution, non-OEM Android forks would be mainstream. They're not. I hardly know any people using non-OEM Android.
This is not even hypothetical, this was literally happening before background services were heavily limited in earlier Android versions.
With current notched phones which are limited to 4 notifications (you get four and a dot if there are more), you can have VPN app, XMPP client, Syncthing, and a generous space for one more incoming notification.
Those tools existed and they didn't help because users had no recurse against poorly behaving apps. Meanwhile Android kept being reamed by reviewers and media for poor battery life and people kept buying locked-down iPhones instead because they lasted longer.
I spent countless of hours trying to get Android devs to not do dumbass things with battery ("oh, I need updates? I''ll just poll the server every 20 minutes and ruin the users battery in hours. Easier than long polling!") and in the end the situation didn't improve until Google stepped on the devs neck and forced them to use GCM/FCM and started actively powering down radio without apps input.
Users have very effective recurse against poorly behaving apps: uninstall. You just need to inform users that the app X does use much battery. Then it should be up to the users to decide if to allow this behaviour or uninstall this app. Maybe an explicit permission to run in the background. That's it.
Solution that you like is also very beneficial for OS vendor, how convenient.
Even correctly behaving apps will consume much more power and network with this scheme.
It is not up to the OS to decide which apps the user needs running. Be it wifi scanner, vpn or some file sync process. All the user needs is a correct tool to know which app consumes what, and then there User must decide. Not some prick in google or xiaomi or samsung or whoever else.
But the two big challenges there are:
- odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google").
- we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone.
It'd be a hell of a cool project for someone to take on though.
Your macOS has an unacceptable battery life already despite having a massive 58WHr battery - about 3.5x the size of a normal phone battery. Phone users don't want to lug that size of a battery around just to get battery life that's worse than they get right now from a 15WHr one.
Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.
In your reasoning, "most" users would be done and "most" apps would be malicious.
But in the end, it's quite simple - dealing with power use on mobile is hard and most developers don't care (same as they don't give a crap about making your web pages fast and slim). Users care about battery life above most of other features, including your freedom. They WILL got and buy a device that lasts the longer amount of time in the smallest and lightest package.
As long as these two things are true, leaving developers to run their polling code without restrictions has a massive effect on sales of both OEM devices and Android ecosystem as a whole. As such, OEMs are actively modifying Android to not allow this - see the wonderfully depressing https://dontkillmyapp.com/ - which is a significantly worse mess than you having to use a proprietary service to send a single device wakeup ping.
But that doesn't align with Google's interests, so it will never happen, unless they are forced to.
It's similar to how crappy drivers causing BSODs were for a large part responsible for the "Windows is a crappy unstable mess" sentiment of the late 90's and 00's [1]. This led to Microsoft severely restricting driver manufacturers, requiring signing and WHQL etc. Less freedom but stability and perception among users has markedly improved.
[1] https://www.zdnet.com/article/why-the-blue-screen-of-death-n...
I was an Android dev pre-5.0 and believe me, having lived through the s*tshow that was push notifications at the time, there's no way it would've worked any other way. Google's own SDKs were garbage and as with everything else they kept releasing new incompatible rebranded versions annually. Last I checked, the Firebase console for managing push notification subscriptions was still one of the worst SPAs I've come across.
You'd expect a thriving ecosystem of dedicated push notification providers to pop up and outcompete Google, but all of the 3rd party offerings were even worse, in terms of battery life, UX, reliability and even pricing.
It's unfortunate, but no developer cares about your battery life, because no user is going to switch away from using their app solely because of crappy power usage, so Google had to do exactly what they did.
Maybe in a decade or two, with new battery technologies, there won't be a physical limitation and this situation would play out differently.
I was in Android dev since pre 2.0, developing an app which need to constantly run. The situation got worse since then, not better.
A thriving ecosystem of dedicated push notifications can't pop up because you can't go to Android settings and choose another push notifications provider. You have to rely on ugly crutches to even receive a push notification, and that is why they are 'even worse'.
So you either need every app developer to maintain the list of all push providers or someone, presumably Google, to maintain the canonical list and the thing that manages sending them to all the push providers.
Oh and then there's the associated suite of privacy issues. Do you really want every push notification prouder to get even metadata about all of your push notifications?
So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
> So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
They seem to do fine with email addresses. Again, I don't see why 'username@notification.provider.com' (or an alternative with auth embedded) would be absurdly hard for developers. Someone will write a 'SendPushNotification' function that parses out the domain to send it to and the auth to use and send it, just like we've done with email since forever.
Google will likely know where you're sending your notifications, but they won't manage sending them (though they could probably scrape the contents since they own the OS).
If by notifications you are referring to Firebase Cloud Messaging, which replaced Google Cloud Messaging and is now integrated in Google Play Services, I do agree with you.
It is my opinion that Google should be forced to decouple all these Google Play Services which are not related to the "Online App-Store" which Google Play is, and ideally be forced to open source it, so that trustworthy alternatives can be used to replace it.
I mean all the components which track you, which basically is what Google Play Services is: it is a system service created to monitor every possible activity you have with your phone (location, physical activity, health) as well as the efficient, persistent data connection to transfer these bits of information to Google (and to your device as FCM), while Google grants you access to use these services in a restricted manner.
For me Amazon's Android devices are basically useless since they don't have Google Play Services installed, and you have to work around it to get it installed, which basically is illegal to do.
Without the problem for YOU, because, presumably, you have a non-shitty phone. It is a much more severe issue on the likes of Samsung / Xiaomi / Huawei. See https://dontkillmyapp.com
Also, such apps are unloaded from time to time even on stock non-modified Androids.
If you think people talk about AOSP when they talk about Android, you are always going to miss the point of these conversations.
> Unfortunately, vendors (e.g. Xiaomi, Huawei, OnePlus or even Samsung…) did not seem to catch that ball and they all have their own battery savers, usually very poorly written, saving battery only superficially, with side effects.
My apologies to NGRhodes, the link does indeed refer to an issue with OEM and not what Google supplies. I don’t really see what it has to do with the topic we were discussing however.
And if you force Google to stop verifying proper behaviour in CTS, do you expect those manufacturers to allow you to run background services at will?
They already kill off anything that's not whitelisted to keep those battery numbers up. The every new major OEM release we developers find bunch of new ways the try and kill background apps.
Such solutions are what I referred to as 'the best alternative'. No, thanks, it's not even close to the real deal.
The OS is designed in such way requires push notifications built into its core to work properly.
Apps are subject to power and resource restrictions, but the user can easily lift those restrictions manually for certain apps, like UP Distributor. If the app is implemented properly, it will work just as well as Google's push service.
> The OS is designed in such way requires push notifications built into its core to work properly.
Notifications are built into the OS. A network-based push notification service is not part of the OS. It is false to say that (a particular implementation of) network-based push notifications have to be "built into the OS' core to work properly."
The flip side of this is that there were a lot a badly behaving apps, sitting in the background without a user requirement that would justify that, eating battery and network. Hence nearly all Android phone manufacturers bundling some kind of background app killer.
The correct solution here would have been a system-level, open source, provider-agnostic push notification API built into AOSP. The Web Push API is a great example of how a push API can be provider-agnostic: https://developer.mozilla.org/en-US/docs/Web/API/Push_API. It makes sense that push notifications should be consolidated to one provider -- this way, your device only needs to maintain one 24/7 TCP connection to a server which it receives all notifications from all apps through, rather than having each app run its own notification service in the background, killing your data and battery life.
Google's push service works by providing an HTTP endpoint to apps that they can use on the backend to deliver notifications. The Web Push API also works this way, but the returned endpoint can be for any provider. If you use Chrome, the domain will be `google.com`, but on Firefox, it's `mozilla.org`. But each provider's endpoint uses the same standardized API, so the backend doesn't have to care what the URL is. And this isn't a security risk, because everything sent through the service is encrypted.
This could have been done for Android, but that would have given Google much less control over the platform, so they decided to do it in a monopolistic way. This is one of the many ways Google aims to maintain their monopolistic control over "open source" Android. Another example is SafetyNet hardware-backed attestation.
Projects like GrapheneOS are really interesting because they are finally providing a real secure, private, de-Googled OS option, with excellent app compatibility thanks to sandboxed Play Services (which allows you to run Play Services without giving it root access to your device [1]). But will we ever be able to fully decouple Google from Android? I'm not sure. I expect most users of custom ROMs to continue installing Play Services on top of them for a long time, if they want something as basic as push notifications to work.
By the way, while I personally have qualms with Google, I believe users should have the choice to use Google apps, if they are comfortable with the inherit privacy risks. This belief is shared by the GrapheneOS developers. [2] My problem with Android is that it was not built to function without Play Services. Community projects that enable it to do so, like microG, will always be a cat-and-mouse game with Google. I think sandboxed Play Services is the most sane approach the problem of Play dependencies the community has come up with so far, but I think if we want real change to happen, we need to target app developers. Each developer has the choice of whether to include Google or not within their app. We just need to convince them that they don't need Google.
Google owns `developer.android.com` and points developers towards using Play Services APIs wherever possible. Perhaps the community should create their own open-source alternatives to the most commonly used APIs (e.g. push notifications) and developer documentation that provides instructions on how to switch from Google (ideally making the transition as easy as possible by emulating the Google API syntax). It would probably be possible to offer an installable platform-agnostic push notification API that developers can use. Providers could be installed as separate apps. Google could be one such provider. Perhaps we could implement a Web Push compatible API, and reverse engineer Chrome's Firebase integration to implement it as an option from the get-go, hoping other providers show up over time. We could perhaps allow users to self-host their push service as well. Modify Gotify, an open source self-hosted push server [3], to accept push notifications in the Web Push format.
In the hacker circles it seems there's two groups of people: those who think Android is a lost cause because it will always be controlled by Google, and think Linux phones are the only real alternative, and those who believe we can actually "steal" Android back from Google and make it into a true open source project. I fall into the latter, but I think a lot more work still needs to be done if we want to achieve this.
[1] https://grapheneos.org/usage#sandboxed-play-services
[2] https://grapheneos.org/features#features
> We aren't against users using Google services but it doesn't belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut of simply bundling a very incomplete and poorly secured third party reimplementation of Google services into the OS. That wouldn't ever be something users could rely upon. It will also always be chasing a moving target while offering poorer security than the real thing if the focus is on simply getting things working without great care for doing it robustly and securely.
Push services are a bit more convenient in that they require less infrastructure both in the server-side as well as client programs (e.g. they can even be shut down and still receive messages), but nothing really prevents having an ecosystem of multiple competing push services.
> Many platforms before Apple/Google worked like this
Mobile devices are an entirely different beast with strict battery life and data usage requirements.
Another factor to consider is that Android will kill long-running background apps unless you disable battery optimization for said apps through a convoluted process (even if you show a persistent notification). [1] It would be really inconvenient for users to have to manually disable battery optimization for every app that wants to send push notifications.
[1] https://github.com/gotify/android#disable-battery-optimizati...
As far as I know, Android still allows background applications though. The only constraint is that you have to show a persistent notification (that the user can hide). IM clients like Conversations.im will attest to that.
(iOS does not -- and thus creating a real Jabber client that does not depend on push notifications is impossible)
Specifically with regards to notifications the main things I care about are instant messaging apps (WhatsApp, Telegram, Signal and Element) and email notifications. All of these apps fall back to either their own implementation of a persistent connection or use the OS' APIs for background job scheduling and polling. In my experience, having a handful of persistent background connections does not significantly impact battery life (<5%/charge). Also, modern Android has Doze[1] mode. Unless an app is granted a battery optimization exception, its scheduled tasks (polling) will run within a brief period every N minutes, where N depends on how long the device has been inactive. This is what I want in most cases. I personally only give IM apps a battery optimization exception. Notifications from other apps are usually less urgent/important.
However if you want the convenience of having a single connection for all your notification delivery, GrapheneOS[2] (an AOSP-based OS with many security and privacy improvements) has a compatibility layer for Google Play services[3] that allows it to be run with non-system privileges (i.e. the same as every app the user installs). That means you can choose exactly which permissions are granted to it. For example, you can revoke all permissions except Network[4]. This lets you use Google's FCM service without Google knowing anything about you except your IP address (and the contents of your notifications).
Using Google as the notifications middleman is an ugly crutch though[5], but this setup is solid. This is only necessary because they have convinced Android developers to use their APIs, but alternatives can and do exist. I think UnifiedPush[6] is going in the right direction, but they haven't gained much traction yet.
[1] https://source.android.com/devices/tech/power/platform_mgmt
[3] https://grapheneos.org/usage#sandboxed-play-services
[4] https://grapheneos.org/features (ctrl-f Network permission toggle)
[5] similar to using Apple as the notifications middleman, although the incentives are slightly different
The big surprise here is/was that Google intends to charge a "service fee" to developers who use an alternative billing system.
> We recognize, however, that developers will incur costs to support their billing system, so when a user selects alternative billing, we will reduce the developer’s service fee by 4%. For example, for the vast majority of developers who pay 15% for transactions through Google Play's billing system, their service fee for transactions through the alternate billing system would be 11%.
I was hoping that at some point in the weeks to follow, they'd clarify how this is supposed to work. Presumably Google will require me to send them a report of how much money I'd made?
And then I guess I'd write Google a check for 11% of my earnings…?? Quarterly? Monthly? What happens if I miss a payment?
And then I guess I'd write Google a check for 11% of my earnings…?? Quarterly? Monthly? What happens if I miss a payment?
There has to be some sort of callback into the app on successful payment so that the purchased functionality can be unlocked. Seems like Google would be able to inspect the combination of the app purchase metadata and the callback activity to come up with their vig. Just my guess though.
This isn't particularly uncommon for revenue based licensing agreements. For example, Epic requires you to file a quarterly report once you commercially release a product based on the Unreal Engine. (https://www.unrealengine.com/en-US/release)
I'm also guessing that this means that third party payment processors will have to register to be available on this new API.
> We recognize, however, that developers will incur costs to support their billing system, so when a user selects alternative billing, we will reduce the developer’s service fee by 4%. For example, for the vast majority of developers who pay 15% for transactions through Google Play's billing system, their service fee for transactions through the alternate billing system would be 11%.
You have to pay a 11% fee for using someone else's billing system when buying an in-app purchase, if that app was downloaded from the Play store?
The penalty for noncompliance is so low because the money is so huge, and nobody will go to jail, that they are going to pull every stunt in the book until someone has the guts to start shutting these companies down. By claiming they are complying technically, while obviously not, they force the government to follow up the legislation with a regulatory action, which then they can tie up in the courts for years.
If they complied with the law properly now, other countries would quickly follow suit. But if they can tie up the attempt for a number of years, they can all pad out their retirement funds before all the litigation is over and duck out before the stocks crash.
It's not like we don't know how to do this stuff, we just don't invest enough in it.
Another USA company tried to do that as well. They called their OS "Windows Phone" and it withered and died because a fractured support for software people care about doesn't make a useful device.
A Chinese company tried to do that as well. They now again ship Google Services next to their own Huawei services in Europe because without software support, their smart devices weren't useful to users either.
South Korea is a small market. The US company is famous for mismanaging its mobile operating systems for more than 2 decades.
The Chinese company didn't "try" to do that, it was forced to. But guess what, in China, where most external apps are banned, there's an entire, completely separate ecosystem.
You do need a combination of skill and critical mass. I don't expect South Korea to achieve this, but for example if there's a bigger alliance of say, South Korea, the EU, etc., where they put resources into encouraging an OS based on open standards, that starts to look feasible.
App developers will need support, but they can port their apps. Especially since this OS doesn't need to start from scratch, it can be based on AOSP.
That's probably the biggest thing Google/Apple are afraid of this point, that a fully open/interoperable mobile OS is somehow enforced. They either have to open up their OSes to be in key markets or they're forced to let someone else create that OS.
Therefore, logically, Apple should be the one paying app developers 30% of their revenue. Witout them iPhone would be an overpriced paperweight.
There are also plenty of other mobile phone OS, that are not compatible with every phone and that is the main issue why they are not widespread. Phone that I own is supported not only by Android(and Android forks), but also couple of other mobile phone OS. The trend is that in future there will be more choices for OS, that might satisfy those users, that are currently not happy about Android, but have no other choices at the moment.
There are at least 10 other mobile OS choices - most of them are based on Linux, but current share of those is ~0,1% out of ~6 billion of phones. In total numbers that is only 6 million devices. 6 million device market is a significant number for any company, not to mention, that this number is only playground compared to 1000x larger world market of mobile phones.
All these governments don't have an issue with the code, they have issues with project governance.
The EU has already fined Google, South Korea is adding these new rules, I think even the US is thinking about some regulation, let's see what happens in a few years.
iPhone has branded itself as status symbol that people are rich and can pay and maintain lifestyle that includes ipHone - Androids, well - it is replacable and will be eventually.
So you are saying Google / Apple are above the law, capitalism is more important than democracy?
Where does this end? They might as well start acting as mafia, resort to raketeering and break you legs if you don't show up for work.
Is there any other reason i missed?
On the more practical side, it's kinda hard to make yours work. You probably don't want to charge a popular free app like Wikipedia the same as an app like Netflix.
they do? then why does my phone have a uninstallable 'galaxy store' app that Samsung decide to fill my limited storage with.
Time to split app distribution from OS. Making it mandatory to allow other stores, with first class user experience, and not set their as default one.
What other manufacturers can't do is fragment the ecosystem and prevent people from also using Play Store.
https://www.paypal.com/us/webapps/mpp/merchant-fees#statemen...
In the US, PayPal is a 4.99% + fixed (US: $0.09).
Yup, ecosystem: https://en.wikipedia.org/wiki/Braeburn_Capital
For those that don't understand what that is, Apple's products, especially the App Store, have insane profit margins. Apple's profits are so high that they don't know what to do with the money so they started their own investment fund.
> In October 2012, CNET reported that Braeburn had US$117.2 billion under management, making it "the world's biggest hedge fund."
That was in 2012. Since then they've almost tripled the amount of Apple money that they manage.
So we should expect companies to only profit to a point of net-zero? Or can you call out a percentage of revenue that is acceptable?
Just as people who are too rich distort democracy.
The fee is for: - access to install base and customer relationship - funds development of the platform, SDK, and tools - funds development of the store - funds operation of the store - profit for the company - last and least: payment processing
Could those things be funded differently? Yes... but it would require a radical restructuring of the way mobile platforms work that would not be favorable to startups or independents. It would also lead to massive fracturing of the customer relationship, lower trust, and ultimately shrink the total dollars spent on software (though the big players would make more money). People trust Apple or Google with their credit card. They know the platform requires all subscriptions show up in one place and they don't need to call and argue with a sales rep to cancel. Be prepared for all of that to disappear when it becomes a free-for-all. Stop pretending this kind of "freedom" is completely free of consequences even for those who don't take advantage of that "freedom".
""" Android & the Google Play Store: The free Android operating system enables hardware manufacturers to build a wide range of devices at different price points that gives users unprecedented choice. And the Google Play Store delivers the world's largest selection of apps and games, available in over 190 countries with personalized recommendations and easy discovery of high-quality apps.
New Android platforms: We build platforms for new form factors such as Auto and TV to help developers increase their reach in new ways.
Security: Consumers trust Android and Google Play because of its security, the reviews of apps to ensure they comply with policies around safety and privacy, and with automated security of Google Play Protect that scans over 100 billion apps per day.
App distribution: Developers can instantly reach over three billion Android users with the ability to optimize delivery by device and functionality and provide ongoing updates.
Developer tools: Developers can run experiments, beta test, optimize store listings, analyze performance, and more. """
This is the rent seeking that everybody is objecting to.
> funds development of the platform, SDK, and tools
The platform is open source. So if you want to use someone else's tools then you shouldn't have to pay this part, right?
> funds development of the store - funds operation of the store
The cost of providing this is negligible. Many alternative stores and repositories do it for free. It accounts for zero percent of the cost of anything.
> profit for the company
Profit isn't a separate thing. The cost of payment processing already includes the profit of the payment processor etc.
> last and least: payment processing
Which is the only thing left, so if you're using someone else as payment processor...
It's the "access to install base and customer relationship" that they're really sticking it to you for, and that's the illegitimate one.
Android is Open Source, Google Play & Google Play Services are not. Developers are free to build Android apps that don't use anything related to Google Play.
> The platform is open source. So if you want to use someone else's tools then you shouldn't have to pay this part, right?
The platform here includes "android", so yes if you aren't using Android you probably don't need to pay to support Android development. It's not clear here, but do you think "open source" somehow means "doesn't require funding to develop"?
> The cost of providing this is negligible. Many alternative stores and repositories do it for free.
Few/none of those provide app review and various anti-malware stuff. You can argue that these have negative value, but they absolutely have non-negligible costs.
Also I don't think any alternative stores support canarying/progressive rollouts of new versions, which is useful for developers and a nontrivial to support for other stores.
Yes, it is true, that there are other stores - like Samsung has it's own store on Android, so technically there is a choice of stores. Apparently Google would not fight store wars with the producers of hardware... but there is nothing that prevents them to disable any other stores by any other means - by simply sabotaging their app.
The issue here with Google Play is that it assumes, that Google Play has monopoly of money transactions for that publisher outside of Play store, even if the app has a choice to receive money through oher means - crypto, Paypal or cards. Same issue is with Apple store - they did not wanted to allow to transact money in Epic store(and wanted their cut on those), where you could make transactions in the Epic website from your card.
You have a career in comedy if you think that the Play Store's definition of canary rollouts is good. Hell, the entire Play Console is probably one of the most hated piece of software by android devs because of how terrible it is, with constant changes, horrible performance, stupid requirements and non-working options.
<<Google Play Had a Profit of $8.5 Billion in 2019 With Margins of 62 Percent. According to court filings unsealed>>
https://www.thurrott.com/mobile/android/254978/google-play-h...
So, no, with indecent margins like that, you can't justify them using their monopoly to racket app developers with fees that are unrelated to the usage of the service.
Imagine if everyone was doing the same in real life, that would look absurd:
- your power utility provider requiring that you pay to them 10% of your business income because you use electricity somehow and they have costs and need to do profit
- the postal service requiring you to pay 15% of the bills you send by email through their online service or 10% of the bills you send by any other provider just because you benefit from receiving standard letters in your home mailbox. Just because they have costs and they need to do fat profits.
- Ikea forcing you to give them 11% on your business incomes because you use a desk and a chair that you bought there in your office. For the same reasons...
You know that high margins are someone else's opportunity? Surely someone else will build an alternative that undercuts Android.
Ah, you say there's a huge moat? Worth billions if not trillions of dollars? Huge market recognition? Agreements with huge companies? Regulations and government approvals all over the world? Years and years of development by thousands of developers?
On top of that there's an oligopoly in place by companies already convicted of such agreements for other issues (see the anti-poaching agreement from a decade back)? What? Like a cartel that probably fixes prices?
They very well can make these stipulations and expect you to pay them. They have every right to go "uh we need 100% of your business profit if you want to buy IKEA furniture". You have every right not to do that due to the unreasonable payment terms. You'll need to ask your lawmakers to fix this if you think it's unjust and you're being forced against your will to oblige.
Google could charge accordingly without any "radical restructuring".
When you are buying a phone, you also pay price that includes price for OS of the phone, that includes development costs of SDK and development tools. Some of the phones nowadays has a choice to BUY and install different OS, that comes with different stores.
Unlike your assumption, payment processing is completelly different ecosystem and Apple is simply using monopoly on iPhones and not letting other stores on their hardware and software. Alphabet does not produce phones... so IMO it is acting worse, that it makes up these stupid tales. This is one of the reasons why I am switching my phone from Android, because that is MY phone, that I paid for! Besides, Android still snoops your data without your consent and I'm not even paid for that data!
Besides, the only concern about payment processing that YOU should have is not development costs(they can't be that HUGE...), but if your payment processing is safe and protected!!! That is the only costs, that stores should have - to ensure protection of those many many transactions, where maintenance and development costs are miniscule and to be even considered is laughable topic.
With the race to the bottom on cheap Android phones, it's obvious that "profit from the device only" is insanely low.
> Some of the phones nowadays has a choice to BUY and install different OS, that comes with different stores.
Just pointing out that this seemingly directly contradicts your line before it. If some phones can install a different OS and come with a different store, why should the phone profit margin go towards developing the SDK and development tools?
First of all it is now possible to make tax declarations yourself without going through a customs agent. Previously if you bought something like a dashcam from AliExpress you'd need to pay VAT and a "processing fee" to the agent (i.e. the post office) which in total would come to around the same price as you paid the seller. It's still somewhat complicated to do yourself, but the post office here introduced their own electronic declaration system. If you choose to use their system it's €3, but if you choose to do it yourself you need to pay a "parcel handling fee" of €3.
Additionally the regulations require sellers sending goods to the EU to charge VAT at the time of purchase. So everything you buy from AliExpress now is sold with VAT (but prices are still shown without). The post office also introduced a €1 handling fee for these parcels - that they don't need to do anything with other than deliver them.
Google now says the fee is for the "ecosystem". They are taking people for fools and hiding the real story: they are a monopoly and they only do this because they are forced by the people of South Korea
Present title: Google Play permitting alternative billing systems for users in South Korea
The title is editorialised and reads like this is something Google is doing of their own volition, whereas they’re merely complying with (new) law.
If you sell an app on an alternative store, how do you get the average person to install it? Adjust your marketing materials to teach them how to find the hidden "allow unknown sources" toggle on their phone, and then say something like: "Just ignore the many scary warning messages telling you that you're about to get a virus, and implying that we're malicious. Also, don't let it scan us for malware, not because we're malware, but because Play Protect may end up accidentally blocking us, and we have no idea how to get that reversed".
And even if you do that and manage to get enough customers to qualify as a potential competitive threat, Google will put together a task force[1] to destroy you.
1: https://www.androidcentral.com/google-fortnite-task-force
Usually a button next to the "Google Play Store" and "Apple App Store" buttons?
If the developer feels they have to support some store's users themselves with installation and troubleshooting, they should just get their own app side loaded and maintain a direct relationship.
I wouldn't expect Microsoft to give me directions to a Best Buy to pick up Office 365.
> they should just get their own app side loaded and maintain a direct relationship.
How do you get the average person to sideload an app? Whether it's a store or a single app, Google Play will always have an unfair advantage.
Part of the deal was that they couldn’t tell anyone about it without Google’s permission. So when you get a rejection from an OEM after you offer to bundle your store, you don’t get an explanation.
Will Netflix have to raise their subscription rate by 120% or more?