WhoBuilt

Adopting Cross-Platform React Native at Scale: Zalando’s Learnings

Sep 16, 2025· 25 min· 1.0K views·Watch on YouTube

Speaker

Rene Eichhorn, senior software engineer at Zalando, shares Zalando’s learnings adopting React Native at scale at RUC 2025, presented by Callstack.

Why Zalando explored React Native

Zalando had separate iOS and Android codebases totaling about 500,000 lines, built over 10 years. The team wanted faster development and experimentation while keeping the existing app running and preparing for future needs, including web.

Adopting React Native gradually

Eichhorn describes integrating React Native screen by screen, with A/B tests to control rollout. Zalando aimed to avoid disrupting native engineers’ workflows or carrying existing architecture’s technical debt into the new setup.

A development app and a production framework

The React Native entry point is packaged for two consumers: a standalone development app and a framework used by the production app. A prebuilt developer app connects to local Metro or CI bundles, while the production framework exposes a small API for initialization and creating native views.

Sharing web concepts and UI

Zalando aimed to share useful code across web and mobile while preserving platform differences. Its existing Rendering Engine provides common application concepts such as data fetching and caching; React Strict maps HTML-like elements to platform components, and shared component libraries can use platform-specific files when needed.

Keeping state and platform choices flexible

Zalando’s Traits library defines typed actions and state so modules can depend on capabilities such as navigation without depending on their implementation. Teams can share logic or use different implementations by platform, preserving the option to build native features.

Takeaways

  • Plan extra time for brownfield React Native adoption; integration has gotchas beyond the basic documentation.
  • Use a standalone development app connected to local or CI bundles to make iteration easier across native and web engineers.
  • Keep the production integration behind a small API for initialization and view creation.
  • Decide deliberately which code and concepts to share, while preserving platform-specific behavior where it matters.
  • Use typed interfaces between modules and state management to keep implementation choices flexible.

Mentioned in this talk

Search inside this talk

What was claimed 10

Related talks