We fixed the Play declaration and the rejection came back word for word
Ticking the wrong box on a form can get an app rejected before anyone looks at a line of code. The real surprise was that un-ticking it did not help.
Eczanow is a directory that lists the location and contact details of pharmacies in Türkiye. It does not manage prescriptions, remind anyone to take medication, diagnose anything or collect health data. Google Play’s first answer was still this:
Violation of Play Console Requirements — Some types of apps can only be distributed by organizations.
The rejection came from two form fields, not from the code
Every app on Play Console has to complete the Health apps declaration — Google asks for it explicitly even from apps that have no health features. On the first submission that form was set to “Medication and Treatment Management” and the store category to Health & Fitness.
Google is specific about what that category covers: medication schedule management, pill identifiers, medication reminders, prescription management, treatment plan adherence. Eczanow does none of it — it does not even show which pharmacy stocks which drug. In other words the declaration was simply wrong.
And the price of it was fixed: since 2024, health apps can only be published on Play by an organization account. With an individual account, the app hits an account-type wall before anyone looks at what it does.
Health apps declaration: “My app doesn’t provide any health features”.
Category: Maps & Navigation (alternatively Travel & Local).
⚠️ Skipping the form is not an option — Google requires the declaration from apps with no health features too.
Corrected, resubmitted, identical rejection
The declaration was changed to “no health features”, the category to Maps & Navigation, and the app resubmitted. The rejection text came back word for word.
There is only one reasonable reading of that: Play’s classification is not re-derived from the form at submission time. The “Medication and Treatment Management” flag from the first declaration is stuck to the app record, and the rejection text arriving byte-identical suggests nothing was re-evaluated at all.
It goes through the same automated check and returns the same answer. If two submissions produced the same text, a third only costs you days. At that point the move is not to rejoin the queue — it is to change the queue.
Two moves, in parallel
- Appeal. It puts the case in front of a human, and only a human can clear a stuck flag. Free, a few days. ⚠️ After a second rejection the odds are poor; do not plan optimistically around it.
- Organization account. Needs a legal entity and a D-U-N-S number; free, but it can take weeks. Which is exactly why it should be started without waiting for the appeal result.
Writing the appeal had one rule: every sentence has to be verifiable from the code. An unverified claim in a store appeal costs more than the rejection did — you lose your credibility for the next review too.
How it ended
The app was approved while the appeal was still in flight, and the closed test went live. To be honest, we do not know which one worked: the appeal, or a delayed re-evaluation of the corrected declaration. The second is the likelier explanation.
What to take from it
- There is no “roughly right” answer on a store form. One field can get you rejected before a single line of code is reviewed.
- A wrong declaration sticks. Correcting it later may not clear the flag — which is exactly what filling it in correctly the first time is worth.
- If the same rejection arrives twice, stop resubmitting. Change the process instead: appeal, account type, or scope.
- The two stores do not apply the same rules. iOS was untouched by this — Apple allows the Medical category on an individual account. While Play was blocked, that was the open road to users.
Eczanow