The Better You Get at React Native, the More You Need to Understand Native

When I began working with React Native, one of the most appealing aspects was the promise of "write once, run on both iOS and Android." While React Native does offer a powerful way to share code across platforms, after years of building and maintaining React Native applications, I've come to understand that as you become more proficient in React Native, the more critical it becomes to grasp native development.

This isn't because React Native is incapable; rather, real-world mobile applications eventually encounter the limits of the operating system.

React Native allows for the sharing of a significant portion of the application: UI components, business logic, API integration, state management, validation, networking. However, Android and iOS possess their own unique systems, including permission systems, app lifecycles, build systems, security models, and native APIs, as well as distinct release processes.

Instead of adhering to the mantra "write once, run everywhere," I find it more accurate to say, "share what should be shared, and adapt what is genuinely platform-specific."

The need for deeper native knowledge typically arises when something doesn't behave as expected. This could be a push notification behaving differently on iOS, a library requiring Android configuration, a release build failure despite working during development, biometric or security features necessitating deeper platform integration, or background tasks performing inconsistently between platforms.

These are not necessarily React Native problems but rather mobile platform issues. Understanding where to look can make a substantial difference.

As developers progress in their careers, their approach shifts from asking "how do I implement this in React Native?" to "where should this functionality actually live?" The answer can be JavaScript, React Native, a native module, or even different implementations for Android and iOS. This transition signifies the difference between knowing a framework and understanding mobile engineering.

Should one always opt for React Native? Not necessarily. React Native is a great choice when the Android and iOS product experiences are similar, the team desires faster development, a large portion of the business logic can be shared, and the product doesn't heavily rely on specialized hardware. However, native development becomes necessary when the product demands heavy graphics or gaming, integration with highly specialized hardware, deep platform-specific capabilities, fundamentally different experiences across Android and iOS, or requires extremely fine-grained platform control.

The key takeaway is not that one technology is superior; rather, it's about selecting the right tool for the specific problem at hand. My advice to those learning React Native today is not to stop there but to also learn about Android and iOS, build systems, app lifecycle, and native APIs. While becoming an expert in Kotlin or Swift may not be necessary, it's beneficial to be comfortable investigating what occurs beneath React Native when encountering platform-specific issues.

Eventually, you will realize you are not merely a React Native developer; you are a mobile engineer who employs React Native. This realization is likely the most significant lesson I've learned from working with React Native.