React Native Codebases: How to Share 90% of Code Between iOS and Android?

The promise of “write once, run anywhere” is the holy grail for mobile engineering leads. React Native brings this dream closer to reality than ever, yet many teams struggle to push code sharing beyond 70-80%, hitting a wall of platform-specific quirks, performance issues, and unmanageable complexity. The common advice often falls short: simply using cross-platform UI kits or patching issues with bits of native code as they arise is a reactive strategy, not a scalable one. This approach leads to a tangled codebase that is difficult to maintain and fails to deliver on the initial promise of efficiency.

The fundamental flaw in this thinking is viewing code sharing as a default outcome rather than a deliberate architectural goal. If the true key to unlocking 90%+ code reuse wasn’t about finding the perfect library, but about architecting for separation? The most successful React Native codebases are not those that avoid native code entirely, but those that master the interface between the shared JavaScript world and the platform-specific native layers. This is a shift from simple code sharing to strategic boundary management.

This guide provides an architect’s blueprint for achieving this high level of code reuse. We will deconstruct the critical decisions you must make, from establishing a performance budget and managing application state to conquering the infamous bridge bottleneck. We’ll explore how to handle data fetching efficiently and build robust native integrations, transforming the challenge of cross-platform development into a significant competitive advantage.

Native Swift/Kotlin vs React Native: When Is Performance Critical?

The first architectural decision is acknowledging that React Native is not a “free lunch.” While it offers immense development velocity, it comes with a performance budget that must be managed. For most standard UI and business logic, the performance is more than adequate. However, for tasks involving heavy computation, real-time graphics, or complex, multi-threaded operations, the overhead of the JavaScript-to-native bridge can become a critical bottleneck. The decision to use React Native is not a binary choice but a strategic trade-off.

Engineering leads must proactively identify areas where performance is non-negotiable. These often include:

• Intensive background processing (e.g., image or video manipulation).
• Custom UI components with complex gesture interactions.
• Real-time data visualization or animations that must run at a consistent 60 frames per second.

Understanding this from the outset allows you to architect your application to isolate these performance-critical parts, potentially implementing them as custom native modules while keeping the vast majority of the app in the shared codebase. For example, even a seemingly simple component like text can have performance implications; optimizations in React Native 0.72.0 led to a 20% faster text rendering on iOS by avoiding redundant object creation.

This reality is also reflected in resource consumption. A React Native application can require an additional 20 MB of memory compared to a fully native app, a factor that must be considered for low-end devices. Recognizing when and where performance is critical is the first step toward a successful high-reuse architecture.

How to Manage Complex App State With Redux or Context API?

As an application grows, managing its state becomes one of the most significant architectural challenges. A poorly managed state leads to bugs, unpredictable UI behavior, and a frustrating developer experience. In the React Native ecosystem, the primary decision boils down to using the built-in Context API or adopting a dedicated state management library like Redux. This choice directly impacts the scalability and maintainability of your shared codebase.

The Context API is an excellent choice for small to medium-sized applications or for managing localized state within a specific part of your component tree. Its main advantage is its simplicity and native integration with React, requiring minimal boilerplate. However, its performance can degrade in large applications with frequent global state updates, as it can trigger unnecessary re-renders in consuming components if not carefully optimized with techniques like `memo`.

For large-scale applications with a complex, shared global state, Redux provides a more robust and predictable pattern. By enforcing a unidirectional data flow and centralizing all state logic in reducers, it makes the application’s behavior easier to reason about and debug. While it comes with a steeper learning curve and more boilerplate, the benefits in a complex environment are substantial. The decision between them is a classic trade-off between initial simplicity and long-term scalability.

The following table outlines the key decision criteria for choosing between these two powerful tools, a critical step in architecting your application’s data flow.

The superior debugging capabilities of Redux often become the deciding factor for enterprise-grade applications. As developer Vrinch notes on DEV Community, this tooling is a game-changer for complex projects:

Redux DevTools extension allows you to inspect every action, state change, and even time travel through state history, making it easier to debug and track down issues.

– Vrinch (Developer), DEV Community – State Management in React Native

The Bridge Bottleneck That Causes Janky Animations

Nothing ruins a user’s perception of quality faster than “janky” animations—stuttering, lagging, or unresponsive UI transitions. In classic React Native architecture, this is often a direct result of the bridge bottleneck. Animations controlled by the JavaScript thread must send updates across the asynchronous bridge to the native UI thread for every frame. If the JS thread is busy with other tasks (like processing API responses or running complex business logic), it can’t send these updates in time, causing frames to be dropped and the animation to stutter.

To achieve the goal of 90% code reuse without sacrificing a smooth user experience, you must architect your animations to bypass this bottleneck. The solution is to run them entirely on the native UI thread, independent of the JavaScript thread’s workload. This is where libraries like React Native Reanimated become essential architectural components, not just nice-to-haves. Reanimated introduces the concept of “worklets”—small pieces of JavaScript code that can be executed synchronously on the UI thread.

This architectural shift allows for the creation of fluid, high-performance animations and gesture interactions that are indistinguishable from their fully native counterparts. The visualization below conceptualizes how worklets create a dedicated, high-priority path for animations on the UI thread, completely isolating them from potential blockages on the JS thread.

As this diagram illustrates, by moving animation logic off the main JS thread, the UI remains responsive and fluid regardless of other ongoing processes. This approach is fundamental to creating a professional-grade mobile application. The performance gains are not trivial; modern implementations using Reanimated 3 have demonstrated the ability to maintain a silky-smooth 60 FPS even with complex shared element transitions. Adopting this strategy is a non-negotiable step for any app where UI fluidity is a priority.

How to Write Custom Native Modules for Unsupported Features?

No matter how extensive the React Native ecosystem becomes, you will eventually encounter a feature that requires direct access to native platform APIs not exposed by default. This could be anything from integrating a specific hardware SDK (like a payment terminal) to leveraging a new, cutting-edge iOS or Android OS feature. Rather than viewing this as a failure of code sharing, a robust architecture plans for it. This is strategic ejection: the deliberate and clean integration of native code.

The modern approach to this is using TurboModules, a core part of React Native’s New Architecture. TurboModules replace the old, asynchronous bridged-based system with a more efficient, synchronous communication layer powered by the JavaScript Interface (JSI). This direct communication eliminates the overhead and serialization costs of the bridge, resulting in significantly faster and more reliable native integrations. As the Microsoft team notes, the underlying technology is a major leap forward.

TurboModules use JSI, a JavaScript interface for native code, which allows for more efficient communication between native and JavaScript code than the bridge.

– Microsoft React Native for Windows Team, React Native for Windows Documentation

Writing a TurboModule involves defining a strict interface in TypeScript, which is then used by a codegen tool to generate native boilerplate for both iOS and Android. This ensures type safety across the JS/native boundary and provides a clear contract for developers to implement. The process standardizes how native functionality is exposed to the shared JavaScript codebase, making it a predictable and manageable part of the architecture.

CodePush: Deploying Hotfixes Without Waiting for App Store Review

One of the most powerful advantages of React Native’s architecture is the ability to update an application’s JavaScript code and assets without requiring a full new build and submission to the App Store or Google Play. This capability, often managed through services like Microsoft’s App Center CodePush, is a game-changer for agility and rapid bug fixing. It allows engineering teams to deploy critical hotfixes, UI tweaks, or content updates directly to users’ devices in minutes, bypassing the often lengthy and unpredictable store review process.

The mechanism works by allowing your application to check a server for updated JS bundles and assets. If a new version is available, the app can download it in the background and apply the update the next time it is launched. This provides an incredible safety net. If a critical bug in the JavaScript logic makes it to production, you can push a fix almost instantaneously, dramatically reducing the impact on your users.

However, it is crucial to understand the primary limitation of this technology: CodePush can only update files within the JS bundle. It cannot update or change any native code (Swift/Kotlin/Objective-C). This architectural constraint reinforces the importance of the boundary management discussed earlier. If a bug exists in a custom native module, it will still require a full app store release to fix. Therefore, a sound strategy is to keep as much logic as possible, especially business logic that changes frequently, within the JavaScript layer to maximize the benefit of over-the-air updates.

REST vs GraphQL: Which Is Better for Mobile App Data Fetching?

Efficient data fetching is paramount for a good mobile user experience, where network conditions can be unreliable and bandwidth is precious. The choice of API architecture—traditionally REST or the more modern GraphQL—has a profound impact on both app performance and developer productivity. While REST (Representational State Transfer) has been the de facto standard for years, it often presents challenges in a mobile context.

The primary issue with REST is over-fetching and under-fetching. Imagine you need to display a list of user names on a screen. A standard `/users` REST endpoint might return a full user object for each person, including their address, account history, and other data you don’t need (over-fetching). Conversely, to get a user’s name and their last three orders, you might need to make one call to `/users/:id` and then another to `/users/:id/orders` (under-fetching), resulting in multiple network round-trips that slow down the app.

This is where GraphQL offers a compelling alternative. GraphQL is a query language for your API that allows the client to request exactly the data it needs, and nothing more. The client sends a single query specifying the precise fields required, and the server responds with a JSON object matching that exact structure. This eliminates both over-fetching and under-fetching in one go, leading to smaller payloads and fewer network requests. For a mobile app, this can mean a significantly faster and more responsive experience, especially on slower networks.

The trade-off is that implementing a GraphQL server is more complex than a traditional REST API. It requires a more sophisticated backend with a defined schema, types, and resolvers. However, for applications with complex data requirements and a need for high performance, the initial investment in a GraphQL backend pays significant dividends in frontend development velocity and end-user satisfaction.

The Cold Start Latency Error That Frustrates Mobile Users

A user’s first impression of your app is formed in the seconds it takes to launch. A slow “cold start”—the time it takes for the app to launch from a terminated state—can be a major source of user frustration and a primary reason for abandonment. In a React Native app, cold start latency is a multi-layered problem, but a significant portion is often attributed to the time it takes to load the JavaScript bundle into memory and have the JavaScript engine parse and execute it.

To combat this, the React Native team developed Hermes, a JavaScript engine specifically optimized for running React Native on mobile devices. Unlike the default JavaScriptCore engine on iOS or V8 on Android, Hermes is designed for one primary goal: improving startup performance. It achieves this by pre-compiling JavaScript to optimized bytecode during the application build process. This means the engine doesn’t have to parse the JS from scratch on the user’s device, significantly reducing the initial computation required at launch.

The architecture of app launch can be visualized as a series of layers, each contributing to the total startup time. Optimizing the JS engine layer with Hermes is one of the highest-impact changes you can make. The conceptual diagram below shows these distinct optimization layers, from the native shell to the final component render.

Enabling Hermes is now a simple configuration change in most React Native projects, and the performance benefits are well-documented. Analysis has shown that adopting Hermes can lead to a 40% faster startup time compared to using JavaScriptCore. Other techniques, such as using inline requires and splitting the JS bundle into smaller chunks, can further reduce this latency, but switching to Hermes provides the biggest initial win.

Mastering REST API Ecosystem Connectivity: How to Build Robust Integrations?

Achieving a 90% shared codebase is ultimately about building a single, resilient application that can seamlessly connect to a diverse ecosystem of services. Whether your backend is built on REST, GraphQL, or a mix of both, the frontend architecture must be robust enough to handle these integrations gracefully. This final piece of the puzzle is about establishing patterns for reliable connectivity and error handling, ensuring the app remains functional and responsive even when the network or backend services fail.

A robust integration strategy involves several key components. First, implementing a centralized API layer in your JavaScript code that abstracts away the specifics of each endpoint. This layer is responsible for handling authentication, adding required headers, and parsing responses. It provides a clean and consistent interface for the rest of your application, regardless of whether it’s talking to a REST or GraphQL endpoint. This abstraction makes it easier to mock APIs for testing and to swap out services in the future.

Second, a resilient mobile app must have a sophisticated error handling and retry mechanism. Network requests on mobile are inherently unreliable. Your API layer should automatically handle common network errors, implementing an exponential backoff strategy to retry failed requests without overwhelming the server. For critical data, it should also integrate with an offline storage solution (like AsyncStorage or a more robust database like WatermelonDB) to cache data and gracefully handle offline scenarios.

By combining these architectural pillars—a clear performance budget, a scalable state management strategy, high-performance animations, optimized startup, and a resilient API layer—you create a foundation for success. The goal is no longer just to share code, but to build a single, high-quality application that leverages the best of both the JavaScript and native worlds.

To build a truly efficient and scalable cross-platform application, the next step is to translate these architectural principles into a concrete technical roadmap for your team.