Plan for the day the App Store says no

If your entire business runs through one app, and a reviewer you’ve never met can pull it from the store without warning or explanation, you don’t have a product. You have a permission slip. Someone else signs it, and someone else can tear it up on a Tuesday afternoon while you’re asleep.

I didn’t take this seriously until I watched a rejection email land on a build that hadn’t changed in any meaningful way. Same app, same behavior, a policy interpretation that drifted overnight. Nothing was wrong with my code. The door I’d walked through a dozen times was just suddenly closed, and every operation that depended on that app, every driver, every dispatch, was now waiting on an appeal queue I had no leverage over.

The dependency you forgot to write down

We’re careful about dependencies in code. We pin versions, we vendor libraries, we worry about a package getting yanked from a registry. Then we ship the whole thing through a distribution channel we don’t own and never think about it as a dependency at all.

It is the biggest one you have. A gatekeeper that can remove your only customer-facing surface, on its own timeline, for reasons that are sometimes a real violation and sometimes just a reviewer’s bad day, is not infrastructure you control. It’s a relationship you’re hoping stays warm.

The mistake isn’t using the store. For most products there’s no realistic alternative, and the reach is the whole point. The mistake is treating that distribution as if it were yours, on the quiet assumption that the app you have today is the app you’ll have tomorrow.

Distribution you don’t own is a dependency, not a foundation. Treat it like the single point of failure it is, before it fails.

Know where the side door is, even if you never use it

The fix isn’t dramatic and it isn’t about routing around the rules. It’s about knowing the building has more than one exit before there’s smoke in the hallway.

• Have a path to push a forced update from your own source. If a critical fix can only reach users through a review queue that takes days, your incident response is hostage to a third party. Wire in a mechanism to deliver a build directly, even if every normal release still goes through the front door. You want the capability to exist and be tested, sitting unused, so it’s there the day you actually need it.
• Know how to side-load against live before you’re forced to. Installing a build outside the store and pointing it at production isn’t a hack, it’s a fire drill. The time to figure out signing, provisioning, and the install flow is a calm afternoon, not the hour after a takedown.
• Separate your business from the single binary. The more of your operation that can keep running, dispatch, payments, the back office, while the customer app is in limbo, the less a rejection is an extinction event and the more it’s an inconvenience. Decouple so one closed door doesn’t dark the whole building.

None of this is about defying the gatekeeper. I follow the policies, I make the appeals, I play it straight, because the front door is genuinely the best way in and I want to keep using it. The point is narrower and calmer than rebellion: I just need to know the side door exists, and that the key turns, before I’m ever trapped behind the main one.

You’re insuring against an afternoon

The whole exercise costs a few days of engineering and the discomfort of building something you hope to never use. That’s the deal with insurance: a small known cost now against a large unknown cost later, and the temptation is always to skip it because the bad day feels abstract.

It isn’t abstract. The bad day is a specific reviewer, a specific email, and a business that suddenly can’t reach its own users while a queue you can’t jump decides its fate. I’d rather spend the calm afternoon learning where every exit is than discover, mid-fire, that I only ever knew the one that just locked behind me.