Somewhere between SDK 50 (January 2024) and SDK 52 (November 2024), "using Expo" quietly stopped meaning "using Expo Go with a limited set of native modules" and started meaning "using the same toolchain as a bare React Native project, plus a hosted build and update pipeline." Three things drove that: Expo Router matured into a real file-based routing system, development builds became the expected way to run a project locally, and EAS stopped being optional infrastructure and became the default one.
#Expo Router v3: typed routes and API Routes
Router v3 shipped alongside SDK 50 with two additions that matter more than the version bump suggests. Typed Routes gives you TypeScript-checked route names and params instead of stringly-typed navigation. API Routes, still experimental at this point, let you define server endpoints as files in the same app/ directory as your screens.
import { useLocalSearchParams } from "expo-router";
export default function TripDetail() {
const { id } = useLocalSearchParams<{ id: string }>();
return null;
}
export async function GET(request: Request) {
return Response.json({ status: "ok" });
}
That second snippet is a +api.ts file — Router's convention for server routes that live alongside your app code instead of in a separate backend project. Reach for API Routes when you need a thin server endpoint (webhooks, auth callbacks) and don't want to stand up a separate service for it; it's still explicitly experimental, so don't put your primary backend there yet.
#Expo Router v4: React Navigation 7 underneath, headless primitives on top
SDK 52 brings Router v4, rebuilt on React Navigation 7. The more practical addition is expo-router/ui, which exposes headless, unstyled primitives — a <Tabs /> component with Radix-like composition instead of a fixed, pre-styled tab bar. If you've been fighting the default tab bar's styling limits, this is the escape hatch.
#Development builds become the default workflow
Expo Go was never going to work for apps with custom native modules, and by SDK 50-52 the ecosystem has fully accepted that development builds are the answer, not a workaround. expo-dev-client gives you Expo Go's fast-refresh developer experience in a build that includes your actual native dependencies.
npx expo install expo-dev-client
npx expo run:ios
Once you're on a dev build, Expo Go stops being relevant to your day-to-day — you're running the same native binary shape you'll ship, just with the dev menu and fast refresh attached.
#EAS Build and EAS Update: the pipeline you don't self-host
EAS Build compiles your native binaries in the cloud, with no local Xcode or Android SDK setup required for CI. EAS Update pushes JS-and-asset-only changes over the air without an App Store review cycle.
eas build --platform ios --profile production
eas update --branch production
The combination — build in the cloud, patch in the air between store releases — is what makes a small team able to run a release process that used to need dedicated mobile infra.
#Server Components: an early preview, not a production feature
SDK 52 includes an early preview of React Server Components and Server Actions, shown first at React Conf 2024. This is explicitly aimed at library authors adopting RSC support ahead of time, not at shipping product code — treat any RSC usage in Expo today as a bet on where things are headed, not a stable API.
#What to adopt first
- Move to a development build now if you're still fighting Expo Go's native module limits — it's the supported path, not a fallback.
- Adopt Typed Routes immediately on any Router-based project; it's low-cost and catches a real class of navigation bugs at compile time.
- Put your build and OTA update process on EAS Build and EAS Update before you build your own CI pipeline for it — you'll spend less time maintaining infrastructure than replicating what's already hosted.
- Try API Routes for small, app-adjacent server needs, but keep your real backend elsewhere until the feature graduates out of experimental.
- Leave Server Components alone in product code for now — it's a preview aimed at library authors, and the ergonomics are still being worked out upstream in React itself.