Expo SDK 52+ Features for Faster MVP Launches

Key facts, with sources

• 71% of State of React Native 2024 respondents reported using Expo's EAS Build, ahead of manual builds with Xcode (59.7%) and Android Studio (54.5%). (InfoQ)
• Expo SDK 52, released November 12, 2024, enabled the New Architecture by default for all new projects, and Expo Go for SDK 52 and higher supports only the New Architecture. (Expo Changelog)
• The official React Native documentation now recommends starting new apps with a framework, naming Expo, rather than initializing a bare project. (React Native documentation)
• EAS build caching can speed up subsequent Android and iOS builds by up to 30% and is available to all users at no additional cost as of the SDK 57 cycle. (Expo Changelog)
• Doctolib runs Expo tooling without EAS to scale developer experience on a healthcare app serving 90 million users, showing Expo's open-source tools work independently of its paid cloud services. (Doctolib Engineering (Medium))

New Architecture by default — and why MVPs should keep it on

SDK 52 flipped the New Architecture on by default for new projects, riding on React Native 0.76. For founders the relevant question isn't the interop internals — it's risk. My experience upgrading client apps: well-maintained libraries had already migrated by the time SDK 52 landed, and the libraries that break under the New Architecture are usually abandoned ones you shouldn't ship an MVP on anyway.

Starting a new app on the old architecture in 2026 means signing up for a forced migration later, mid-growth, when you least want it. Greenfield projects get the migration for free by never having the legacy setup. In code audits I now flag newArchEnabled: false in a new project as a decision that needs justifying, not the other way around.

expo-video: the end of rolling your own player

Video used to be a reliable time sink in React Native MVPs: the community players each had platform-specific quirks, and expo-av's video support was long deprecated in spirit before it was in writing. SDK 52 shipped expo-video as a stable, first-party player with a modern hook-based API, built on current native player primitives.

The API shape matters for velocity: you create a player with a hook, configure it in a callback, and render a view — no ref gymnastics, no imperative setup racing against mount. For the common MVP cases (onboarding clips, feed previews, muted autoplay hero videos) it's now a ten-minute task.

import { useVideoPlayer, VideoView } from 'expo-video';

export function OnboardingClip({ source }: { source: string }) {
  const player = useVideoPlayer(source, (p) => {
    p.loop = true;
    p.muted = true;
    p.play();
  });

  return (
    <VideoView
      player={player}
      style={{ width: '100%', aspectRatio: 16 / 9 }}
      contentFit="cover"
    />
  );
}

The camera rewrite and shrinking your native dependency list

The rewritten expo-camera reached stability in the same era, with a cleaner permissions story and more predictable behavior across devices. Between expo-video, expo-camera, expo-image, and the file-system modernization, the standard MVP feature set — capture a photo, show media, cache images aggressively, store files — is now covered by first-party modules maintained on the same release train as the SDK itself.

This is the real MVP acceleration: every third-party native module you delete removes a config plugin, a potential New Architecture incompatibility, and a maintainer you're betting your upgrade path on. When I scope an MVP now, I default to the Expo module for any capability where one exists and only reach for third-party native code when there's a concrete gap.

DOM components for the weird ten percent

SDK 52 also introduced DOM components: mark a React component with a use dom directive and it renders inside a web view while still receiving props from your native app. This sounds like a gimmick until you hit the classic MVP wall — a rich text editor, a chart library, a markdown preview — where the web ecosystem is a decade ahead of native equivalents.

I treat DOM components as a scoped escape hatch, not an architecture. They're slower than native views and shouldn't host your core interaction loop. But for one screen where the alternative is a week evaluating half-maintained native libraries, embedding a mature web library and moving on is the correct MVP trade. Ship it, note it as intentional debt, revisit if the screen becomes hot.

Upgrade posture: staying current is the cheap strategy

Expo ships SDK releases on a regular cadence, and each release typically supports a straightforward upgrade from the previous one. The teams I see suffer are the ones that skip several versions and then face a compound migration — SDK changes, React Native changes, and library updates all tangled together.

For an MVP my rule is simple: start on the newest stable SDK, and take each upgrade within a sprint or two of release while the diff is small and the community has flushed out the edge cases. A single-version Expo upgrade is usually a half-day task; a three-version jump can eat a week. Staying current isn't polish — it's the lowest-cost way to keep access to exactly the kind of velocity features SDK 52 delivered.

When to hire senior help

Senior help pays off when deciding between managed and prebuild workflows, setting up EAS-based CI/CD and OTA update channels, or untangling a project that was ejected prematurely. An experienced Expo engineer can usually configure build, submit, and update pipelines in days, a task that costs first-time teams weeks of trial and error. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Expo Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Ejecting to the bare workflow at the first native requirement instead of using config plugins and development builds, permanently giving up managed upgrades
• ✕Testing only in Expo Go and misconfiguring runtime versions for expo-updates, so an OTA update ships JavaScript that crashes against mismatched native binaries
• ✕Burning EAS build minutes on every commit in CI without caching or local builds, turning a convenience service into a surprise line item
• ✕Skipping several SDK upgrades in a row, then being forced into a large breaking migration when app store target API level deadlines arrive

Frequently asked questions

Sources

• InfoQ
• Expo Changelog
• React Native documentation
• Expo Changelog
• Doctolib Engineering (Medium)