React Native app development company: the version question to ask before you sign in 2026

Summary. React Native 0.87 shipped on 11 August 2026 and raised the minimum toolchain to Node.js 22, Android Gradle Plugin 9 and Kotlin 2.0, while making the Strict TypeScript API the default. Expo SDK 56, the distribution most agencies actually build on, ships React Native 0.85. Google Play requires new apps and updates to target Android 16 (API level 36) from 31 August 2026, with an extension only to 1 November 2026. Those three facts interact, and the interaction is the single most useful question to put to a prospective React Native app development company: which React Native version will my app be on in six months, core or Expo, and who pays for the gap? Since 0.82 in October 2025 there has been no legacy architecture to fall back on, so the answer is no longer academic.

The framework itself has become boring in the way mature infrastructure should be. React Native 0.83 and 0.86 both shipped with no user-facing breaking changes at all. The risk has moved out of the framework and into the toolchain, the plugin ecosystem, and the distance between the version your partner is comfortable with and the version the app stores require.

What changed between 0.82 and 0.87

The Meta and Expo engineers who published 0.87 state the cost plainly: "This release makes the Strict TypeScript API the default JavaScript API, updates Metro to 0.87, adds experimental support for Swift Package Manager (SwiftPM). It also raises the minimum toolchain requirements: Node.js 22, Android Gradle Plugin 9, and Kotlin 2.0+."

Two of those items are the ones that consume sprints. Strict TypeScript was opt-in from 0.80 in June 2025 and was always described by the React Native team as a one-time breaking change; codebases that skipped it for two years pay for it in one go. AGP 9 is separately awkward on apps carrying older native modules, which is most apps that have been running for more than three years.

Version 0.82 is the release that removed the escape hatch. The team's own framing was direct: it is "the first React Native that runs entirely on the New Architecture", with the remaining legacy code slated for removal to cut install size. If a library you depend on never migrated to Fabric and TurboModules, there is no configuration flag that saves you now. Auditing that dependency list is the first real piece of work on any inherited React Native codebase.

The core-versus-Expo gap, and why it decides your Play deadline

Expo is how most teams ship React Native, and Expo tracks core with a deliberate lag. Expo SDK 56 announces that it "includes React Native 0.85 and React 19.2". Core is on 0.87. That is two minor releases and roughly four months.

The lag is usually a feature. Expo absorbs the upgrade pain, tests the ecosystem, and hands you a version where the popular libraries already work. It becomes a problem in exactly one situation: when a store mandate lands inside the gap.

That situation is live right now. Google Play requires new apps and app updates to target API 36 from 31 August 2026. React Native added Android 16 support in 0.81 back in August 2025, so both 0.85 and 0.87 can meet the deadline. The exposure is different: a team on an older Expo SDK inherits both the Android target bump and the accumulated toolchain jump at the same moment, and those two jobs interfere with each other because AGP and Kotlin sit underneath both.

So the question to ask a prospective partner is specific, and the answer should be a version number and a date, not a reassurance.

• Which React Native version, and which Expo SDK if any, will this app be on at handover?

• What is your standing upgrade cadence, and is it inside the retainer or billed as change requests?

• Which of our dependencies are not yet on the New Architecture, and what replaces them?

• Will we be on the managed Expo workflow or a bare project, and what does that cost if we need custom native code later?

A company that cannot answer the third question has not read your package.json.

What we build with React Native

eCorpIT builds React Native applications for teams that already employ React and TypeScript engineers, because that is the condition under which React Native repays its costs. Typical work: consumer apps sharing business logic with an existing web front end, commerce and D2C applications, field-force tools with offline data synchronization, and rescue work on apps stranded on the legacy architecture.

Rescue work is a growing share of it. An app built in 2022 on the old bridge, with three unmaintained native modules, is not a small upgrade. It is an audit, a dependency replacement plan, and then an upgrade.

Our five-step delivery process

1. Dependency and version audit. We read the package.json, the native module list and the Gradle files, then report which libraries have no New Architecture path, what your current target SDK is, and where you stand against 31 August 2026. It produces a dated position, not an estimate.

1. Version and distribution decision. Core React Native or Expo, managed or bare, written down with the trade-off stated. Where the app needs custom native code on a known roadmap, that argues against the managed workflow and we say so.

1. Build in two-week increments. Working builds distributed through TestFlight and Play internal testing from the first increment, so signing, permissions and store review problems surface early instead of at submission.

1. Store readiness. Target API 36 verified, edge-to-edge behaviour checked on Android 15 and above, privacy manifests and App Store Connect age-rating responses completed before the first submission rather than after a rejection.

1. Cadence maintenance. A standing quarterly upgrade slot aligned to the React Native release train, so a toolchain floor like the AGP 9 requirement in 0.87 consumes a planned sprint.

The stack

React Native on the New Architecture with Fabric and TurboModules, Hermes V1, and TypeScript under the Strict API. Expo with EAS Build where the managed workflow fits. Navigation, state and data-fetching chosen against your existing web codebase so logic is genuinely shared rather than merely similar. Server side: Node.js, Python and .NET on AWS, Azure or Google Cloud. Push through Firebase Cloud Messaging and APNs. CI/CD via GitHub Actions or Azure DevOps with signed builds to both stores.

Why eCorpIT

eCorpIT is eCorp Information Technologies Private Limited, founded in 2021, based at Sector 83, Gurugram. We are assessed at CMMI Level 5, certified to ISO 27001:2022 and MSME registered, and we are partners of AWS, Microsoft, Google and Shopify. Teams are senior-led and multi-disciplinary.

For applications handling personal data we design aligned with DPDP Act 2023 requirements and with whichever framework your auditor applies. We state what we hold and design toward the rest; we do not claim certifications we do not have.

Engagement model and indicative bands

Three models. Fixed scope for a defined first release with a signed specification and a store date. A dedicated team billed monthly per engineer for continuous product work. A maintenance retainer covering the quarterly upgrade slot, sized by the count of native modules rather than by screens, because native modules are what break on an upgrade.

We give an engagement model rather than a rate card, because any React Native quote produced before someone has read your dependency list is a guess dressed as a number. The audit in step one is short and ends in a fixed figure. Current commercial terms are available through /contact-us/.

India-specific considerations

Android's share of new installs in India makes the 31 August discoverability rule sharper here than in most markets. An app that stays below API 35 does not get removed from Google Play; it stops being offered to users arriving on newer devices, and Google Play tells them the app was built for an older version of Android. Existing users notice nothing. New acquisition simply stops, which is why it usually goes unreported internally until a growth review.

Hiring is the other India-specific variable. React and TypeScript engineers are considerably easier to hire in the NCR market than Dart engineers, and that supply difference often outweighs any framework comparison. We have written the hiring side up separately in our React Native versus Flutter hiring decision framework, and the managed-versus-bare question in Expo versus React Native. If you are still choosing an architecture, our hybrid app development company page compares all three cross-platform routes, and the Play deadline itself is covered in the Android target API 36 migration guide. Broader architecture guidance sits in our enterprise mobile app development guide.

FAQ

How eCorpIT can help

We start by reading your dependency list and your Gradle files and telling you exactly which libraries have no path onto the New Architecture and where you stand against the 31 August Play deadline. For new builds we commit to a React Native version and a distribution choice in writing, with the argument against that choice included. Teams are senior-led, and the quarterly upgrade slot is part of the engagement rather than a change request you discover later. Begin with a short audit through /contact-us/.

References

1. React Native release announcements, versions 0.80 to 0.87, Meta and Expo, June 2025 to August 2026

1. React Native architecture overview, Meta

1. React Native releases overview, Meta

1. Target API level requirements for Google Play apps, Play Console Help, Google

1. Migrating to a newer target SDK level, Android Developers

1. Expo SDK 56 changelog, Expo

1. Expo SDK 55 changelog, Expo

1. Upgrade Expo SDK walkthrough, Expo Documentation

1. Expo SDK reference, latest version, Expo Documentation

1. Upcoming Requirements: SDK minimum requirements, Apple Developer

1. React Native packages directory, React Native community

1. React Native contributing and release process, Meta

Last updated: 15 August 2026.