Google has published a new round of technical requirements for Android apps. They are published now but not enforced yet: the main two become mandatory in February 2027, and one more in April 2027. Once a rule is in force, an app that fails it gets quietly pushed down in search, and can eventually be pulled from the store. An app on the store is not a finished object sitting on a shelf. It is a thing you have to keep alive, and I am saying this from the middle of the work, because right now I am updating every app we publish to clear the new bar before the deadlines.
The store keeps moving, and it does not wait for you
Most people picture the app store like a bookshelf: you put the book there once, and it stays. An app is the opposite. Leave it alone and it slowly stops working, because the phones, the operating system and Google's own rules all keep moving under it.
The changes come on two fronts. One is developer verification, where every app has to be tied to a verified developer by the end of September 2026 or it gets removed. The other is a set of quality rules, and those are the ones catching people off guard. And this batch is not the last word. Google already makes every app keep pace with a new Android version each year just to stay in the store, and adds rules like these on top. Whatever you clear in February, there is another line behind it.
What actually changed
None of this is written for a business owner to read, so here it is in plain language.
Your app cannot hog the phone. When the memory rule takes effect in February 2027, Google will hold your app to a memory ceiling on cheaper phones, the ones with 4 GB of RAM that most of your customers actually own. Go over it, around 2 GB, and your app is flagged as heavy and badly behaved.
Your app has to be packaged properly. From the same February 2027 date, Google will require apps to be shrunk and optimized before they ship, not bloated with dead code. For us that means running the standard tooling every serious build should already use. Plenty of cheap builds skip it.
Your app should remember people when they change phones. From April 2027, if your app has a login, Google expects it to bring that login back automatically when someone moves to a new phone, instead of making them dig up a password. Google gives you an official way to do it, and apps that ignore it look broken next to the ones that do not.
On top of that, the rules already being enforced today: your app has to crash in fewer than about one session in a hundred, has to run as modern 64-bit software, and has to support the newer memory layout that recent phones use. Miss those and you are penalized today: a bad crash rate buries your app in search and can put a warning on its store page, and the 64-bit and memory-layout rules block you from shipping an update at all.
The part nobody budgets for
Here is the uncomfortable bit. Every one of these is a maintenance job on an app that was, as far as the owner was concerned, finished. The build was paid for a year or two ago. Nobody set money aside for "Google changed the rules again." So the app slowly rots: a new Android version breaks something, a new store rule flags it, and one day a customer messages you that the app is gone, right in the middle of using it.
This is why, when we quote a build, we say up front that it will need upkeep and roughly what that will cost, instead of pretending the price ends at launch. The web systems we built more than a decade ago are still running for exactly that reason: someone kept updating them while the ground moved under them. A build with no maintenance behind it is not a saving. It is a slow liability.
What we are doing with ours
Right now I am going through every app we publish, Fyntoo Field, Fyntoo Scan, InvoStock and the rest, and bringing each one up to the new requirements ahead of the deadlines. Not because anything is broken, but because the whole promise is that the thing keeps working after we hand it over. That promise is worth nothing if I let the apps drift the moment Google raises the bar.
Building an app is the easy part. Keeping it in the store is the job most people never price in. When we build one, we plan for exactly these requirements and tell you what the upkeep will cost before you commit, so the app you pay for is still installable two years later. If you are weighing up a build, that is the conversation worth having first. Tell us what you are trying to make, and we will be straight about what it takes to keep an app alive, not just to launch it. That honesty is the whole point of how we work.