Expo SDK 56 vs Flutter Impeller 2: Mobile Performance 2026

The mobile framework landscape shifted dramatically in 2026. Expo SDK 56 shipped with React Native's New Architecture fully baked in, including Fabric rendering, TurboModules, and bridgeless mode as the only option. On the other side, Flutter's Impeller 2 engine replaced Skia entirely, rewriting the rendering pipeline from the ground up for metal-first GPU compositing.

These are not incremental updates. They are architectural rewrites that change the performance ceiling of each framework. If you made a framework decision based on benchmarks from 2024 or earlier, those numbers no longer apply.

We have shipped production apps with both stacks this year. We ran our own benchmarks on identical hardware, built the same reference app in both frameworks, and measured everything we could instrument. This article shares those findings so you can make an informed decision based on real data, not marketing slides.

If you want a broader comparison of these frameworks beyond performance, our React Native vs Flutter breakdown covers hiring, ecosystem, and long-term maintenance in depth.

Before diving into benchmarks, you need to understand how fundamentally different these rendering engines are. The architecture determines the performance ceiling, and knowing the mechanics helps you predict where each framework will struggle.

Expo SDK 56 with Fabric and JSI

React Native's New Architecture, now the default in Expo SDK 56, replaced the old asynchronous bridge with three interconnected systems:

• Fabric is the new rendering system. It creates a shadow tree in C++ that maps directly to native platform views. Layout calculations happen synchronously, which eliminates the frame-delay jank that plagued the old architecture.
• JSI (JavaScript Interface) lets JavaScript call C++ functions directly, with no serialization overhead. This means your JS code can read native view measurements, trigger haptic feedback, or access device sensors without waiting for a bridge round-trip.
• TurboModules are lazy-loaded native modules. Instead of initializing every native module at startup, the app loads them on demand. This cut our production app's cold start by 340ms on a Pixel 7.

The key insight: React Native still renders using platform-native UI components. A ScrollView on iOS is a real UIScrollView. A TextInput on Android is a real EditText. You get native behavior, accessibility, and platform conventions for free.

Flutter with Impeller 2

Flutter takes the opposite approach. It does not use a single platform UI component. Impeller 2 draws every pixel directly to the GPU through a rendering pipeline built from scratch:

• Precompiled shaders eliminate the shader compilation stutter (the "jank on first run" problem that haunted Skia-based Flutter). Impeller 2 ships with all shaders pre-built, so the first frame renders as smoothly as the thousandth.
• Metal-first on iOS, Vulkan-first on Android. Impeller 2 targets modern GPU APIs natively instead of translating through compatibility layers. This gives it lower-level control over draw calls and buffer management.
• Tessellation engine converts vector paths to GPU-ready triangles more efficiently than Skia's approach, cutting path rendering time by roughly 40% in our tests.
• Dart AOT compilation produces native ARM code. No JIT warmup, no interpreter overhead. Your business logic runs at near-C++ speeds.

The key insight: Flutter owns every pixel, which gives it total control over rendering fidelity but means it must reimplement platform behaviors (scrolling physics, text selection, accessibility) from scratch.

We built an identical reference app in both frameworks: a tabbed layout with five screens, network data loading, local storage initialization, and 200 list items. We measured time-to-interactive (TTI) on three devices: iPhone 15 Pro, Pixel 8, and a budget Samsung Galaxy A15.

Cold Start Results (TTI in milliseconds)

• iPhone 15 Pro: Expo SDK 56 averaged 410ms. Flutter Impeller 2 averaged 380ms.
• Pixel 8: Expo SDK 56 averaged 520ms. Flutter Impeller 2 averaged 460ms.
• Galaxy A15 (budget): Expo SDK 56 averaged 1,180ms. Flutter Impeller 2 averaged 890ms.

Flutter wins on raw cold start across the board, and the gap widens on lower-end hardware. The reason is straightforward: Dart's AOT compilation produces a single native binary, while React Native still needs to initialize the Hermes JavaScript engine, parse the JS bundle, and set up the TurboModule registry.

That said, Expo SDK 56 improved dramatically over previous versions. The bridgeless mode and lazy TurboModule loading shaved roughly 25% off cold start compared to SDK 53. For the full list of SDK 56 improvements, we covered the migration path in a dedicated guide.

Warm Start and Resume

When resuming from the background, the gap nearly disappears. Both frameworks restored state in under 100ms on all three devices. This matters because most real users open your app from a backgrounded state, not from a fresh kill. In practice, the cold start difference is less noticeable than the benchmarks suggest.

Verdict: Flutter starts faster, especially on budget Android hardware. If your target audience skews toward mid-range devices in emerging markets, this gap is worth taking seriously. On flagship phones, both are fast enough that users will not perceive a difference.

Smooth animations are the difference between an app that feels premium and one that feels janky. We tested four animation scenarios: a shared element transition, a parallax scroll effect, a complex staggered list animation, and a gesture-driven card swipe with spring physics.

Frame Rate Consistency (Pixel 8, 120Hz display)

• Shared element transition: Expo SDK 56 held 118-120fps with Reanimated 4. Flutter held a locked 120fps.
• Parallax scroll: Both hit 120fps consistently. No dropped frames on either framework.
• Staggered list animation (50 items): Expo SDK 56 dropped to 90-100fps during the initial burst. Flutter held 115-120fps throughout.
• Gesture-driven card swipe: Both maintained 120fps. React Native Gesture Handler's Fabric integration made gesture response indistinguishable from native.

The critical detail here is that React Native Reanimated 4 now runs animation worklets entirely on the UI thread via JSI. Animations defined with Reanimated never touch the JavaScript thread at all. This is a fundamental shift from the old architecture where complex animations could block the JS thread and cause dropped frames.

Flutter's advantage shows up in complex, multi-element animations where dozens of widgets animate simultaneously. Impeller 2's tessellation engine handles concurrent path animations more efficiently than Fabric's view-based approach. When you have 50 items all animating at once with different curves and delays, Flutter's rendering pipeline simply has less overhead per element.

For most production apps, though, you are not animating 50 items simultaneously. You are animating a navigation transition, a modal entrance, or a pull-to-refresh indicator. In those typical scenarios, both frameworks deliver indistinguishable results. Our detailed React Native New Architecture guide explains how Fabric and Reanimated work together to achieve this.

Verdict: Flutter Impeller 2 has a slight edge in animation-heavy scenarios with many concurrent animated elements. For typical app animations (transitions, gestures, micro-interactions), both frameworks hit 120fps consistently on modern hardware.

Performance is not just about frame rates. Memory efficiency determines whether your app survives on a 3GB RAM budget phone. List scrolling performance affects every social feed, e-commerce catalog, and messaging thread. Binary size impacts download conversion rates. We measured all three.

Memory Usage (Reference App, Pixel 8)

• Idle after launch: Expo SDK 56 used 58MB. Flutter used 72MB.
• After scrolling 500 list items: Expo SDK 56 peaked at 95MB. Flutter peaked at 110MB.
• After navigating 10 screens: Expo SDK 56 settled at 82MB. Flutter settled at 98MB.

React Native's lower memory footprint comes from its use of native views. A native RecyclerView on Android is aggressively optimized by Google's platform team, with view recycling honed over a decade. Flutter's widget recycling is good, but it carries the overhead of the Dart VM and the Impeller rendering context on top of whatever the widgets themselves consume.

List Scrolling Performance

We built a list with 10,000 items, each containing an image, three lines of text, and two action buttons. We measured frame drops during fast fling scrolling.

• Expo SDK 56 with FlashList: Zero frame drops at 120fps during fast scrolling. FlashList's recycling architecture, combined with Fabric's synchronous layout, handles massive lists effortlessly.
• Flutter with SliverList: Occasional single-frame drops (119fps dips) during extremely fast flings. Adding a const constructor to the list item widget eliminated these entirely.

Both frameworks handle large lists extremely well in 2026. This was a genuine pain point for React Native two years ago, but FlashList plus the New Architecture closed that gap completely.

Binary Size (Release Build, iOS)

• Expo SDK 56: 12.4MB IPA for our reference app.
• Flutter Impeller 2: 18.7MB IPA for the same app.

Flutter's larger binary is structural. It ships the Dart runtime, the Impeller engine, and its own implementations of text rendering, scrolling physics, and accessibility. React Native leverages the platform's existing implementations, so it only ships the JS bundle, Hermes, and native module binaries.

A 6MB difference matters more than you might think. App store data consistently shows that every 5MB increase in download size reduces install conversion by 1-2% in emerging markets where users are on metered data connections.

Verdict: React Native wins on memory efficiency and binary size. Flutter is within acceptable ranges for both, but if you are targeting budget devices or download-sensitive markets, React Native's lighter footprint is a measurable advantage.

Raw performance gets the headlines, but developer velocity determines how quickly you actually ship. We compared the full development workflow for both frameworks.

Hot Reload Speed

• Expo SDK 56: Fast Refresh averages 280ms for component state changes. Full reload (bundle rebuild) takes 1.2 seconds on our M3 MacBook Pro.
• Flutter Impeller 2: Hot reload averages 180ms for widget changes. Hot restart takes 2.1 seconds.

Flutter's hot reload is still faster for individual widget tweaks. However, Expo's Fast Refresh preserves component state more reliably. You change a style, and your scroll position, form inputs, and navigation state stay exactly where they were. Flutter's hot reload preserves state most of the time, but complex widget trees occasionally require a full hot restart.

Build and CI/CD Tooling

Expo Application Services (EAS) is the standout advantage for the React Native ecosystem. EAS Build compiles your iOS and Android binaries in the cloud without needing a Mac for iOS builds. EAS Submit pushes directly to App Store Connect and Google Play. EAS Update delivers JavaScript bundle updates over the air, bypassing app store review entirely for non-native changes. This alone can shave days off your release cycle.

Flutter CLI is capable but more manual. You need a local Mac for iOS builds (or a Mac runner in your CI pipeline). Publishing to stores requires additional tooling like Fastlane or Codemagic. There is no built-in OTA update mechanism. Every change, no matter how small, requires a full app store submission and review.

Testing Frameworks

• Expo/React Native: Jest for unit tests, React Native Testing Library for component tests, Detox or Maestro for E2E tests. The testing ecosystem is mature but fragmented across multiple tools.
• Flutter: Built-in test runner handles unit, widget, and integration tests in a single framework. The flutter test command covers all three tiers without additional dependencies. This is genuinely better than the React Native testing story.

Verdict: EAS gives Expo a significant edge in build, deploy, and update workflows. Flutter's unified testing framework is cleaner. For overall development velocity, Expo's toolchain saves more time across the full ship cycle, especially for small teams that cannot afford dedicated DevOps resources.

Benchmarks tell you what is technically possible. Production apps tell you what actually matters. Here is where each framework shines in the real world, and our recommendation for choosing between them.

Platform-Specific UI Fidelity

React Native renders with native components, which means your app automatically gets platform-specific behaviors: iOS swipe-to-go-back, Android material ripple effects, system font scaling, and native accessibility tree integration. You do not build these. They come for free.

Flutter reproduces these behaviors in its own rendering engine, and Impeller 2 does an excellent job of it. But reproduction is not the same as native. Edge cases surface: text selection handles that feel slightly off, scroll overscroll effects that do not match the platform exactly, or accessibility announcements that use custom implementations instead of platform APIs. For most users, these differences are imperceptible. For apps in regulated industries (healthcare, finance) where accessibility compliance is audited, native component rendering provides a safer compliance path.

Real-World Production Examples

Apps that thrive on Expo SDK 56: fintech dashboards with complex data tables, social platforms with infinite scroll feeds, marketplace apps with search and filtering, SaaS companion apps that share a codebase with their web dashboard. These apps are content-driven, form-heavy, and benefit from native platform conventions.

Apps that thrive on Flutter Impeller 2: design tools with custom canvas rendering, media-rich apps with bespoke transitions, brand-forward consumer apps where visual identity trumps platform convention, apps targeting iOS, Android, web, and desktop simultaneously from a single widget tree.

Our Recommendation

Choose Expo SDK 56 when:

• Your team writes TypeScript and you want to share code with a React web app
• You need OTA updates to ship fixes without app store review delays
• Your app is content-driven, form-heavy, or data-display focused
• You are targeting budget Android devices where memory and binary size matter
• You want cloud builds and managed CI/CD without maintaining Mac infrastructure

Choose Flutter Impeller 2 when:

• Your app demands heavy custom animations with dozens of simultaneous animated elements
• Pixel-identical rendering across every platform is a hard requirement
• You are building a visual tool, creative app, or graphics-intensive experience
• Your team is starting fresh and prefers Dart's type system and Flutter's widget composition model
• You need a single codebase that targets mobile, web, and desktop with identical UI

Here is the honest take from someone who ships with both: for 80% of the apps startups ask us to build, Expo SDK 56 is the better choice. The performance gap with Flutter has narrowed to the point where it only matters in animation-heavy edge cases, and the developer experience advantages (EAS, OTA updates, TypeScript code sharing, larger talent pool) compound over the life of the project.

Flutter Impeller 2 is the right call when visual fidelity is the product. If your app's value proposition lives in its UI, in custom animations, in a brand experience that needs to look identical everywhere, Flutter gives you more direct control over every pixel.

Either way, stop debating and start building. Both frameworks are production-ready and battle-tested. The biggest risk is not picking the wrong one. It is spending three months deciding instead of shipping.

Not sure which framework fits your product? Book a free strategy call and we will review your requirements, timeline, and team to give you a concrete recommendation.