Bridging the Gap: How to use React Native in existing large native code bases
summary
Claims concrete tradeoffs: initial approach uses a separate JS repo with a multi-repo CI shim that clones iOS and Android, builds bundles, and pushes artifacts — slow and non-atomic but low friction; long-term wins come from migrating to a mono repo for atomic PRs and single dependency management. A custom native navigator gets built to preserve native nav bars, do shared-element transitions, and keep animations native. Reality check: deployment works, live reload and code push exist, and production usage is ~107 registered screens and ~71k JSLOC (~10–15% of the app).
AI-written summary · about
chapters (8)
- 0:00Start
- 4:18The Multi-repo Problem
- 7:59The Multi-Repo (benefits) - Path of least friction
- 10:43The Mono-Repo (benefits) - Atomicity for Native + JS changes
- 11:54The Navigation Problem
- 24:07Advantages - Easily transition to and from native/react
- 26:00Disadvantages - NavigationBar not in React
- 26:45Additional Challenges
related talks
24mIntegrating React Native into an existing native codebase
41mReact Native - A native love story
28mCross-Platform React
25mGoing Native
01h 13mMigrating to React Native: A long-term retrospective
45mReact Native: Things we learned the Hard Way
07mFrom Native to React Native
28mShould I use React Native too?
