React Native App Development for Startups: iOS and Android From One Codebase

If your product needs to be on both iOS and Android, React Native is worth understanding properly before you pick a direction. It is the framework Wall & Fifth uses for mobile builds — not because it is the fashionable choice, but because for the products most startups and scaling businesses are building, it is genuinely the most practical one. That said, cross-platform covers a wide range of quality levels, and the difference between a React Native app that feels native and one that feels like a wrapped website is significant.

This page covers how the framework works, where it performs well, where it does not, what the app store submission process looks like in practice, the mobile builds Wall & Fifth has shipped, and how to think about whether mobile-first or web-first serves your product better. If you are at the very earliest stage and have not yet validated the idea, the MVP development service is the right starting point — a mobile MVP can be built fixed-price from £30,000 in eight weeks.

Why React Native rather than Swift or Kotlin for most startup builds

Building separate native apps in Swift (iOS) and Kotlin (Android) means two codebases, two sets of engineers, two release cycles, and two sets of platform bugs to track. For an early-stage company, that overhead rarely makes sense unless the product genuinely requires capabilities that React Native cannot reach.

React Native lets developers write TypeScript and React — skills that overlap heavily with web development — and produce apps that render actual native UI components on both platforms [3]. A button in a React Native app is not a simulation of a native button; it is the platform's own UIButton on iOS and android.widget.Button on Android. This is a meaningful distinction from frameworks that draw their own pixels.

The practical hiring argument is also real. The pool of engineers who can work competently in TypeScript and React is substantially larger than the pool of engineers who specialise in Swift or Kotlin. UK labour market data supports this: permanent React Native vacancies reached 234 in the six months to May 2026, up from 168 in 2025, with the median UK salary rising to £70,750 from £67,500 the year before [7]. More vacancies and higher pay signals growing commercial adoption. For a startup that may need to hand off or grow a team after launch, being on a mainstream, hireable stack matters.

Expo Application Services (EAS) also enable over-the-air JavaScript updates that reach users without going through app store review [5]. For product teams that need to ship fixes quickly or iterate fast on real usage data, this is a meaningful operational advantage over traditional native development.

The New Architecture: what changed and why it matters

The single most important technical development in React Native over recent years is the New Architecture. Any studio building on the old bridge-based approach is building on a dead-end stack.

The old architecture routed all communication between JavaScript and native code through an asynchronous JSON bridge. Every layout measurement, gesture event, and native call required serialisation in both directions, making synchronous native access impossible and causing frame drops under heavy load. The New Architecture replaces this with four interconnected components [8]:

The timeline is clear from multiple sources. React Native 0.76 (October 2024) made the New Architecture the default for new projects. React Native 0.82 (October 2025) permanently removed the legacy Paper renderer — there is no flag to restore it [3]. The legacy bridge codebase was frozen in June 2025 with no further features or bug fixes [8]. Expo SDK 55 removed legacy architecture support from its managed workflow entirely [3].

Wall & Fifth builds on the New Architecture as standard. The recommended production stack in 2026 is Expo SDK 56, targeting React Native 0.85 and React 19, with the Hermes V1 engine as the default JavaScript runtime [3].

One important caveat from the official React Native documentation: enabling the New Architecture does not automatically improve performance or user experience for every app type [13]. Gains are most visible in animation-heavy and data-dense screens. For most business applications, the architecture change eliminates previous constraints rather than producing dramatic benchmark improvements from day one.

What React Native cannot yet do as well as native

Honest assessment here matters. React Native's performance has improved substantially with the New Architecture, but there are categories of product where the trade-offs become genuinely significant.

• Graphics-intensive and game experiences. Apps where frame-perfect GPU-driven animation or real-time rendering is the core experience are better served by fully native development or a dedicated game engine. React Native renders native views, but heavy GPU workloads sit outside its natural territory [4].
• Certain device API integrations. Not every native platform API has a React Native equivalent. Accessing platform-specific features sometimes requires writing custom native modules in Swift or Kotlin and bridging them into the JavaScript layer — which requires engineers who understand both environments and adds delivery time [4].
• AR and VR applications. Augmented reality and virtual reality experiences require deep native integration and frame-rate consistency that sits outside React Native's natural territory.
• App bundle size. React Native apps bundle the framework alongside the application code, meaning they tend to be larger than equivalent native builds. For users on constrained storage or slower networks, this is worth considering [4].
• App startup speed. Current benchmarks suggest React Native app startup is somewhat slower than native, with memory usage modestly higher — though UI thread performance and scroll performance are close to native for standard interactions [10]. For standard business applications, most users will not notice these differences.

For standard business applications — marketplaces, SaaS tools, e-commerce apps, fintech dashboards, social platforms, logistics trackers — React Native's performance with the New Architecture is entirely sufficient. The limitations become meaningful for a specific and relatively narrow category of product.

The real difference between a React Native app and a wrapped website

A web app wrapped in a browser container (a WebView) and submitted to the App Store is not a React Native app. It looks different, performs differently, and often violates App Store guidelines in ways that cause rejections. React Native renders actual native UI components using the platform's own component system — not a browser rendering engine.

What makes a React Native app feel native is not the framework label but the component choices and animation implementation. Native-feeling gestures use react-native-gesture-handler, which runs gesture logic on the native thread. Smooth animations use react-native-reanimated, which runs animation worklets entirely on the UI thread, making 60fps and 120fps animations achievable without JavaScript overhead [5]. A FlashList behaves as smoothly as the platform allows for long scrolling lists. Transitions follow platform conventions rather than web conventions.

The test to apply when evaluating a cross-platform app is simple: does it feel like it belongs on the platform, or does it feel like a website in a frame? A well-built React Native app should pass that test without qualification.

React Native vs Flutter: a clear-eyed comparison

For most product companies building on TypeScript web stacks, React Native is the natural extension. Flutter is the right call when you are specifically optimising for what it does best: pixel-perfect parity at 120fps, or apps where custom canvas rendering is a genuine advantage [3].

App store submission in practice

Both Apple's App Store and Google Play have review processes, and the most common reason first submissions fail is avoidable with preparation. Wall & Fifth handles App Store and Google Play submission as part of a mobile project — this is not handed back to the client to figure out.

Common rejection reasons on first submission include: a missing privacy policy (required by both stores if the app collects any user data); incomplete or inaccurate app descriptions; use of private APIs; placeholder content left in the build; and guideline violations around in-app purchases — any digital goods sold within an app must use the platform's own payment system. Apple's review process typically takes one to three days; Google's is often faster but can vary.

Structuring a first submission to avoid delay means testing on a real device across both OS versions, preparing accurate metadata and screenshots in all required dimensions before submission day, having a working demo account ready for reviewers, and making the app's core functionality accessible without edge-case setup. Rejections on a first submission are not unusual, but the common ones are preventable.

Once an app is approved, EAS Update allows JavaScript-layer changes to be pushed over the air without going back through review. Post-launch iteration is substantially faster than traditional native development — a hotfix or a contained feature change can reach users within minutes rather than days.

Wall & Fifth mobile builds

Wall & Fifth has shipped multiple React Native and native iOS products. Three from the portfolio illustrate different demands:

jottt is a daily focus app with a deliberately constrained model: three task slots, no backlog, no categories. It is live on the App Store and was built as a Wall & Fifth internal venture. The product design challenge was making severe constraint feel considered rather than unfinished — every interaction detail had to carry the product's point of view.

embrk is a yacht charter management app for owners and operators, also live on iOS. It holds fleet management, routes, guest experience, and commercial data in one place, designed for people running charters from a phone rather than an office. The build required careful offline consideration and data model design for a domain with genuinely complex state.

Loopa is a social discovery app currently in development, listed on the work page. Each of these products demanded a different set of technical decisions — which is part of why Wall & Fifth builds its own ventures rather than only working on client products. The sharpness of those decisions carries into client work.

Hypothetical example: a marketplace app with buyer and seller flows

This is a hypothetical example to illustrate how a React Native scope is typically structured.

Suppose a founder wants to build a marketplace app — buyers browsing and purchasing, sellers managing listings and payouts — for both iOS and Android. The core product decision is whether this starts as a mobile-first build or a web-first build with a companion app. For a marketplace, web-first is often the right answer: listings are discoverable via search, sellers can manage inventory on desktop, and the web product validates the core transaction before the mobile layer is added. The mobile app then focuses on the highest-frequency use cases — buyers browsing and transacting, sellers receiving notifications and managing active orders.

In React Native, the buyer and seller experiences would be separated by role-based routing at login. The listing grid uses FlashList for smooth performance with large inventories. Payments go through Stripe's React Native SDK. Push notifications via Expo Notifications handle seller alerts for new orders. The total codebase is one repository deploying to both stores. This scope — two user roles, Stripe integration, push notifications, and admin tooling on the web side — would fall into the Extensive MVP Build tier, scoped and priced individually before work starts. The marketplace development page covers the architectural decisions behind the platform layer.

How Wall & Fifth scopes a React Native build

The questions that determine scope — and whether mobile-first or web-first serves the product — are important to answer before a line of code is written:

• Is the core value of the product something users need on their phone specifically, or is it primarily a desktop or browser product with a mobile companion?
• How many user types does the app need to support, and do they have meaningfully different flows?
• Does the app require offline functionality, device hardware (camera, location, biometrics), or platform-specific integrations?
• What is the post-launch iteration plan — and does the team have the technical resource to maintain a native module if one is required?
• Is the product going to a consumer audience where App Store presence matters immediately, or a B2B audience where a web app might be sufficient for early validation?

Wall & Fifth mobile builds start from £30,000 fixed-price for a focused single-role app. Products with multiple user types, Stripe integration, admin panels, and marketing sites are scoped individually. The MVP cost guide covers how these numbers are arrived at and what each budget tier actually buys.

For founders building a product with a subscription or SaaS layer underneath the mobile surface, the SaaS development page covers the architecture decisions that shape whether the platform can scale commercially — billing infrastructure, multi-tenancy, and role-based access all apply whether the primary surface is mobile or web.

Back to Custom Marketplace Development UK: Building Two-Sided Platforms That Actually Transact

Related reading

• SaaS Development Company UK: Building Subscription Platforms for Founders