React Native developers UK companies hire to build, share code and rescue apps

What do React Native developers in the UK actually get hired for?

React Native developers build iOS and Android apps from one JavaScript or TypeScript codebase that renders real native components. In the UK the work splits roughly into three briefs: a first app for a business that already has a React website, a second-generation app replacing something built years ago, and rescue work on an app that stopped moving when the original supplier left.

The first brief is where React Native earns its keep. If your website is built with React or Next.js, your web developers already think in components, hooks and TypeScript. An app built by React Native developers can share the same data types, API client and validation rules, which means a price change or a new product field is defined once rather than twice.

The second brief usually involves an older app built natively or with an early hybrid tool. The business wants one codebase, faster releases and a design that matches the current brand. The third brief is the one people search for late at night: the agency went quiet, the contractor took a permanent job, or the app simply will not build any more.

We are three freelance developers in India. One of us leads the React Native and web work, another of us covers cloud, data and any AI features, and the third of us runs the plan, the release calendar and your weekly updates. The sections below explain how we approach each brief and what to check before you hire anyone, us included.

Your site already runs on React: how much can the app share?

Expect to share logic, not screens. The parts that move cleanly between a React or Next.js site and a React Native app are TypeScript types, API calls, form validation, pricing rules, date and currency formatting, feature flags and state management. The parts that do not move are the visual components, because the web renders HTML and React Native renders native views.

In practice we set up a monorepo with a shared package. Your Next.js site imports it, the Expo app imports it, and a change to, say, the delivery postcode rules lands in both places at once. A UK retailer with a Next.js storefront might share 20 to 40 files this way: product types, basket maths, VAT display helpers and the checkout validation schema.

• Shares well: TypeScript interfaces, API clients built on fetch, Zod or Yup schemas, business rules, i18n strings, analytics event names.
• Shares with care: state stores and data-fetching hooks such as TanStack Query, which work on both but need platform-aware storage.
• Does not share: JSX that renders div or span elements, CSS modules, Tailwind classes (unless you adopt a native styling layer), and anything touching the browser window.

Some teams go further with React Native for Web or Expo's web output to share screens too. That can suit an internal tool, but for a public marketing site we keep Next.js in charge, because server rendering and page speed matter for search. If your site is still a plain React single-page app, it may be worth planning a move from React to Next.js alongside the app.

Expo or bare React Native: which should a UK project use?

Start with Expo unless you have a specific reason not to. The React Native documentation itself says that if you are building a new app with React Native, it recommends using a framework, and Expo is the framework it describes. Expo now handles native code through prebuild and config plugins, so the old fear of being trapped in a “managed” box mostly no longer applies.

Expo gives your React Native developers file-based routing with Expo Router, a large set of maintained native modules, cloud builds through EAS Build and over-the-air updates through EAS Update. You can still add custom native code in Swift or Kotlin through a local module, and you can still open the generated iOS and Android projects in Xcode and Android Studio.

The bare workflow still has a place. Choose it when you are inheriting a large existing app with heavy custom native code, when a hardware SDK from a supplier ships with its own build instructions that clash with prebuild, or when your organisation's security team requires the native projects to be committed and reviewed line by line.

For rescue projects the answer is often “move towards Expo gradually”. We first get the bare project building as it is, then adopt Expo modules one by one, and only switch to prebuild once the native folder has no hand edits left. That path avoids a risky big-bang migration on an app that customers are using today. The decision table further down sets out the trade-offs side by side.

Can React Native developers rescue an app an agency abandoned?

Usually yes, provided you can recover three things: the source code, access to the Apple and Google developer accounts, and the Android signing key or Play App Signing setup. With those, an app left by a previous agency can nearly always be brought back to a releasable state. Without them, the job gets harder but is rarely hopeless.

The source code is the first question. Ask the previous supplier for the full Git history, not a zip of the latest files, along with any environment files, API keys held in a password manager and the backend code if they built it. If your contract says you own the code, you are entitled to ask; if the wording is unclear, your solicitor is the right person to advise.

Store access comes next. If the app was published under the agency's Apple account, Apple allows an app transfer between App Store Connect accounts; the app keeps its reviews and ratings and users continue to receive updates, according to Apple's documentation, though TestFlight builds and testers must be removed before the transfer starts. Google Play has its own transfer process through Play Console support.

The Android signing key is the item people forget. If the app uses Play App Signing, Google holds the app signing key and you can reset a lost upload key through Play Console. If it uses an old self-managed key that nobody can find, you may have to publish as a new listing. We check this in the first two days so there are no surprises later.

What a React Native takeover audit checks in the first week

A takeover audit answers one question: fix or rebuild? We spend roughly the first week reading the code, attempting clean builds on both platforms and writing up what we find in plain English, with each issue rated by risk and effort. You receive the report whether or not you hire us for the next phase.

• Does it build from a clean checkout on current Xcode and Android Studio, or only on one person's laptop?
• Which React Native and Expo SDK versions are in use, and how many major upgrades behind is it?
• Is the New Architecture enabled, and which libraries in package.json block it?
• What does Android target? Google Play requires new apps and updates to target Android 16 (API level 36) from 31 August 2026, so an old target stops updates.
• Where are secrets stored? We look for API keys committed in plain text.
• Which analytics, crash and advertising SDKs start before any consent is given?
• Is there test coverage, a CI pipeline, and a written release process?
• Are backend APIs documented, versioned and still hosted on an account you control?

If more than half the screens need rewriting and the architecture is several major versions out of date, a rebuild in current Expo usually costs less over two years than patching. If the problems are clustered in a few screens and the build chain, fixing is almost always cheaper. The audit shows you the evidence either way.

Over-the-air updates: what can React Native developers ship without review?

Over-the-air updates let you push JavaScript and asset changes straight to installed apps, but only within what Apple and Google allow. Apple's App Review Guideline 2.5.2 says apps may not download, install or execute code which introduces or changes features or functionality of the app. So OTA is for fixes and small content changes, not for sneaking in new features.

Expo's own EAS Update documentation draws the same line. It lists fixing a bug in JavaScript code and updating copy, translations, UI styling or screen layouts as good uses. It lists changes to native code, native dependencies, app permissions such as camera or location, and Expo SDK upgrades as things that need a new binary. It also reminds developers that updates must follow the App Store and Play Store guidelines.

Used carefully, OTA updates mean a Friday-afternoon bug in a UK retailer's app gets fixed the same day instead of waiting for review. Used carelessly, they are a quick route to a rejection. We treat anything that changes behaviour as a store release.

UK GDPR and PECR consent for analytics SDKs inside a React Native app

Treat analytics, advertising and attribution SDKs inside your app the same way you treat cookies on your website. The ICO's guidance on cookies and similar technologies says the PECR rules can also cover apps on smartphones and tablets, not just browsers, and that app developers should give clear information about what the app does and how it uses information before users install it.

The rules changed recently. According to the ICO, the Data (Use and Access) Act 2025 lets organisations set some storage without consent, such as for statistical purposes or to improve functionality, and all its data protection provisions were in force by 19 June 2026. The ICO's guidance on storage and access technologies lists the exceptions, including statistical purposes and appearance, and each comes with conditions such as a simple means of objecting. Which SDKs qualify is a legal judgement for you and your adviser.

What React Native developers can do is make the app technically capable of whichever approach your adviser signs off. On our builds that means SDKs are initialised only after the consent decision is read from storage, the consent screen offers equal accept and reject choices, the user can change their mind from settings, and crash reporting is configured to strip personal data where the SDK allows it.

On iOS there is the separate App Tracking Transparency prompt for cross-app tracking, and both stores ask you to declare data collection in the listing. We draft those declarations from the actual SDK list so they match what the app does. For your website's side of this, see our note on UK GDPR cookie banners, and read the ICO's cookies and similar technologies guidance directly.

How much do React Native developers cost in the UK?

Quotes for React Native developers in the UK vary widely, because a “simple app” can mean six screens reading a public API or forty screens with payments, offline sync and a custom admin panel. With us, a new iOS and Android app starts from US$600. The honest answer to “how much” is the list of things that move the number.

• Existing backend. If your Next.js site already has clean API routes, the app mostly consumes them. If not, the backend is part of the build.
• Code we can reuse. Shared types and validation from your web project reduce both build time and future bugs.
• Authentication. Email magic links are quicker than Sign in with Apple plus Google plus company single sign-on.
• Payments. Physical goods can use card and wallet checkout; digital content sold in-app generally has to use the stores' in-app purchase systems.
• Offline use. An app that must work in a warehouse with no signal needs local storage and sync logic.
• Third-party SDKs. Every analytics, chat, mapping or booking SDK adds integration, consent wiring and upgrade work.
• Rescue state. A takeover is priced from the audit, because the starting condition varies so much.

Store fees are separate and paid by you directly: Apple's Developer Program costs US$99 a year and Google Play has a one-time US$25 registration fee. Our full breakdown of scopes and ranges sits on the app development cost UK page.

How to vet React Native developers in the UK before you sign

Ask for evidence you can check in a call, not a list of logos. Good React Native developers will happily share a screen, open a real Expo project, explain why a library was chosen and show you how a release gets from a pull request to TestFlight and the Play Console internal testing track.

Here are the questions we would ask if we were hiring for your project. Notice that none of them can be answered with a portfolio slide.

• Whose Apple and Google accounts will the app be published under? (The only right answer is yours.)
• Which Expo SDK and React Native version would you start on today, and why?
• How will you share code with our React or Next.js site, and what will stay separate?
• Show us how you would roll back a bad over-the-air update.
• How do analytics SDKs wait for consent in your builds?
• What happens to the code and credentials if we part ways after launch?
• Who else on your side knows this codebase if you are unavailable?
• What do you not do? (A straight answer here is a good sign.)

Our own honest limits: we do not visit offices, we do not supply hardware or run device labs of hundreds of phones, and we are not the right fit for a programme that needs twenty engineers. If you want a broader checklist, the questions to ask an app developer page goes further.

React Native vs Flutter vs fully native: which should a UK business pick?

Pick React Native when your web team works in React or Next.js and you want the app and site to share logic and hiring pool. Pick Flutter when there is no React on the web side and you want pixel-identical custom UI on both platforms. Pick fully native Swift and Kotlin when the app is mostly about one platform's deep hardware features.

Both cross-platform options produce apps that pass store review and feel native to most users. The difference is less about performance these days and more about your organisation: who will maintain the code in three years, which language your developers already know, and how much logic already exists in TypeScript.

If your deciding factor is budget rather than technology, compare notes with our Flutter app development company UK page and the wider native vs hybrid app comparison.

How long do React Native developers take: new build vs rescue?

A new React Native app for iOS and Android typically takes 6 to 10 weeks with us from signed scope to store submission. A rescue is different: the audit takes about a week, the first stabilised release often follows within two to four weeks, and larger fixes are then planned in sprints.

For a new build, the first week goes on screens and data: wireframes agreed, the API mapped, the shared package with your web project set up. Weeks two to six are building in two-week cycles, with an installable build on your phone at the end of each cycle through TestFlight and Play internal testing. The last stretch is testing on real devices, store listing copy, privacy declarations and submission.

Review times vary. Apple and Google both review submissions, and a first submission can bounce back with questions about sign-in, account deletion or data use. Apple's guideline 5.1.1(v) says that if an app supports account creation, it must also offer account deletion within the app, which is a common reason for first-time rejections. We build that flow from the start.

If your Google Play account is a personal one created after 13 November 2023, Google requires a closed test with at least 12 testers opted in for at least 14 days before production release. Organisation accounts are not subject to that rule. We flag this in week one so the test runs in parallel with development rather than delaying launch.

Who owns the code, accounts and keys when React Native developers leave?

You should own everything, and it should be set up that way from day one rather than promised at the end. On our projects the Git repository sits in your GitHub, GitLab or Bitbucket organisation, the app is published through your Apple Developer and Google Play Console accounts, and the Expo project belongs to your Expo organisation with us added as members.

Signing is where ownership gets real. For Android we use Play App Signing, so Google holds the app signing key under your account and the upload key can be reset if lost. For iOS, certificates and provisioning profiles are generated under your Apple team; with EAS Build the credentials are stored in your Expo organisation, not on a developer's laptop.

Handover is written down. At the end of the build you receive a README that explains how to run the project locally, how to cut a release, which environment variables exist and where each secret lives, plus a list of every third-party service with the account owner named. Rescue projects are a reminder of why this matters: nearly every abandoned app we are asked about lacked exactly this document.

Contract terms, including confidentiality and intellectual property wording, are agreed in your written quote and our published terms. If you need your own contract, send it and we will read it before starting.

New Architecture, Hermes and upgrades: technical choices that age well

Build on the current React Native architecture and plan for upgrades from the start. According to the React Native team, starting from version 0.76 the New Architecture is enabled by default in new projects. Apps started before that, which includes most rescue projects, often still run the old bridge and depend on libraries that have not caught up.

Our default stack for a new UK app is TypeScript, Expo with Expo Router, the Hermes JavaScript engine, TanStack Query for server data, a small state store for local UI state, and EAS Build for signed binaries. We add Sentry-style crash reporting only behind consent, and we pick libraries by maintenance activity rather than download count alone.

Upgrades are a budget line, not an emergency. Expo releases new SDK versions several times a year and each tracks a React Native release. We recommend upgrading at least once or twice a year, which keeps each step small. The expensive projects are the ones that skipped three years of upgrades and now face a forced jump because Google Play's target API rules have moved on.

• Choose maintained libraries with New Architecture support listed in their documentation.
• Keep native customisation inside config plugins or local Expo modules, not hand edits to the ios and android folders.
• Pin versions and upgrade on a calendar, testing on the oldest devices your customers use.
• Record the runtime version policy so OTA updates only reach compatible binaries.

App store visibility, your website's SEO and AI search

An app does not replace your website in search; the two should point at each other. Google Search, Google AI Overviews and AI assistants such as ChatGPT and Perplexity mostly read web pages, not app screens. The website is where people discover you, and the app is where returning customers stay.

Practical steps we include on React Native projects: universal links on iOS and Android App Links so a link to a product page opens the app when installed and the web page when not; a proper app landing page on your site with store badges, screenshots and plain-language answers about what the app does; and structured data on that page so search engines understand the relationship between the brand, the site and the app.

On the store side, the listing title, subtitle, screenshots and the first lines of the description do most of the work. We write them from real customer language rather than keyword lists. For deeper work on the website side, our technical SEO audit for UK sites and AI search optimisation pages explain how to get the web half of the picture right.

One more point for React-based sites specifically: if your marketing pages render only in the browser, search engines and AI crawlers may see less than your customers do. Server rendering through Next.js fixes most of that, and it pairs well with an app that shares the same data layer.

Working with React Native developers in India from the UK

The UK business day overlaps our working hours from late morning onwards, so a 10:30 or 11:00 UK call lands in our afternoon, and anything you send by mid-afternoon usually gets a reply the same day. Code you review in the morning has often been updated overnight by UK time, which suits a two-week sprint rhythm well.

Calls happen on Google Meet, Zoom or Teams, whichever you already use. Day-to-day questions go on WhatsApp or a shared Slack channel, and every decision that affects scope is confirmed in writing. We work in English; Hindi is only used inside our own team.

If you are still deciding between a remote team and someone down the road, our page on offshore vs onshore software development sets out both sides without the sales pitch.

Worked example: a hypothetical Bristol brand with a Next.js shop and a stalled app

Here is a made-up scenario to show how React Native developers would handle a typical UK brief. Say a coffee subscription brand in Bristol runs its shop on Next.js. Two years ago an agency started a React Native app for subscribers, got it into TestFlight, then stopped replying. The founder has a zip file, an Apple account in the agency's name, and no idea where the Android key is.

Week one is the audit. We request the Git history and API keys from the agency in writing, check whether the app record can be moved into the brand's own App Store Connect account, and confirm whether the Android build used Play App Signing. The build runs on React Native 0.71 without the New Architecture, targets an Android API level that Google Play would now refuse, and starts an analytics SDK before any consent screen.

The recommendation might be: keep the subscription and account screens, rebuild the three broken screens in current Expo, move validation and product types into a shared package with the Next.js shop, gate analytics behind consent, and ship the first store release within about four weeks. Anything beyond that, like a loyalty feature, is quoted separately after launch.

The result the founder gets is not a promise of downloads or reviews. It is an app that builds on any machine, publishes under their own accounts, shares logic with the website, and comes with a README their next developer can follow. That is what a successful rescue looks like.

Checklist before you hire React Native developers in the UK

Run through this list before you send a brief to anyone. Having the answers ready usually shortens the quote process by several days and makes quotes easier to compare like for like.

• Apple Developer and Google Play Console accounts in your organisation's name (organisation enrolment with Apple needs a D-U-N-S number).
• A list of screens or user journeys, even rough sketches or screenshots of competitors you admire.
• Where your data lives today: Next.js API routes, a headless commerce platform, a CRM, a spreadsheet.
• Which SDKs you want (analytics, crash reporting, chat, maps) and who has signed off consent wording.
• For a rescue: the Git repository or the best copy you have, plus any correspondence with the previous supplier.
• Your release expectations: how often you want updates, and who approves them.
• A budget range and a date that genuinely matters (a trade show, a seasonal launch), not an arbitrary one.

Send what you have on WhatsApp or through the contact page. You will get questions back, then an itemised quote in about two working days.