There's an easy version of code push, and I could have shipped it months ago.
The easy version handles the parts that were never really the problem — the surface stuff. It demos well. It works on your machine. And it quietly falls apart the moment a real app on a stranger's phone does something you didn't anticipate. I've seen enough tools that stop exactly at the edge of the hard part to know the shape of that trap.
I didn't want to build the thing that demos well. So I went down instead of across — into the layers most app developers never touch, and most sane people never volunteer for.
Why not just do the easy 90%?
Because the last 10% is the entire product.
Anyone can make an over-the-air update work in a controlled demo. The value isn't in the demo — it's in the update that lands correctly on hardware you'll never see, under conditions you didn't test, and fails closed when something's wrong instead of crashing in someone's hand. That guarantee is the whole thing a developer is actually buying. And you cannot bolt it on afterward. It has to be true all the way down, or it isn't true at all.
So "the easy 90%" was never an option that led anywhere. It leads to a tool people try once, get burned by, and never trust again. The only version worth building was the one where the hard part is solved for real — which meant going as deep as the hard part goes.
What "deep" actually cost
I'm not going to walk through how — that part's the company, and I've written elsewhere about why I keep that door closed. But I'll be honest about the shape of it: it meant working below the SDK, against runtime behavior that was explicitly designed to make what I wanted impossible, with a failure mode of a crash on a real device and no undo button.
It was slow. It was frustrating in the specific way that only systems work is — where you can be one wrong assumption away from a fix for days, and the only thing that tells you the truth is the device itself, not your reasoning about it. I adopted a rule early and never broke it: the device is the only authority. Not "it should work." Not "the logic is right." Does the physical phone do the thing, or doesn't it. Everything else is a story I'm telling myself.
That rule cost me a lot of comfortable green checkmarks that turned out to be lies. It also saved me from shipping several of them.
Why it was worth it
Because "over-the-air updates for Flutter" is a claim a dozen things can make, and "over-the-air updates for Flutter that land correctly on real hardware and fail safe when they don't" is a claim almost nothing can back. The depth is the moat. Not because it's secret — because it's genuinely hard, and hard-won things are hard to catch up to.
I went this deep because the shallow version isn't a product. It's a demo with a countdown timer on it. And I didn't spend months of my life to ship a countdown timer.