Expo SDK 55 Migration Guide: What CTOs Need to Know in 2026

Expo SDK 55 shipped on May 6, 2026, and the headline is blunt: the legacy (Bridge) architecture is no longer supported. If your app still relies on the old bridge for native module communication, it will not build on SDK 55. Full stop. There is no compatibility shim, no opt-out flag, no "we will get to it next quarter" escape hatch.

This is not a surprise. The Expo team signaled this deprecation three SDK cycles ago, and SDK 54 printed console warnings every time a bridge-based module loaded. But warnings are easy to ignore, and plenty of teams did exactly that. According to Expo's own telemetry, 83% of active EAS Build projects already run on the New Architecture. The remaining 17% face a mandatory migration before they can adopt SDK 55, and that migration carries real engineering cost if your dependency tree is not ready.

SDK 55 bundles React Native 0.83 and React 19.2, bringing concurrent rendering improvements, better Suspense support, and tighter integration between React's reconciler and the native rendering pipeline. Combined with the New Architecture mandate, this is the largest single-SDK jump in complexity since SDK 48 to 49.

If you are a CTO evaluating whether to prioritize this migration, the short answer is yes, do it now. SDK 53 enters maintenance mode in August 2026, and SDK 54 follows in November. Falling two major versions behind Expo is where teams accumulate the kind of tech debt that requires dedicated "migration sprints" instead of incremental upgrades. The pattern is always the same: the longer you wait, the more painful it gets.

Before diving into migration mechanics, it helps to understand what you are migrating toward. SDK 55 is not just a "drop legacy support" release. It ships meaningful improvements that your engineering team will appreciate once the upgrade dust settles.

React Native 0.83 and React 19.2

React Native 0.83 completes the integration work that started in 0.79. Fabric and TurboModules are now the only code paths, which means smaller binary sizes (the bridge runtime is no longer bundled), faster startup times, and more predictable rendering behavior. React 19.2 brings better error boundaries and the stable Actions API. For mobile apps, the most impactful change is improved Suspense hydration, which makes skeleton-to-content transitions noticeably smoother.

Hermes v1: Real Performance Gains

Hermes v1 is a significant engine upgrade. The bytecode compiler produces 12-18% smaller bundles compared to Hermes 0.12 (the version in SDK 54). Startup time improves by roughly 15% on mid-range Android devices, which is where performance matters most. The garbage collector has been rewritten to use generational collection by default, reducing GC pauses from an average of 8ms to under 3ms in our benchmarks. If your app suffers from jank during list scrolling or complex animations, Hermes v1 alone might fix it.

New Object-Oriented Native APIs

Expo is replacing its older functional APIs for Contacts, Calendar, and MediaLibrary with object-oriented equivalents. Instead of calling Contacts.getContactsAsync() and receiving a plain object, you now work with Contact instances that have methods like contact.update() and contact.delete(). The same pattern applies to calendar events and media assets. This is a breaking API change, but the migration is mostly mechanical. The new APIs also support lazy loading of related data (a contact's phone numbers load only when you access them), reducing memory usage for apps that work with large datasets.

RenderNode Blur API

The new RenderNode-level blur API lets you apply Gaussian blur to any view without wrapping it in a special component. This replaces @react-native-community/blur for most use cases. Set blurRadius as a style property on any View, and the blur is applied at the render pipeline level with hardware acceleration. We measured consistent 60fps blur animations on iPhone 12 and Pixel 7, even with blur radii up to 40px.

EAS Build Caching: 30% Faster Builds

EAS Build now caches CocoaPods, Gradle dependencies, and Hermes bytecode between builds. For a typical mid-size project (200+ dependencies), this cuts build time by roughly 30%. Our test project dropped from 14 minutes to 9.5 minutes on the EAS Build standard tier. The caching is automatic for new projects, but existing projects need to opt in by adding "cache": true to their build profile in eas.json. There is no reason not to enable this immediately.

The single most important step before starting your migration is running npx expo-doctor@latest. This tool scans your project's dependency tree and flags every package that is incompatible with SDK 55 and the New Architecture. It checks for native modules still using the Bridge API, deprecated Expo packages, and version mismatches between peer dependencies.

Run it now, even if you are not planning to migrate this week. The report gives you a clear picture of how much work is ahead. Here is what the output categories mean:

• Compatible: The package works with SDK 55 and the New Architecture. No action needed.
• Update Available: A newer version of the package adds New Architecture support. Update the package, test your app, and move on.
• Incompatible (Alternative Available): The package does not support the New Architecture, but a drop-in replacement exists. Expo-doctor suggests the replacement.
• Incompatible (No Alternative): This is the painful one. The package is abandoned or the maintainer has not added New Architecture support. You need to fork it, rewrite the native bridge code as a TurboModule, or find a completely different solution.

In our experience across dozens of migration projects, roughly 90% of dependencies fall into the first two categories. Another 7% have straightforward alternatives. The remaining 3% require actual engineering work: writing TurboModule specs, updating Objective-C or Kotlin native code, and testing on both platforms. That 3% is where the migration timeline gets unpredictable, so identify those packages early.

A common culprit is react-native-maps for teams still on versions below 2.0. The 2.x release added full Fabric support, so updating is straightforward. Another frequent blocker is any in-house native module your team wrote against the old Bridge API. These require a manual rewrite to the TurboModule spec, which typically takes 2-4 days per module depending on complexity.

If your project is in the 17% that has not migrated to the New Architecture, here is the playbook we use with our clients. This assumes you are currently on SDK 53 or 54. If you are further behind, you will need to do incremental SDK upgrades first. Jumping more than two major SDK versions at once is asking for trouble.

Step 1: Create a Migration Branch and Upgrade the SDK

Branch from your current main. Run npx expo install expo@^55.0.0 and let Expo's dependency resolver update the core packages. This will update react, react-native, and all @expo/* packages to compatible versions. Commit this change before touching anything else. You want a clean diff that shows only the version bumps.

Step 2: Enable the New Architecture

In your app.json (or app.config.js), set "newArchEnabled": true under the "expo" key. In SDK 55 this flag defaults to true and ignoring it will also default to true, but being explicit helps your team understand what changed. If you were previously setting this to false to opt out, remove that override.

Step 3: Fix expo-doctor Warnings

Run npx expo-doctor@latest again on your migration branch. Update every package it flags. For packages in the "Incompatible (No Alternative)" category, you have three options: fork and patch, replace with a different library, or remove the feature temporarily and ship without it. We recommend the third option when possible. Ship the SDK 55 upgrade without the problematic feature, then add it back once you have a compatible replacement. Trying to do both simultaneously doubles your QA surface area.

Step 4: Migrate Custom Native Modules

If your project has custom native modules written against the old Bridge API, you need to rewrite them as TurboModules. The React Native New Architecture guide covers the TurboModule spec in detail. The short version: create a TypeScript spec file using the TurboModuleRegistry API, then update your native Objective-C/Swift or Kotlin code to implement the generated interface. Codegen handles the C++ glue layer.

Step 5: Update UI Components to Fabric

Custom native UI components need to migrate from the old requireNativeComponent API to Fabric's codegenNativeComponent. This is more involved than TurboModule migration because you are dealing with view props, event handlers, and the measure/layout cycle. Budget 3-5 days per complex custom view component.

Step 6: Test on Physical Devices

The New Architecture changes how native views are measured, laid out, and rendered. Subtle differences can cause pixel-level layout shifts, especially with absolutely positioned elements and custom shadows. Run your full regression suite on physical iOS and Android devices. Simulators miss performance-related issues like GC pauses and frame drops. Pay special attention to: FlatList/FlashList scrolling, modal presentations, keyboard avoidance, and any screen that uses LayoutAnimation.

Step 7: Update EAS Build Configuration

Add build caching to your eas.json profiles. Update your iOS deployment target to 15.1 (SDK 55's minimum). Update your Android minSdkVersion to 24. If you use custom build plugins, verify they are compatible with the new Expo CLI version shipped with SDK 55. Submit a test build to EAS Build before merging. Verify that both platforms build successfully and the resulting binaries pass smoke tests.

Hermes v1 deserves its own section because the performance improvements are substantial enough to change how you think about React Native performance optimization. If your team has been working around Hermes limitations, some of those workarounds can now be removed.

The generational garbage collector is the biggest change. Previous Hermes versions used a single-generation mark-and-sweep collector that would occasionally pause the JavaScript thread for 5-15ms. In a 60fps app, your frame budget is 16.6ms, so a single GC pause could drop a frame. Hermes v1's generational collector divides the heap into young and old generations. Young generation collections complete in under 1ms. Old generation collections are less frequent and use incremental marking to spread work across multiple frames.

What this means in practice: if your team added useMemo or useCallback specifically to reduce GC pressure (not for referential equality in dependency arrays), you can likely remove those optimizations. The new GC handles short-lived allocations efficiently enough that memoizing simple computations costs more in code complexity than it saves in runtime performance.

The bytecode compiler also matters for cold start time. The new compiler produces more compact bytecode with better register allocation. Our benchmarks on a Samsung Galaxy A54 showed cold start improvements from 1.8 seconds to 1.5 seconds for a 300-screen app. On iPhone 13, the improvement was smaller (0.9s to 0.8s) because iOS devices have faster storage.

One caveat: Hermes v1 changes the behavior of WeakRef and FinalizationRegistry. If your code depends on specific GC timing for cleanup callbacks, test carefully. The new collector finalizes objects on a different schedule, which can expose latent bugs in code that assumes deterministic finalization order.

Every time we start a migration project, the client says "we think it will take two weeks." The actual timeline depends almost entirely on third-party library compatibility. The core Expo and React Native migration is well-documented and predictable. It is the long tail of community packages that creates surprises.

Here is a compatibility snapshot of the most commonly used libraries as of May 2026:

• react-navigation 7.x: Fully compatible. Make sure you are on 7.0 or later.
• react-native-reanimated 4.x: Fully compatible. Version 3.x works but has deprecation warnings. Update to 4.x.
• react-native-gesture-handler 3.x: Fully compatible.
• react-native-svg 16.x: Fully compatible with Fabric. Older versions (pre-15.0) are not.
• react-native-maps 2.x: Fully compatible. Version 1.x is not compatible with Fabric.
• react-native-firebase 21.x: Fully compatible. Version 19.x and below require the bridge.
• react-native-video 7.x: Fully compatible with the new Fabric renderer.
• @shopify/flash-list 2.x: Fully compatible and recommended over FlatList for large datasets.
• lottie-react-native 7.x: Compatible. Versions below 7.0 use the old component registration API.

The packages that cause the most migration pain are typically: older payment SDKs (Stripe's React Native SDK below version 0.40 uses Bridge), custom analytics integrations with internal native modules, and niche hardware integrations (Bluetooth, NFC, custom camera pipelines). If your app uses any of these, budget extra time.

One strategy that works well: create a minimal reproduction app with just your problematic dependencies. Build it against SDK 55, see what breaks, and fix issues in isolation before attempting the migration in your production codebase. This avoids debugging a broken build where you cannot tell if the issue is a library incompatibility or a bug in your own code.

How long does this actually take? Based on our experience migrating apps ranging from 50-screen MVPs to 500-screen enterprise applications, here are realistic timelines:

Apps Already on New Architecture (83% of projects)

If your app already runs on the New Architecture (you enabled it in SDK 53 or 54), the SDK 55 upgrade is straightforward. Budget 2-3 days for a senior React Native engineer. Bump SDK versions, update deprecated API calls, run expo-doctor, update flagged dependencies, and test. Most of this is mechanical.

Apps Still on Legacy Architecture with Clean Dependencies

If expo-doctor shows no "Incompatible" packages, budget 1-2 weeks for one senior engineer. The first week covers the architecture migration: enabling New Architecture, fixing build errors, updating native module registration. The second week is testing and fixing layout regressions. If you have solid E2E tests (Detox or Maestro), testing goes faster.

Apps with Incompatible Dependencies or Custom Native Modules

This is where timelines stretch. Each incompatible library that needs a fork or replacement adds 2-5 days. Each custom native module rewrite adds 2-4 days. A complex app with 3-4 incompatible libraries and 2 custom native modules could take 4-6 weeks of focused engineering time. If your team has never worked with TurboModules or Fabric, add a week for learning.

Our Recommendation

Do not let this migration sit in the backlog. SDK 53 support ends in August 2026. If you are still on SDK 53 or earlier, you will stop receiving security patches and bug fixes. For teams that have a complex migration ahead, starting now gives you a comfortable buffer. For teams with a clean upgrade path, there is no reason not to do it this sprint.

If your team is stretched thin or lacks native module expertise, outsourcing the migration to a team that has done it before can save you weeks. We have run this playbook enough times to know where the landmines are, and we can typically complete a complex migration in half the time it takes a team doing it for the first time.

Once your app builds and runs on SDK 55, resist the temptation to merge immediately and move on. There are several optimizations you should make while you are already in the codebase:

Enable EAS Build Caching

Add "cache": true to every build profile in your eas.json. This is a one-line change that saves 30% on build times. For teams running 10+ builds per day during active development, that translates to hours of saved CI time per week.

Adopt the New Native APIs

The object-oriented Contacts, Calendar, and MediaLibrary APIs are not just cosmetic changes. They reduce memory usage through lazy loading and provide better TypeScript types. If your app uses any of these modules, update to the new APIs now rather than carrying the deprecated function calls forward.

Profile with Hermes v1

Open the Hermes profiler (available through the built-in DevTools in SDK 55) and profile your app's startup and key user flows. Hermes v1's profiler provides more granular timing data, including GC pause visualization and bytecode execution heatmaps. You might find that bottlenecks you assumed were "just how React Native works" are actually fixable now.

Use the RenderNode Blur API

If your app uses @react-native-community/blur, replace it with the native blur style property. Fewer dependencies, better performance, and one less community package to maintain. The API is simple: style={{ blurRadius: 20 }} on any View component.

Review Your Memoization Strategy

With React 19.2's improved reconciler and Hermes v1's faster GC, many aggressive memoization patterns are no longer necessary. Keep memoization where it prevents expensive re-renders, but remove it where it was added purely to reduce object allocations. Simpler code is easier to maintain.

The React Native ecosystem has matured significantly over the past two years. SDK 55 represents the culmination of a multi-year effort to modernize the rendering pipeline and module system. Teams that complete this migration are in a strong position: faster builds, better performance, smaller binaries, and access to the latest React features.

If you are planning your SDK 55 migration and want a second set of eyes on your dependency audit, architecture, or timeline estimate, we are happy to help. Book a free strategy call and we will walk through your project together.