On 28 August, Google stopped accepting updates to AnkiDroid, a free open-source flashcard client with more than ten million installs. It sells nothing. Its only funding is an Open Collective page, and a link to that page is what Google Play’s payments policy objected to. Unless the dispute is resolved, AnkiDroid is removed from Google Play worldwide on 11 September, everywhere except India and Russia.
The maintainers are stripping the link out of the Play build under protest, because the alternative is losing most of their users. That is the version that reached the front page. The part that should worry anyone running a product is different: for two weeks, an unresolved argument about a subsection of the United States tax code has sat directly on top of a team’s ability to ship anything at all.
TL;DR
- Google Play rejected AnkiDroid updates from 28 August over a donation link, with removal scheduled for 11 September 2026. A dispute over one UI element blocks every unrelated fix in the same queue.
- Store review is a single-threaded, unversioned dependency with no SLA. If you owe a regulator a corrective measure on a clock, as the EU Cyber Resilience Act now does, it sits on your critical path.
- The rule deciding AnkiDroid’s case is the gap between IRC 501(c)(3) and 501(c)(6). A US tax classification is now a product architecture input for European teams.
- Digital Markets Act enforcement opened external payment links on Google Play, but the service fee applies regardless of billing method. Steering changes the channel, not the margin.
- Android developer verification lands in four countries on 30 September 2026 and goes global from 2027. The “we can always sideload” fallback now has an identity requirement and a date.
The dispute is not the risk. The queue is.
App store policy is almost always discussed as a fairness argument: whether the platform should be allowed to do this. That framing treats the outcome as the risk. The outcome is not the risk. The mechanism is.
Store review is a queue you do not control, with no published service level, no versioning and no deprecation policy. It is also single-threaded with respect to your product: a rejection over one element blocks the entire binary. AnkiDroid did not lose the ability to ship a donate button on 28 August. It lost the ability to ship a crash fix, a data-loss fix, or a security patch.
Put that next to what regulators now expect. We wrote recently about the Cyber Resilience Act’s reporting clock, which starts on 11 September 2026 and requires a final report within fourteen days of a corrective measure becoming available for an actively exploited vulnerability. “Available” is doing a lot of work there. If your product ships through an app store, availability is not the moment CI goes green. It is the moment a reviewer you have never met approves a build, and that reviewer’s queue may currently be occupied by an argument about your pricing page.
Most teams have a rollback plan for their own infrastructure and none at all for a blocked release channel.
The veto reaches into your interface
The second uncomfortable detail is what the remedy looks like in code. The fix is not a metadata edit. It is the removal of a visible feature, shipped as a variant that now differs from the build the same team publishes elsewhere. Generalise that: any surface whose legality depends on a platform policy can be vetoed on someone else’s timetable. Pricing displays, external links, referral flows, account deletion paths, tipping features, third-party login options, anything touching money that leaves the platform.
The engineering answer is unglamorous. Policy-adjacent surfaces should be driven by configuration rather than hard-coded, so removing one is a flag flip and not a refactor, and per-channel build variants should exist before you need them, because standing one up under a deadline is how teams ship the wrong variant to the wrong store. That configuration has to be data, not code: Play’s restrictions on remotely-hosted code mean a flag can return a value but must not return behaviour, the same constraint Manifest V3 imposed on browser extensions. Review latency is your release cadence, so the fewer changes that require a review, the better.
The deciding rule is in someone else’s tax code
Google’s payments policy carves out an exception: Play billing must not be used for tax-exempt donations. AnkiDroid’s fiscal host, Open Source Collective, supplied an IRS determination letter confirming exemption under Internal Revenue Code section 501(c)(6). Google’s position is that this does not qualify, its policy citing 501(c)(3) charities “or the local equivalent”. The distinction now being argued in a public issue tracker by people who are mostly not tax lawyers is between an organisation exempt from tax and one whose donors can also deduct the gift.
Operationally, that means the eligibility of a feature in an app used worldwide turns on a subsection of the United States Internal Revenue Code, adjudicated by a support queue with no stated appeal timeline. For an Irish company, “the local equivalent” of a 501(c)(3) is not obvious: a registered charity under the Charities Act 2009 with a CHY number is the nearest match, but a company limited by guarantee or a co-operative may not be recognised by a reviewer working from a US-shaped policy. If any part of your funding model depends on that recognition, your legal structure has stopped being a finance decision and become a product dependency. Settle it before you build the feature, not after the removal notice arrives.
The EU opened the channel and kept the fee
There is genuine movement here, and it is being widely misread. On 23 July 2026 the European Commission fined Google 890 million euro for Digital Markets Act breaches, reported as 460 million for search self-preferencing and 430 million for Google Play’s anti-steering rules, with sixty days to comply. Separately, from 30 June 2026 a new fee structure in the US, EEA and UK permits alternative billing and external web links, with other markets staggered into 2027.
The headline everyone took is that you can finally link out to your own checkout. True, and less useful than it sounds. Read the rate card: the service fee applies regardless of whether you use Play’s billing system, alternative billing or an external link. What you avoid by linking out is the additional billing fee, currently five per cent where Play billing is used in those regions, and you then pay your own processor instead. Steering is a channel change, not a margin change. It gives you the customer relationship, the receipt, the dunning email and your own pricing experiments, all worth having, but it does not give you back thirty per cent. Model it as a customer-ownership decision with a modest fee delta and you will make the right call; model it as a cost saving and you will be disappointed.
The escape hatch is being registered
The traditional answer to all of this is that Android is open, so distribute outside the store. That answer is quietly acquiring an expiry date. Android developer verification requires app registration for participating stores in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, covering Google Play alongside the Honor, Oppo, Samsung, Transsion, vivo and Xiaomi storefronts, with global expansion signalled for 2027 and beyond. Unregistered applications remain installable through ADB or a new advanced sideloading flow, and a limited distribution tier allows sharing to a handful of devices without government identification, which covers hobby projects and internal test builds but not a product.
For most teams this is administrative rather than existential, and Google has shipped a Developer ID Status API and Developer Console API so registration can be automated in a pipeline. Sideloading is not dying. What is changing is that your fallback path is becoming a verified, identity-bound channel with registration state that can, in principle, be revoked. If your “we will just send the client an APK” plan assumes an unconditional escape hatch, that assumption now has a date on it.
What to do this quarter
- Write down your review latency. Pull the last ten submissions per store and record the median and the worst case. That is your real time-to-fix for anything shipped in the binary.
- Identify your out-of-band path. Expedited review, server-side kill switch, remote configuration, or nothing. If it is nothing, say so explicitly rather than discovering it.
- Inventory your policy-adjacent surfaces. Everything touching payments, external links, accounts or age, with confirmation that each can be disabled by configuration.
- Settle the entity question before you build. If donations or non-profit pricing are in the model, get the classification confirmed in writing and keep it where whoever handles an appeal can find it.
- Re-cost steering honestly. Compare the full service fee plus your own processor against Play billing, not against thirty per cent.
- Put registration in the pipeline. Developer verification is a build prerequisite with an owner and a renewal date, alongside your signing certificates.
None of this depends on whether Google is behaving reasonably. It rests on a structural fact that predates the dispute and will outlast it: the channel through which your software reaches users is a dependency you cannot pin, cannot fork and cannot read a changelog for. Teams that treat it as infrastructure absorb these events as a bad fortnight. Teams that treat it as a background assumption find out how it works on the day it stops.
REPTILEHAUS builds and maintains mobile and web products across Ireland and Europe, including the release engineering and platform contingency work that keeps them shippable. If you are not sure what happens to your roadmap the day a store says no, get in touch.
📷 Photo by Árpád Czapp on Unsplash
