The Wall
None of these rules are hidden. They just do not announce themselves while you are designing, and by the time they matter you have already built the thing they forbid.
A field guide to the rules that kill products right before launch
Two days before launch, one line in the app store rules killed a product I had already built.
Not a bug. Not a rejection. A rule that had been sitting there the whole time, that I had no reason to read until the thing I had built ran straight into it.
The frustrating part is that none of these rules are hidden. They are published. They are searchable. They just do not announce themselves while you are designing, and by the time they matter you have already built the thing they forbid.
This is the list I wish someone had handed me at the start.
The five walls
1. The audience wall
The rule. The moment a product is directed to children, an entirely separate body of law switches on. In the US that is COPPA. Google Play has its own version, and its Families policy triggers when your audience merely includes children, not only when it is exclusively children.
Why it bites late. You do not declare your audience in code. You declare it in your marketing, your screenshots, your app store category, your icon. Regulators look at all of it. You can build something technically neutral and still be considered child-directed because of how you sold it.
The trap I hit. My app embedded a third-party video player. That player shows its own ads. Once a product is child-directed, the developer carries responsibility for those ads, not the platform serving them. "They are the same ads as the regular site" is not a defence.
Spot it early. Write your app store description on day one. If it implies children, you have just chosen a legal regime. Choose it deliberately.
2. The payments wall
The rule. App stores take a cut of digital purchases made inside the app, and they are specific about what you may show. Some apps qualify as reader apps and can keep purchases outside the app entirely, but then the app must show no pricing, no plans, and no path to checkout.
Why it bites late. Pricing UI is something you build early and casually. A plan comparison table feels like a design problem. It is a compliance surface.
Spot it early. Decide your payment model before you design a single pricing screen. If you go the reader route, every price and tier must be conditional on platform from the first line of code. Retrofitting it means auditing every screen.
3. The account deletion wall
The rule. If your app lets people create an account, it must let them delete it. Apple requires it. Reviewers test it by tapping the button.
Why it bites late. Deletion is the least glamorous screen in any product, so it gets stubbed. Mine signed the user out and deleted nothing. A button that lied, sitting in production, until I checked.
It is also not only an app store issue. Under GDPR and CCPA, "delete my account" is a promise with legal weight behind it.
Spot it early. Build deletion when you build signup. Test it by actually deleting something, then querying the database to confirm it is gone. A success message proves nothing.
4. The "is it really an app" wall
The rule. App stores reject apps that are thin wrappers around a website with little native value.
Why it bites late. Wrapping a web app is the fastest way to ship to mobile, and it works beautifully, right up until review.
Spot it early. Know what makes your app worth installing rather than bookmarking, and be able to say it in one sentence.
5. The claims wall
The rule. What you say about your product is part of your product. Marketing copy is evidence. Evidence of who your audience is, of what you promised, of what you are liable for.
Why it bites late. Copy is written last, often quickly, usually by whoever is least worried about it.
The discipline. Write down the claims you will never make, before you need them. My list includes never claiming the app blocks ads, because it embeds a player that shows them. What I can say honestly is what the product actually does: no recommendations, no autoplay, no wandering off. That is a better line anyway, because it describes a benefit instead of a technicality.
The pattern underneath all five
Every one of these walls has the same shape.
A constraint that lives outside your codebase, that you cannot see from inside your product, that becomes unavoidable at the exact moment you try to ship.
You cannot debug your way past them. You cannot design around them once you have hit them. The only defence is to go find them before they find you.
A pre-launch checklist
Run this at the start of a project, not the end.
Audience
- Who is this for, by age? Write it down
- Does anything about my marketing, category, icon, or screenshots suggest a younger audience than I intend?
- If my audience includes minors, which regimes attach, and have I read them rather than skimmed a summary?
Money
- How do people pay, and where does that transaction happen?
- Does any purchase interface appear inside the app? Should it?
- Is pricing conditional on platform from the first line of code?
Third parties
- What do I embed that I do not control? Ads, players, trackers
- If a regulator held me responsible for what that third party does to my users, would I still ship it?
Promises
- Does every button do what it says? Especially delete
- Have I verified deletion by checking the data is actually gone?
- What claims will I never make? Write the list before you need it
Reality
- Does my app justify being an app?
- Have I read the actual guidelines, or only what people say about them?
The one that saved me
When I hit the wall, the instinct was to fight it. Find a workaround, argue the edge case, engineer around the rule.
What actually worked was changing who the product was for.
Same product. Different audience. Every legal wall dissolved, and it turned out there was a community being served badly by everyone: teens and adults with autism and intellectual disabilities, using tools designed for small children.
Sometimes the wall is not telling you to build differently. It is telling you that you built the right thing for the wrong people.
This is a practitioner's field guide, not legal advice. The rules change, they vary by region, and the specifics of your product matter. When something here applies to you, read the current source and talk to a lawyer.
I am Aneil Razvi, a product design and AI experience leader. Cubby, my personal project, is a caregiver-curated video app for teens and adults with autism and intellectual disabilities.
Available for fractional design leadership and advisory work.
First published on LinkedIn on 5 August 2026. Read the comments there →