React Native at Scale With Rafael Mendiola

Mendiola describes different entry points: startups may use React Native for an iOS and Android MVP, while scale-ups may add Android after first building for iOS. Enterprises may consider it when uneven team sizes lead to slow or inconsistent delivery across web, iOS, and Android.

He says teams should weigh delivery speed, user impact, and the talent they already have. Web developers can learn React Native, but mobile brings platform-specific issues and a longer tail of app versions, so bugs can persist after release. Mendiola recommends keeping experienced native engineers on the team to handle native modules, tooling, and platform bugs.

Mendiola sees the main benefit as delivering features across platforms more consistently by reusing JavaScript expertise and coordinating teams around a feature. For enterprises, he advises checking for delivery bottlenecks first, then setting a clear target and testing React Native on a new feature integrated into existing native apps. Baseline data can help show stakeholders whether the change improves delivery.

Adoption can raise concerns among native developers who fear their work is being replaced, so Mendiola recommends explaining the operational goals and involving an internal champion who can address stakeholder concerns. He also points to hands-on learning sessions, clear ownership, and teams responsible for developer experience, tooling, and CI/CD. Performance problems, outdated dependencies, unclear team boundaries, and unowned code can all slow delivery.

Mendiola’s main frustration is that React Native lacks a single product vision, so developers must follow multiple sources to keep up. He values company-backed open-source projects because they can make enterprise adoption easier. He would like React Native companies to collaborate on a shared production pipeline covering needs such as continuous integration and visual regression testing.