Chapter 1: Why Expo and what you can build

Expo is React Native’s officially recommended framework. That sentence would have surprised people five years ago - Expo was the “easy mode” sandbox you outgrew on the way to a real project. It is no longer that thing. In 2026, Expo is the production path: a managed build service, a curated set of native libraries, over-the-air updates, file-based routing, and a native module API that lets you write Swift and Kotlin without leaving your JavaScript project.

This handbook is the complete pipeline from npx create-expo-app to an app live on both stores with widgets, in-app purchases, push notifications, and a CI/CD pipeline that builds while you sleep. If you have shipped a React app and want your next product on the App Store, you are in the right place.

Learning objectives

After this chapter you will be able to:

• Explain where Expo fits in the React Native ecosystem and why it became the recommended starting point
• Distinguish between Expo Go, development builds, and EAS Build - and when to use each
• Assess whether Expo is the right choice for a given product idea
• Understand what SDK 57 ships with and what new problems it solves
• Scan the full handbook chapter map and know what each section covers

Why this matters

Most Expo content stops at the demo. You build a thing in Expo Go, it works on your phone, and the tutorial ends. You are left with a folder of code and no path to TestFlight, to payments, to widgets on the home screen, to an update you can ship without a two-day app review.

The gap between “my app runs on my device” and “my app takes payments and updates itself” is real, it is documented nowhere end to end, and it costs builders weeks of scattered documentation and Stack Overflow searches to close. This handbook closes it in one place.

What Expo is (and what it stopped being)

Expo is an open-source framework built on React Native. It provides three things that raw React Native does not:

1. A managed build service (EAS). You run eas build, Expo compiles your app on cloud infrastructure - Linux VMs for Android, Mac mini hosts for iOS - and returns a store-ready binary. No local Xcode or Android Studio required for release builds.

2. A curated set of native libraries. Camera, notifications, haptics, secure storage, maps, audio, video, and two dozen more. All tested together, versioned together as an SDK release, and guaranteed compatible. When you use Expo’s libraries, you skip the dependency hell that raw React Native projects accumulate.

3. A native module system (Expo Modules API). When you need custom native code, you write it in Swift and Kotlin using Expo’s DSL. No Objective-C, no Java, no bridging headers. The Modules API uses JSI - JavaScript Interface - the same high-performance C++ layer that React Native’s New Architecture uses.

The mental model shift: Expo is not a starter kit you graduate from. It is the framework you build on, with optional escape hatches when you need them.

The framework React Native picked

In late 2024, the React Native documentation began directing newcomers to Expo. The reactnative.dev getting-started page now says: start with Expo. This was not a corporate acquisition - Expo and the React Native core team are separate organizations. It was a recognition that the managed workflow solves real problems that most developers hit within weeks of starting a bare React Native project.

What changed? Three things:

• EAS Build replaced the need for local Xcode. Before EAS, Expo apps could only be published through Expo’s legacy build service, which was slow and limited. EAS gives you cloud builds on real macOS and Linux infrastructure with configurable profiles.

• Development builds replaced Expo Go as the standard. Expo Go is a sandbox app with a fixed set of native modules. Development builds are your app binary with your custom native code included, connecting to your local Metro server. You get the fast refresh cycle of Expo Go with the full native surface of a custom build.

• Config plugins made native configuration programmable. Instead of editing Xcode project files and Android manifests by hand, you write a JavaScript function that mutates them. The generated files stay out of version control. The plugin is the source of truth.

As of SDK 57 (June 2026), Expo ships with React Native 0.86, React 19.2.3, Node.js 22.13 minimum, iOS 16.4+ target, and Android 7+ target. The release cadence is roughly three SDKs per year, tracking React Native’s own release schedule.

What you can ship

Expo powers real, revenue-generating products. The fitness app you use to track workouts. The content app where you read articles offline. The commerce app where you buy concert tickets. The productivity tool with home screen widgets and Live Activities.

Some of these are built by solo developers. Some by small teams. All of them share one codebase across iOS and Android.

The question is not “can Expo handle a real app.” The question is whether your app’s specific needs match what Expo makes straightforward vs. what it makes harder. Here is the honest assessment:

Expo works well when your app:

• Has standard UI (navigation, forms, lists, media playback)
• Uses platform features that Expo wraps (camera, location, haptics, notifications)
• Needs in-app purchases (RevenueCat + StoreKit 2)
• Wants home screen widgets and Live Activities (new in SDK 57 via expo-widgets)
• Ships over-the-air updates without app review
• Has a server-side component that handles business logic

Expo is not the right choice when your app:

• Requires raw Bluetooth or BLE peripheral mode (the expo-bluetooth package is emerging but limited)
• Needs advanced AR features tied to ARKit-specific APIs beyond basic 3D rendering
• Demands heavy native UI customization that fights the managed workflow at every turn
• Must integrate deeply with platform-specific frameworks that have no Expo module or community package

For 80 percent of the apps solo developers and small teams build, Expo is the right starting point. For the 20 percent that need more, you can eject to bare React Native at any point - but most builders who think they are in the 20 percent discover they are actually in the 80 percent once they understand what Expo can do.

SDK 57: what is new

SDK 57 (released June 30, 2026) is a small, focused release - primarily the React Native 0.86 bump, which itself was a “no breaking changes” release. But it builds on the larger SDK 55 and 56 releases that introduced features now central to the production pipeline:

The headline: you can now build iOS widgets and Live Activities without writing Swift. You write JSX with expo/ui’s SwiftUI components, and Expo’s native layer compiles them to real SwiftUI views. The same pattern - write once, render natively - applies to Android via Jetpack Compose.

Expo Go vs. development builds: the distinction that matters

New Expo users typically start with Expo Go: download the app from the store, scan the QR code from your terminal, and your project appears on your phone. This is the right first step. It works for learning, prototyping, and testing Expo’s built-in modules.

Expo Go ships with a fixed set of native libraries - camera, maps, notifications, SecureStore, and others. Any third-party library with native code that is not in Expo Go’s bundle - RevenueCat, Firebase, custom widgets, Bluetooth, native payment SDKs - will not work.

Development builds are the answer. You create a custom build of your app that includes all your native dependencies. The expo-dev-client library adds a launcher UI that connects to your local Metro server, giving you the same fast-refresh cycle as Expo Go with the full native surface of a custom build.

The workflow shift:

Expo Go:           npx expo start → scan QR → app runs in Expo Go
Development build: npx expo install expo-dev-client → eas build --profile development → install on device → npx expo start → app connects

The extra step (building the dev client) costs about 15 minutes the first time and pays for itself the first time you need a library Expo Go does not include. Every chapter after Chapter 2 assumes you are using a development build.

The handbook stack

This handbook targets one stack and explains it deeply:

You do not need to know all of these tools before starting. Each is introduced in its relevant chapter with setup instructions and a worked example. By the end, you will have configured every one of them in your own project.

The chapter map

Thirteen chapters, roughly 30 to 45 minutes per chapter:

Chapters 1 and 2 are your first session. Set up the environment, verify everything works, and build the mental model for what follows. The rest of the handbook is sequential - each chapter builds on the one before it.

Key takeaways

• Expo is React Native’s recommended framework. It is a production path, not a starter kit you outgrow.
• Development builds replace Expo Go for production development. They include your custom native code and give you the same fast-refresh cycle.
• SDK 57 ships with React Native 0.86, React 19.2.3, and the now-mature expo-widgets and expo/ui packages.
• Most apps that solo developers and small teams build fit comfortably inside Expo’s managed workflow. The 20 percent that do not can eject to bare React Native at any point.
• This handbook covers the full pipeline: setup, architecture, navigation, styling, data, native modules, widgets, payments, push notifications, build/signing, store submission, and production CI/CD.

Common pitfalls

• Treating Expo Go as the production development environment. It works for the first hour of learning. The moment you add a library with native code, switch to a development build. Delaying the switch means debugging environment issues when you should be building features.
• Overestimating how “native” your needs are. Builders coming from native iOS/Android backgrounds often assume Expo cannot handle their app. Test the assumption: try building a prototype with the specific native feature you think you need. You might find a config plugin or community package already handles it.
• Underestimating the Apple Developer Program setup. The technical part (Xcode, simulators, certificates) takes an afternoon. The bureaucratic part (Apple Developer enrollment, agreement signing, banking/tax forms) can take days. Start it early.

Further reading

• Expo documentation: https://docs.expo.dev
• React Native getting started (recommends Expo): https://reactnative.dev/docs/getting-started
• SDK 57 changelog: https://expo.dev/changelog/sdk-57
• Development builds guide: https://docs.expo.dev/develop/development-builds/introduction/
• Expo Go to dev build migration: https://docs.expo.dev/develop/development-builds/expo-go-to-dev-build/

Checkpoint exercise

Open https://expo.dev and browse the documentation. Find the SDK 57 reference page. Note three packages you did not know Expo offered. Check their API surfaces - are they relevant to an app you want to build? Write down one product idea that could ship using Expo, and note which native feature (camera, payments, notifications, widgets) would be the hardest part.