CONCEPT Cited by 1 source

Progressive screen-level RN migration¶

Progressive screen-level RN migration is the adoption mode for a brownfield React Native rollout: migrate one screen at a time, each on its own risk budget, while the legacy native app continues to ship through its normal release cadence. It is the rollout-time counterpart of React Native as a package — the integration architecture enables the progressive strategy.

Why screen-level granularity¶

The alternative — migrate the entire app to RN in one pass — fails for an app at consumer-app scale:

Scope too large. Zalando's two native apps together host 90+ screens. A big-bang rewrite is a multi-year freeze with no intermediate business value (Source: sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native).
Risk too concentrated. Any architectural mistake in the rewrite affects the entire app on first deploy. No gradient of de-risking.
Team dynamics. Every team blocked on the RN migration simultaneously; feature development halts.

Screen-level migration inverts each of these:

Scope is bounded per unit. One screen at a time; predictable-size effort.
Risk is isolated. A broken RN screen doesn't take the rest of the app down; the legacy native screens continue working.
Team dynamics. Teams self-select the screens they're ready to migrate; feature work continues on screens that haven't been migrated yet.

Dependencies¶

Screen-level migration requires three capabilities to be in place before the first screen migrates:

RN-as-a-package architecture — so the legacy app can mount RN screens alongside native screens without restructuring the whole codebase. See concepts/react-native-as-a-package.
Turbo Module + DI contracts for shared concerns — wishlist badge, session state, navigation, deep-linking, analytics. Each RN screen that needs any of these must have a clean contract to call into the legacy app. See concepts/turbo-module-di-contract.
Developer App with mocks — so screen development doesn't require the full legacy-app build. See concepts/greenfield-developer-app-for-hybrid-engineers.

Without these, screen-level migration degenerates into "RN screens that are tangled with legacy code and can't be iterated on independently."

Zalando's rollout sequence¶

Zalando's post walks through the progression (sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native):

First screen: low-traffic, simple. Purpose: exercise the pipeline, not deliver value. See patterns/early-launch-on-low-traffic-screen.
Several more screens migrated, major and minor.
Discovery Feed (front screen, media-heavy, Q2 2025 results) — validates the architecture at front-screen traffic and media-surface complexity.

As of the post's publication (2025-10), migration is explicitly ongoing: "For us, the migration is still ongoing but we have successfully migrated a few screens..."

Contrast: Shopify's team-level migration¶

Shopify's 2025-01 five-year RN retrospective describes a different granularity — per-team-per-app migration (see sources/2025-01-13-shopify-five-years-of-react-native-at-shopify and concepts/shared-mobile-foundations). The difference:

Zalando: one legacy app per platform, many teams, many screens. Granularity is screens because screens are the natural migration unit within a single app.
Shopify: many apps (Shop, Merchant, POS, Local Delivery, Inbox, etc.), one team per app typically. Granularity is apps/teams because apps are the natural migration unit across a portfolio.

Both canonicalise "progressive adoption" but at different altitudes.

Seen in¶

sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native — canonical wiki first source. Zalando lists progressive adoption as one of the three pillars driving the RN decision, and walks through the low-traffic-first → Discovery-Feed sequence.