Leaving Google Play: what one developer's exit costs

Daniel Gultsch spent twelve and a half years selling Conversations on Google Play, and his post on leaving Google Play puts a figure on what the store cost him: Google's 15% cut came to more than €1,000 a year, and as he wrote it he had been waiting 14 days for Google to review an app update. F-Droid is now his primary distribution channel. Here is what that decision proves, and what it does not.

The facts he states, all of them his own account:

• Conversations launched on Google Play on 24 March 2014; the post is dated 24 September 2026, twelve and a half years later.
• Google takes a 15% cut of his app sales, which he says works out at more than €1,000 a year.
• He had been waiting 14 days for review of an app update at the time of writing.
• Conversations has been removed twice from the Play Store, and updates rejected more times than he can count.
• The F-Droid build is now built reproducibly and signed with his own key, and the app is free.

What the developer says leaving Google Play actually cost him

Conversations is a federated XMPP instant messaging client for Android. The developer says he started it in January 2014 in a student dormitory, released it publicly on 24 March 2014, and made it a business by the old open-source bargain: the source is public, the compiled binary is paid. Ever since, he says, Conversations or related work has been his primary source of income.

Play Store revenue was the steady part. He used to say it paid his rent — regular money next to the lumpy invoicing of contract development, server setup and consulting, and later grants from NLnet and the European Commission. He says that grant funding is now secure until the end of 2029, which is the detail that made the exit possible.

His complaints are operational, not ideological. The developer says app updates have been rejected more times than he can count for incomprehensible reasons, that Conversations has been removed from the store twice, and that Google once accused him of uploading users' contacts — an accusation he says simply was not true and was not triggered by any particular update. He describes going up against "AIs and click workers" with no way to reach a human.

The part that should worry anyone shipping an Android app is the review queue. He says review times were never good but have got a lot worse over the last year, and that Google makes no distinction between a feature update and a security update. A security fix sits in the same queue as a redesign. He calls delaying security updates by days or weeks outright dangerous, and on that specific point he is plainly right: your patch is not deployed until the store says it is.

What does Google Play charge?

Google's published service fee is 15% on the first $1M of revenue a developer earns each year and 30% above that, with subscriptions at a flat 15%. Google's own page also notes that from 30 June 2026 the EEA, UK and US move to a structure based on whether an install is new or existing, with rates in a 10–25% band plus billing fees. As of September 2026, a small paid app in Europe is paying the 15% tier.

The developer's arithmetic is the memorable part. He says €1,000 a year is 1.5 times what he pays for internet access — about €667 on his own figures — and roughly what his notebook costs him per year if you assume three to four years of use. When the internet breaks, he says, someone drives to his house. When the notebook breaks, someone drives to his house. When Google gets it wrong, there is nothing he can do. That is the comparison, and it is a fair one to make of any supplier.

There is also a quieter cost in his story that no fee schedule shows. He says that for years he felt he was in a toxic relationship with Google and the only reason he stayed was economic dependency. Dependency is the actual variable here, not the percentage. A supplier you cannot leave will eventually set terms you would not have agreed to, and the moment to notice that is while the revenue still looks steady.

When alternative app distribution is viable for a business app

Four things were true at once in his case, and a business app usually has at most two of them: the revenue was replaceable, the audience is technical, the code is free software, and another funder had already committed. Secure grant funding to 2029 is not a distribution strategy most companies can copy.

The constraint teams miss is F-Droid's own entry bar. The F-Droid inclusion policy requires every app in the main repository to be free and open source software, and strictly forbids proprietary tracking, advertising and analytics libraries — Google Play Services, Firebase and Crashlytics are named. You must ship a FLOSS alternative or a build flavour without them. For a typical commercial Android app that means losing FCM push, Crashlytics, Google Maps and your analytics SDK in one go, or maintaining a second build that has none of them.

The other half of the bargain is build transparency. F-Droid compiles from public source to verify the binary matches, and verifies reproducible builds by copying the APK signature from your signed APK to its own rebuild and checking it still verifies. That is a genuinely stronger supply-chain guarantee than a store review, and it is why the developer's line about a reproducible build signed with his own key matters. It is also engineering work your team has to do.

What you need	Google Play	F-Droid or your own repo
Paid app or in-app billing	Built in, 15% of the first $1M	Not available; Conversations is now free
Ship a security fix	Same queue as features; he waited 14 days	You publish when you are ready
Crash reporting and push	Firebase and Crashlytics normal	Forbidden in the main F-Droid repo
Proof the binary matches the source	Store review, not reproducibility	Reproducible build, signature verified
Someone to appeal to	He says there is no human	Nobody to appeal to either — it is your repo

What you give up: discovery, billing and updates

Give the counter-argument its strongest form first. The 15% is not only a tax. It buys payment processing, VAT and sales-tax handling across dozens of jurisdictions, global binary delivery, device integrity checks and, above all, an install base that arrives without marketing spend. If you had to rebuild that stack, most teams would spend more than 15% of revenue doing it. His exit works because grants replaced the revenue, not because the alternative rails are cheaper.

Discovery. Off Play, you are the distribution channel. Your website, your existing users and word of mouth do the work the store search box used to do. That is survivable for an app people seek out by name and fatal for one that depends on category browsing.

Billing. There is no in-app purchase rail outside the store. The developer's answer was to stop charging; Conversations is free now. If your model is a paid app, an alternative channel is a second channel, not a replacement.

Updates. The store pushes updates to every installed device. A repository can do the same for users who installed the client, but anyone who sideloaded a bare APK gets nothing automatic, and in the systems we build that gap is where unpatched versions accumulate. If you go this route, budget for an update mechanism as a first-class feature rather than an afterthought.

Trust signals. Enterprise buyers and security reviewers still ask for a store listing, and a procurement checklist rarely has a row for "distributed from the vendor's own repository". You can answer that question with a reproducible build and a published signing key, but you will be answering it, every time, rather than pointing at a listing.

How this interacts with Android developer verification

Leaving the Play Store does not leave Google's identity requirements behind. We covered the Android developer verification cutoff on 30 September and, in more detail for teams shipping internally, why that date blocks stores rather than individual APKs. Read both before you assume an alternative channel is outside the rules; the practical question is who signs and who is registered, not which store you list on.

F-Droid is not neutral on this. Every page of its documentation currently carries the line "F-Droid is under threat. Google is changing the way you install apps on your device." Treat that as a party to the argument stating its position, and confirm the current requirements against Google's own documentation before you commit a release strategy to them. The same applies to Play's own moving deadlines — our post on the target API level 36 extension ending on 1 November is the same category of risk in the opposite direction.

The decision we would actually make

For most of the Android app development work we do, the answer is a second channel, not an exit. Keep the Play listing for consumer billing and for the procurement teams who expect one. Add a direct or enterprise channel for the builds that must ship on your schedule — internal tools, field apps, anything where a 14-day review wait is an operational risk rather than an annoyance. Ship the same reproducible artifact to both so the two binaries are provably the same software.

This is the wrong choice if your app earns through in-app purchases, if your install growth comes from store search, or if your team cannot maintain a build flavour with no proprietary SDKs. In those cases the 15% is buying something real and the honest move is to negotiate your dependency on it, not to perform an exit.

Before anyone argues about the commission again, measure what the store actually returns: the fee you paid last year against the installs the store originated, and the median age of the version your users are running. One developer's numbers made his decision obvious. Yours will not be obvious until you have your own.