The New Architecture, without a feature freeze

Most upgrade projects fail the same way: a branch that lives for months, a feature freeze nobody agreed to, and a merge that lands on a Friday. We run upgrades the other way around. The app keeps shipping every week, and the migration moves forward behind it in small, reversible steps.

Inventory before code#

The first week is a census. Every native module, every library that touches the bridge, every patch in the patches folder. Each one gets a status: ready, needs an upgrade, needs a replacement, or ours to port. That list is the plan, and it is usually shorter than people fear.

Libraries that already support the New Architecture go first, on the main branch, one pull request at a time. None of them change behavior on their own, so they ship with the regular release train.

Flip the flag late#

Enabling the New Architecture is the last step, not the first. By the time we flip it, the remaining work is small enough to review in an afternoon, and the flag ships to internal builds for a full release cycle before anyone outside the team sees it.

We measure startup time, memory, and frame drops on the same low-end Android device before and after. If a number moves the wrong way, we know which step moved it.

What it costs#

Done this way, an upgrade takes longer on the calendar and much less in engineering time. Nobody waits on it, and nothing about it is a surprise.