CONCEPT Cited by 1 source
Greenfield developer app for hybrid engineers¶
A greenfield developer app (in the brownfield-RN context) is a parallel, standalone React Native application built and maintained alongside the main legacy app. It consumes the same RN Entry Point package the main app's Framework SDK consumes, but ships with a standard RN toolchain — no legacy-native-app build required.
Its purpose is not to be shipped to end users. It exists to give RN contributors — especially web engineers transitioning to mobile — a fast, isolated iteration loop that doesn't require them to master the full native-app build environment.
The friction it removes¶
Without a dedicated Developer App, every RN contributor has to:
- Install Xcode (iOS) and Android Studio (Android).
- Understand the full legacy app's build configuration (signing, provisioning, schemes, variants).
- Wait for the full native-app build on every iteration.
- Context-switch between native and RN toolchains for anything they can't do in the RN layer alone.
For a team whose RN contributors come from a web background — the Rendering Engine / Interface Framework lineage at Zalando, say — that friction is a productivity tax that compounds. Zalando's post calls this out: "Building a large native app can be slow, despite build caches. Having to build the entire app to get started with React Native, especially for engineers coming from a web background (and unfamiliar with tools like Android Studio and Xcode), posed a major problem, affecting productivity and causing friction in onboarding web engineers." (Source: sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native)
What it requires¶
A viable Developer App requires:
- Shared Entry Point package between the Developer App and the Framework SDK. The RN code runs identically in both. See concepts/react-native-as-a-package.
- Mocked native contracts for features that depend on the legacy app's state. If an RN screen needs to call the legacy app's wishlist system, the Developer App supplies a mock implementation of the same Swift/Kotlin protocol. See concepts/turbo-module-di-contract.
- Developer-experience utilities — JS-bundle switching (released versions, PR builds, local), custom dev menus, observability hooks. Zalando's Developer App has a custom menu on top of RN's default.
Why this is not just "running the RN layer in isolation"¶
The naive version — "just run RN's own app shell" — misses the point. The Developer App is a product in its own right: it has a shipping discipline, a custom dev menu, a bundle-switching feature, mock contracts that mirror the production protocols, and a team that maintains it. It's an investment that pays off by unlocking the web-engineer contribution pool for RN work.
This is the organisational pattern that comes with brownfield RN adoption at scale. Greenfield RN (where the whole app is RN from day one) doesn't need it — the whole app is the developer app.
Seen in¶
- sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native — canonical wiki first source. Zalando's Mobile Developer App is the worked example.