Loading · Expo
Stack Innovations Start a project
Stack Innovations/ Services/ Mobile Apps/ Expo
05 / 05 · Mobile Apps
000Compiling Expo

Expo

React Native, minus the ceremony — from first commit to TestFlight in days.

Start a build →
First TestFlight build3days
OTA rollout15min
Cold start400ms
EAS build success98%
The argument

Expo is just React Native, with the ceremony removed.

Each config plugin · a native feature, no Xcode required. Each update · pushed without a store review. Each build · reproducible in the cloud.
02 — Ecosystem

Expo,
and the right neighbours.

Navigation/01
Expo Router

File-based navigation with typed routes, deep linking, and universal web support out of the box. Our default for app structure.

File routesDeep linksTypedUniversal
Build/02
EAS Build

Cloud-native builds for iOS and Android, no local toolchain required.

CloudCI
Release/03
EAS Update

Ship JS/asset fixes over the air, no store review in the loop.

OTAChannels
Distribution/04
EAS Submit

Automated App Store and Play Store submission from CI.

App StorePlay Store
Native/05
Expo Modules API

Author native Swift/Kotlin modules with a modern, typed API.

SwiftKotlin
Tooling/06
Dev Client

Custom dev builds with native code, same fast-refresh workflow.

Fast refreshNative
Config/07
Config Plugins

Native project config without ejecting or touching Xcode.

app.config.tsNo eject
Messaging/08
Expo Push Notifications

Unified push across iOS and Android, one API.

APNsFCM
Observability/09
Sentry + Expo Insights

Crash reporting, release health, and build/update analytics.

CrashesInsights
Language/10
TypeScript

Type safety end to end — navigation params, API contracts, native module bindings. Strict mode, no exceptions.

StrictTyped routesShared types
Motion/11
Reanimated + Gesture Handler

Native-thread animation and gestures — 60fps, no bridge hops.

60fpsGestures
03 — What we build

Three shapes,
one toolkit.

01 — MVPs
MVPs &
startups.

The fastest path from idea to App Store and Play Store. One codebase, native feel, no platform team required.

  • →Expo Router · file-based navUniversal
  • →Auth · onboarding · paywallRevenueCat
  • →EAS Build · CI from day oneCloud
  • →Store submission · both platformsEAS Submit
app.expo.dev/build
02 — Internal tools
Internal
tools.

Fast-iterating field and ops apps that update instantly via EAS Update — no waiting on store review to ship a fix.

  • →Offline-first sync · queued writesSQLite
  • →OTA hotfixes · minutes, not daysEAS Update
  • →Device auth · badge / PINSecureStore
  • →Channel rollout · staged, revertibleChannels
channel status build updated
03 — Prototypes
Prototypes
& pilots.

Validate the concept on real devices before investing in a bare-workflow rebuild. Managed workflow, minimal ceremony.

  • →Dev Client · install in minutesQR build
  • →Design partner review loopWeekly
  • →Usage telemetry · from day oneInsights
  • →Eject path · scoped, if ever neededOptional
d1 d6 d12
/ Phase 01 · Discover

Listen first.

Stakeholder interviews, support tickets, session replays. We map the architecture by mapping the work.

Discovery docTech auditRisk map
SCOPE USERS DATA TEAM RISK OUTCOME
app/ app/(tabs)/index.tsx app/(tabs)/settings.tsx app/modal.tsx app/_layout.tsx app.config.ts eas.json
--space-1: 4px --radius-md: 8px --space-2: 8px --shadow-1: 0 1 2 ... --space-3: 16px --motion-fast: 180ms
// app/(tabs)/index.tsx export default function Home() { const router = useRouter(); return ( <View style={styles.root}> <Link href="/modal"> Open modal </Link> </View> ); } → preview build via Dev Client → pushed on every commit → tested · device farm + a11y
w1 w6 w12 +42% activation
01
01
05
05 — Architecture

A request,
end to end.

// live · EAS Update publish → channel:production
Request Static
Client Expo Router · RN Native UI Update channel EAS Update ~15min rollout API layer fetch · GraphQL Auth · tokens Backend Postgres · services Managed infra Observability Sentry · EAS Insights Crashes · Releases
Client → Update channel~15min
Update → API~40ms
API → Backend~18ms
Cold start400ms
06 — Numbers

Standards,
not anecdotes.

What every Expo build leaves with — the floor, not the ceiling.

First TestFlight build 0 days · from repo access
#StandardFloorMethod
01 First TestFlight buildfrom repo access 0d EAS Build
02 EAS build success ratetrailing 90 days 0% EAS
03 OTA rollout timepublish → 100% adoption 0min EAS Update
04 Cold startp50 · mid-tier device 0ms RUM
05 Test coverageunit + integration 0% Jest
06 Critical a11y issuesaudited · WCAG 2.2 AA 0 Manual audit
08 — Engagement

Three ways
to start.

01 / Sprint2 weeks
Diagnostic
sprint.
flatfixed scope
  • →Tech audit · current RN/Expo stack
  • →Architecture proposal
  • →Risk & native-requirement map
  • →Live walkthrough · written report
Book a sprint →
02 / MVP— Most chosen
MVP ship.
retainer4–8 weeks
  • →One app, iOS + Android, end to end
  • →Auth · Push · Telemetry wired
  • →EAS Build/Update/Submit pipeline
  • →CI/CD · monitoring · runbook
  • →Two rounds of post-launch iteration
Start an MVP →
03 / Build12+ weeks
Ground-up
platform.
retainerquarterly
  • →Multi-surface mobile platform
  • →Native modules + config plugins
  • →Embedded design partner
  • →Hand-off plan, onboarded team
Plan a build →
09 — Questions

Things people
actually ask.

Bare React Native means you own the native iOS/Android projects directly — every native dependency is a manual link, every OS upgrade is your migration. Expo's managed workflow wraps that in tooling: config plugins handle native config, EAS handles builds and store submission, and EAS Update ships JS changes without a rebuild. You still get real native code when you need it — Expo just removes the parts of native tooling that don't need to be hand-managed. If your app is heavily native-module-driven from day one, our separate React Native track covers the bare-workflow case in depth.
Yes. The Expo Modules API lets you write native Swift/Kotlin modules and consume them from JS with a typed interface, and most third-party native SDKs (Bluetooth, payments, maps) ship as config plugins now. You build with a custom Dev Client instead of Expo Go once native code enters the picture — that's still the managed workflow, just with your own native binary.
EAS Update ships JS, assets, and config changes directly to installed apps — no store review needed, because the native binary doesn't change. Anything that touches native code (new permissions, native modules, app icon) still requires a full build and a store submission. Both platforms allow this as long as you're not using OTA to change the app's fundamental purpose — which is a policy line we plan around from day one, not something we retrofit later.
Rarely, and usually not fully. Config plugins and the Modules API cover the large majority of native requirements we see. We'd consider a bare-workflow move if you need a native SDK with no config plugin and no reasonable path to writing one, or if your team wants direct control of the Xcode/Gradle projects for reasons outside app functionality. Even then, "eject" is largely a legacy term — modern Expo apps can adopt native folders selectively via prebuild rather than losing the managed tooling entirely.
SQLite (via expo-sqlite) or WatermelonDB for local-first data, queued writes with conflict resolution on reconnect, and EAS Update channels so a sync-layer fix ships in minutes rather than a store cycle. The pattern depends on whether the app is occasionally-offline (cache + retry) or truly offline-first (local database as source of truth) — we scope that in discovery, not after the fact.
You do. The repo, the EAS project, the Apple/Google developer accounts — all provisioned under your organization from day one, not ours. All work is delivered under a work-for-hire clause. We keep no embedded SDKs or licensing strings attached, and offboarding is a transfer of access, not a migration project.
10 — Start

Let's build
something worth shipping.

Two-week diagnostic, four-week MVP, twelve-week ground-up. Bring the brief — we'll send a plan, not a pitch deck.

Start a project →
Tweaks
Accent
Motion
Lenis
Sound