The Gate

What it's like to hand your work to a black box and wait

For weeks you are in total control. Every screen, every rule, every decision is yours, and you can change any of it in minutes. Then you package it up, hand it to a reviewer you will never speak to, and wait.

Building solo, the hardest part was not the building. It was the gate at the end of it. Here is the honest version of what that gate was actually like.

A confession about how my app is really built

My iOS app is my website in a wrapper. The native shell loads the live site, so most of my review fixes shipped as ordinary web deploys, not new app binaries. When I bumped the build number, half the time it was not to change the code. It was just to send a fresh copy back into the review queue. That one architectural choice shaped everything that followed, including the mistakes.

Rejection one: my entire marketing site was inside the app

The first rejection taught me something I should have caught. Because the native shell points at my real website, technically the whole site was in the app, every marketing route included. A reviewer tapped Back on the sign-in screen and landed on my full landing page, pricing and all, inside a native app that is not allowed to sell that way. I had bolted the front door and left a hallway wide open. I fixed it, redeployed, and resubmitted the same day.

Rejection two: the rule I did not know I was breaking

The second rejection was a deeper problem. Even after I hid every price and every plan, the reviewer flagged that I still let people create an account on the phone. There is a specific rule for apps like mine: if an account can eventually reach paid content, you cannot offer sign-up inside the app at all, even with no prices shown anywhere. That is not a bug you patch. It is a decision you make about what the product is.

So I made it. On iOS the app became sign-in and watch only. Accounts get created and managed on the web. Billing lives on the web. That was not a workaround to sneak past review. It was me finally understanding the model I was actually building in, and committing to it fully.

The twist: I un-approved my own approved app

Then the part I am oddly proud of. The next build was approved. Green light, sitting there ready to release. And I pulled it back myself.

The reason had nothing to do with the code. My App Store screenshots showed real creators and their copyrighted content, because that is what I happened to have loaded while testing. Approved or not, that was not clean, and this is a product I need to be clean. I replaced every screenshot with a fictional library I built from scratch, channels and videos that do not exist, and sent it back in. Choosing to un-approve your own approved app, for a reason no reviewer even raised, was the moment I decided to trust my own bar over the finish line.

There is always another gate

While all of that was happening, a completely separate review was running in the background: the one that decides whether my app is allowed to read from YouTube at all. Domain verification, a recorded demo of the consent screen, a written justification for every permission I request, a questionnaire. Clearing the app store is one gate. There are others standing behind it that you do not even see until you are already there.

What the gate made me get right

Preparing for review forced me to say, in plain language, exactly what data my product touches and why. The sharpest thing I did in that process was collect less. I do not store a user's age or date of birth anywhere, on purpose, because storing it would create legal obligations I would rather design around than take on. I removed photo upload for the same reason. Account deletion is real and lives inside the app, not an "email us and we will get to it" promise. The PIN is labeled honestly, as a boundary between an adult admin and their viewer, not dressed up as something it is not. For a product used by people with disabilities and the people who care for them, getting that part exactly right is not a formality. It is the point.

What I am bracing for next

I have only been through Apple's gate. Google's is still ahead of me, and its rules for any audience that might include kids are broader, which is part of why I made the choices I made. I am not going to narrate a review I have not been through yet. When I go through it, I will tell you what it was actually like, the same way.

I am still in the middle of all of this as I write it. That is the honest status. The full story gets told when I am through it, not before.

The short version

• Know how your app is really built, because the architecture quietly decides which mistakes you will make
• Guard the whole product, not just the front door
• Some review flags are not bugs to fix, they are decisions about what the product actually is
• Trust your own bar over the finish line, even when it costs you an approval you already had
• The real privacy win is usually collecting less, not disclosing more
• There is always another gate behind the one you can see

---

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.