React Native & Expo
React Native and Expo development, one codebase for both stores
iOS and Android apps from one React Native and Expo codebase in TypeScript. Builds run on EAS, fixes reach users as over-the-air updates instead of waiting on store review, and native Swift or Kotlin modules are written with the Expo Modules API when a feature needs them. Older React Native apps are upgraded in steps.
- Typical timeline
- 3–6 monthsTo a first store release after discovery, depending on scope
- How it’s quoted
- IndividuallyAfter a 30-minute call
- Who edits it
- Your teamThrough an admin or headless CMS the app reads from
- Stack
- Expo and React NativeTypeScript, EAS Build and EAS Update
In your name Accounts and repositories, from day one Yours The code and documentation, under the signed agreement
On this page
Is it the right call?
When it’s the right call
- You want iOS and Android from one team and one codebase
- Your web product already runs on React or TypeScript
- Bug fixes need to reach users in hours, not after store review
- An existing React Native app is stuck on old versions and hard to build
When it isn’t
- The app depends on demanding graphics or close, platform-specific hardware access We’d suggest: A fully native build in Swift and Kotlin, which we also do
- Most users will visit once and never install We’d suggest: A fast, installable web app
- Your organization builds everything else in C# and .NET We’d suggest: A cross-platform app in .NET MAUI, which we also build
Sound like you? The first step is a 30-minute scoping call with the engineer who would lead the work.Request a scoping call
The smallest way to start
- Fixed scope, usually 2–3 weeks
Discovery sprint
Research into your users, systems and constraints, the architecture decisions written down, and a written plan and quote, yours to take to any team.
Start with a discovery sprint What the written plan covers
Standard equipment
What we usually hand over on a project like this. Your proposal lists exactly what’s included.
- Expo
- React Native
- TypeScript
- EAS
- Swift
- Kotlin
Expo app codebase
TypeScript, typed navigation and shared components, structured for both platforms.
EAS build and update pipeline
Automated builds, preview channels for testers and over-the-air release channels.
Native modules
Swift and Kotlin modules, written with the Expo Modules API, where a feature needs them.
Store releases
App Store and Google Play listings, review submissions and staged rollouts.
Upgrade and handover guide
How to move to the next Expo SDK, release a fix and rotate credentials.
Why Expo
Expo gives a React Native app a maintained toolchain: managed builds, over-the-air updates and a module system for native code without ejecting. You get one codebase, one team and one release process for both stores, and you keep the option to go native for any single feature.
It is one of several routes we build. Fully native apps in Swift and Kotlin, and cross-platform apps in Ionic or .NET MAUI, are equal options. React Native and Expo are usually the right one when your team already works in React or TypeScript, or when fixes need to reach users without waiting on review. How we choose →
What we take care of
Offline storage and sync, push notifications, deep links, in-app purchases, sign in with Apple and Google, and accessibility with VoiceOver and TalkBack. The back end the app depends on, from custom APIs and authentication to managed services such as Firebase, is built to the same standard.
Rescuing older React Native apps
Projects often start with an app that no longer builds cleanly. We audit it, upgrade the React Native and Expo SDK versions in steps, move it to the New Architecture, and replace abandoned libraries. Each step ships as a working release, so users see as little disruption as possible.
Questions about React Native & Expo
Is Expo ready for a production app?
Yes, Expo is ready for production apps: it is the maintained toolchain for React Native, and production apps in both stores are built on it. It no longer limits which native code you can use, so when a feature needs Swift or Kotlin, we write a module without leaving Expo.
When is a fully native app a better choice than Expo?
Fully native is the better choice when the app’s value depends on the platform itself, such as demanding graphics, complex background work or close hardware access, or when your team already maintains Swift and Kotlin. For most product apps that should behave the same on both stores, one Expo codebase is simpler to build and run, with native modules where a feature needs them.
What can over-the-air updates change without store review?
Over-the-air updates can change the app’s JavaScript and assets, such as screens, logic and copy, so a fix can reach users without waiting for store review. Changes to native code, permissions or the Expo SDK version still need a new store build and review. We set up release channels so updates are tested before they reach everyone, and kept within Apple’s and Google’s rules.
Every build, any stack
One standard.
Performance
A performance budget is set before launch and enforced on every change.
Accessibility
Built to WCAG 2.2 AA and tested against it, with automated checks and manual keyboard and screen-reader passes on client builds.
Security
Least-privilege access, secrets kept out of code, dependencies monitored and security headers configured.
Handover
Accounts and repositories in your name from day one. The code and documentation are yours under the signed agreement, written so another team could take over.
Start a project
Tell us what the app has to do.
Who uses it, on which phones, and what it talks to are enough to start. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call