Every time code push comes up, someone asks the same thing: isn't that against App Store rules?

It's a fair question, and the answer is more interesting than a yes or a no. The short version: over-the-air updates and Apple's rules aren't enemies — as long as you understand where the line actually sits. Most of the anxiety around this comes from not knowing where that line is, so let me walk it.

What the rule is actually about

Apple's guideline 3.3.2 is the one that governs downloaded and executed code. The exact wording has shifted over the years, so read the current text on Apple's App Store Review Guidelines rather than trusting anyone's paraphrase — including mine. But the enduring principle has been remarkably stable: an app may download and run code to fix bugs and improve itself, as long as doing so doesn't materially change the app's features or its primary purpose from what Apple reviewed and approved.

That principle is the whole game. Everything about staying compliant follows from it.

The distinction that matters

There's a world of difference between two things that sound similar:

Updating the behavior of an app within what it already does — and was already approved to do.
Turning your app into a shell that downloads its real functionality from a server, or changing its primary purpose after review.

The first is well-trodden and uncontroversial. The mildest form of it is something you already ship without thinking twice: feature flags and remote config change what your users see without a new build, and nobody considers that a violation. Code push is further along the same spectrum, not a different kind of thing.

The second is what gets apps rejected — and should. If you use an over-the-air mechanism to smuggle a fundamentally different app past review, you're on the wrong side of the line regardless of which tool you used. The tool doesn't launder intent.

This lane has existed for years

None of this is new territory. React Native's over-the-air updates, the old App Center CodePush, Expo's update system — an entire generation of apps has shipped over-the-air fixes, and Apple has coexisted with all of it. Not because anyone found a loophole, but because staying inside the approved envelope is exactly what those tools were built to do.

Flutter's version of this capability is newer. The compliance principle is identical.

Where Koolbase sits

Koolbase's code push is firmly on the first side of that line. It's for shipping fixes and improvements fast, inside the envelope your app was already approved for. It is not a way to change what your app fundamentally is between reviews, and it was never designed to be — staying inside 3.3.2 was a constraint from the first day, not an edge to test later.

I say that plainly because I think the fear around code push is mostly a knowledge gap. The rule and the capability aren't at war. Understand the line, build to stay inside it, and you get to ship a one-line fix in minutes instead of waiting days for it to clear review — which is the entire point.

This post is my read of a developer-facing policy, not legal advice. Always check the current guidelines for your specific case.