When I first began building with React Native a few years ago, it was more of a curiosity experiment. Jump forward to 2024, and I’ve seen it evolve into a production-grade platform driving apps into the hands of tens of millions. With leadership experience in mobile teams and work for clients ranging from startups to Fortune 500, I’ve seen firsthand how React Native has evolved from a scrappy newcomer to an adult player for enterprise mobile development.
The truth is that it’s more than just a developer building features on his own machine to get the apps to a production-ready state. You require excellent testing infrastructure to catch bugs prior to the users, and you’d prefer your application to function just fine when network conditions are atrocious or worse. By building products such as the RNWBL mobile app, which has been downloaded more than 30,000 times, I’ve discovered that end-to-end testing and offline-first architecture aren’t bells and whistles, they’re a bare minimum for any real mobile product.
The State of React Native in 2024
React Native has made tremendous progress, and 2024 marks a watershed moment in its maturation. The New Architecture, which had been in development for years, is now enabled by default as of React Native 0.76 released in October 2024. This is a complete rewrite of React Native’s major systems, replacing the old bridge architecture with JSI (JavaScript Interface) for synchronous communication between JavaScript and native code. The result is dramatically improved performance and seamless interoperability with native code. Full support for modern React features like Suspense, Transitions, automatic batching, and useLayoutEffect is now standard, not experimental.
TypeScript is now completely standard across the ecosystem, and the development experience has fundamentally transformed with improved debugging and rejuvenated refresh cycles. Animation libraries like Skia and Reanimated have become the de-facto standards, with 86% of developers now using them, and they’ve been optimized specifically for the New Architecture.
Most impressive is industry adoption. When I first began working with React Native, it was difficult to sell it to clients. Today, companies like Microsoft, Shopify, and many others have it at the center of their technology stack, with nearly 50% of apps now running the New Architecture, more than double what it was two years prior. Expo is now an incredibly powerful platform that takes a lot of the historical headache out of native builds and over-the-air updates. The managed workflow that early on felt constricting now handles most production cases well.
The ecosystem faces stiffer competition from Flutter, Jetpack Compose, and .NET MAUI than before, but React Native has responded with genuine technical innovation rather than marketing speak. Based on my own experience of working with several clients on Toptal, the discussion has changed. Teams no longer ask if React Native is ready for production, now, they want to know how to do it right with the New Architecture. The ecosystem has matured, with improved libraries, more defined best practices, and battle-hardened developers joining the community. The hiring market is a testament to this, with senior-level React Native gigs fetching similar rates as native iOS and Android work.
One note of caution: library compatibility is still catching up. Over 61% of the 400 most installed libraries are compatible with the New Architecture as of mid-2024, with interop layers helping legacy libraries work during the transition. This is improving rapidly, but it’s worth checking compatibility before committing to critical dependencies.
Why End-to-End Testing Is Important
End-users have no patience for broken functionality. A crashed checkout or un-submittable form infuriates users, it ruins revenue. Through my experience deploying end-to-end test pipelines that tested the complete set of application features, I’ve experienced how quality testing increases reliability and development speed.
The testing pyramid is still relevant to mobile app development, but the risks are higher. Unit tests detect logic errors, integration tests confirm component interactions, but end-to-end tests are your last line of defence against shipping buggy user experiences. During the time my co-workers and I re-factored the RNWBL app, we spent heavily on E2E testing upfront, and it paid rich dividends on our app store launch and far beyond.
The landscape of tooling has shifted considerably. Maestro has emerged as the go-to choice for many teams, built on learnings from predecessors like Detox and Appium. Its simpler setup using YAML for test definitions and excellent developer experience have made it increasingly popular, Expo has even shifted its focus from Detox to Maestro, archiving their Detox documentation for EAS. Maestro officially supports React Native’s New Architecture with no known limitations. Detox remains a viable and powerful option, now fully supporting React Native 0.77.x through 0.82.x with the New Architecture, while Appium is still the choice for teams that require cross-platform parity with web test setup. The most important thing is having a tool that gets along with your CI/CD workflow and is within the capabilities of your team.
E2E testing environment calls for cautious infrastructure. You must have emulators or simulators in your CI environment, proper test data management, and strategies to handle asynchronous operations inherent in mobile apps. Page object pattern is your closest friend from a maintainability perspective, believe me, if you don’t use it, your test suite turns into unmaintainable garbage the moment requirements change. I’ve discovered the capability to test in terms of user journeys instead of screens, which more closely reflects real-world usage and makes the tests more robust to UI changes.
Challenges there are. Bad tests are the nemesis of trusting your test suite. Platform variation between iOS and Android sees you debugging most frequently. Why does a test pass on one but fails on the other? Native modules can be wicked to test, and you may need mocks or a real native testing setup. But the alternative, manually testing each flow prior to every release, does not scale.
Numbers do not lie. After a comprehensive E2E testing on a single project, we cut production bugs by more than 60% and halved our deployment cycle time. Developers felt more confident deploying changes, and we could iterate quicker without fear of breaking current functionality. The upfront cost of test infrastructure was paid for within months.
Offline-First Architecture with Apollo Cache
Network reliability does not exist. Wherever your users are, on the tube, in the countryside, or experiencing dodgy Wi-Fi, your app must work. Having every API call offline-first in the RNWBL app wasn’t a luxury, it was a differentiator that users picked up on and valued.
GraphQL and Apollo Client are an ideal offline-first design. Apollo’s InMemoryCache is fantastically powerful once you understand the correct way to configure it. Cache policies determine how aggressively your app depends on cached data versus loading new data from the network. For offline use cases, you must be clever with fetch policies, employing cache-first or cache-only with polite fallback.
This offline-first requirement was particularly critical for RNWBL because renewable energy technicians regularly work in remote field locations, such as wind farms, solar installations, and rural energy sites, where cellular coverage is notoriously poor or non-existent. These technicians need to access equipment data, log maintenance records, and update inspection reports regardless of network conditions. An app that fails when connectivity drops isn’t just inconvenient; it renders field work impossible and forces technicians to resort to paper-based workflows that defeat the purpose of digital tooling entirely.
Persistence is where it gets fun. Apollo3-cache-persist allows you to persist your cache to AsyncStorage or other storage implementations so that it remains alive even during app restarts. All of this just makes the user experience that much nicer, booting your app immediately brings up the previous known state, even without the internet. But cache size and memory management have to be dealt with very gingerly. A rogue cache will bloat your app and make it slow.
Optimistic UI updates are necessary to deliver a responsive experience for offline interactions. When the user saves a form or updates data, you update the UI under the assumption of the best and then wait for the server response later. Rolling back correctly when this doesn’t work out is important, users require good feedback if something couldn’t be saved.
NetInfo state detection of the network will alert you when you are offline, but the question is what to do with a queue of mutations to sync once you’re online. You need exponential backoff retry logic, and you need to support cases when you can have operations that depend on or conflict with one another. Conflict resolution is increasingly a product decision because it’s a technical decision. Do you take the last write, ask the user, or use higher-order merge logic?
Security is also a consideration. Caching data, lingering about local storage, must be adequately secured if it’s sensitive information. You must sit down and figure out what to do when a user logs out or changes accounts, and make sure cached data gets flushed accordingly.
The complete configuration involves initialising Apollo Client with adequate cache policies, setting up persistence, defining network detection, implementing a mutation queue with retries, and handling all edge cases that occur. Offlining is now part of your E2E test suite, where network conditions are mocked out and data is passed through the cache layer just like it would be expected.
Bringing It All Together
The true magic happens when E2E testing and offline capability come together. Your test suite must ensure not only the happy path of pristine connectivity, but the harsh reality of bad networks and offline capabilities. Network simulation within automated testing demands the likes of network link conditioners or proxy servers that will impose latency, packet loss, or outright blocking.
I’ve discovered that actively exercising cache behaviour, ensuring data is cached in app restarts, ensuring optimistic updates roll back on failure, ensuring sync queues execute in the correct order, and catching bugs that would be extremely difficult to find manually. Your CI/CD pipeline should also have tests that test offline conditions explicitly, not as an afterthought but as a central part of your quality assurance process.
Engineer-wise, you require an understanding of offline feature behaviour in the wild. Analytics would monitor how frequently users experience offline conditions, for how long operations take to complete when waiting in line, and whether sync operations are successful. Error tracking must separate network problems from actual bugs. You input this data to create future improvements and learn about real-world user behaviour.
Looking Forward
React Native in 2024 is a production-ready, mature platform that can execute apps of any scale. The New Architecture is no longer a promise, it’s here, it’s default, and it’s delivering the performance improvements we’ve been waiting for. The toolchain has stabilised for decent tooling, and best practices have been distilled through collective experience. Having worked in this space for eight years, working at startups and Fortune 500 companies, I’d be comfortable asserting that React Native is no longer the risk play, it’s often the intelligent one.
The takeaways are obvious: invest in early E2E testing with modern tools like Maestro, design for offline scenarios even if they appear to be edge cases, and embrace the New Architecture while being mindful of library compatibility. The teams that succeed with React Native are the ones that use it as a serious engineering platform and not a hack around cross-platform development. Through using the appropriate architecture, test discipline, and offline-first mentality, you can create mobile applications that delight users and scale with your business.
