DEV Community: Dan

What Expo’s Series B funding means for you

Dan — Sat, 27 Jun 2026 14:41:56 +0000

Originally published on expo.dev/blog by Charlie Cheever.

Expo raised some money.

We raised a $45MM Series B from Georgian and some other great partners. We picked them because they have a track record of partnering with and helping other great developer infrastructure companies like Replit and Render and Dagster. And they just get it.

The first thing they showed us when we initially met them was a bunch of stuff people on their team had built with Expo. It's going to be great to work with them.

We have been profitable for a while so we didn't need to raise money to keep going. But we're seeing so many things that people want from Expo right now and we want to build them, ASAP, and this round will let us do more.

There are a million things we can do to make the apps you bring to life with Expo closer to being exactly what you're dreaming. And there is a handful of things we want to build for you to make that process easier and faster. This funding makes it possible for us to hire engineers to try and build everything.

All the new ways that people are using Expo with AI have also made our todo list way, way longer. We can see a path to letting everyone in the world who has grit and vision make application software (not just the people who are software developers today).

What a fun and crazy time to be helping people make software. There's so much to do. This round of funding lets us really go after it.

If you’re passionate about our mission to make app development better and easier please take a look at our open roles and reach out if you see something that fits your skills.

The real cost of React Native animations: benchmarking every approach

Dan — Fri, 26 Jun 2026 17:07:15 +0000

Originally published on expo.dev/blog by Janic Duplessis.

This is a guest post from [*Janic Duplessis](https://www.linkedin.com/in/janic-duplessis-4aa83171/) - He is the head of consulting at App&Flow and a long-time React Native contributor. *
…

Picture a login screen with a slowly drifting background, the kind of subtle motion that makes a product feel polished rather than built. Simple enough. We implemented it with Reanimated and shipped it. But every now and then, you could catch a frame drop. Just enough to feel slightly off, the kind of thing that bugs you once you’ve seen it.

The root cause is that Reanimated runs on the UI thread every frame. When the app does significant work during that frame (a re-render kicks in, a list scrolls, an input updates), the animation budget shrinks, and that slow background translate becomes a slow background stutter.

At App & Flow, we build React Native apps and tools for product teams that care about getting the details right. Fluid, native-feeling UIs are a big part of that. So instead of working around the problem, we went looking for a better approach.

Core Animation on iOS hands animations off to the OS render server and never touches your thread again. Once you give it a CAAnimation, the system drives it and your app is out of the loop entirely. We wanted that in React Native. That’s how react-native-ease came about, a declarative animation library that drives everything through platform APIs (Core Animation on iOS, ObjectAnimator on Android) with no JS loop, no worklets, and no shadow tree commits per frame.

But building it raised a question we wanted to answer honestly: how much does the choice of animation library actually matter?

So we measured it. Across four approaches, two platforms, and both high-end and mid-range devices, we tracked per-frame UI thread overhead. This post shares what we found, and tries to answer the questions that actually matter: how large is the frame penalty? In what kinds of apps does it matter? And what should you prioritize when choosing an animation library?

💡 The frame drops on the Reanimated side are simulated. We injected artificial UI thread pressure to reproduce what happens in a busy app. Real-world jank depends on your workload, device, and how much else is happening on the UI thread at the same time.

The four React Native animation libraries tested

All benchmarks were run in April 2026 with Expo SDK 55, React Native 0.83, Reanimated 4.3.0, and react-native-ease 0.7.0.

We compared four animation approaches:

Ease: react-native-ease, using platform APIs directly. Animations are described as props on the JS side and driven natively with no per-frame JS involvement.
Reanimated (Shared Values): the standard worklet-based approach. Values are driven on the UI thread via a C++ worklet runtime, but each frame still updates props through the shadow tree.
Reanimated (CSS Animations): Reanimated’s newer CSS animation API. Declarative like Ease, but still backed by Reanimated’s animation engine.
RN Animated: React Native’s built-in Animated API with useNativeDriver: true. Values are driven natively, but the implementation varies by platform.

We also tested Reanimated with its static feature flags enabled, specifically ANDROID_SYNCHRONOUSLY_UPDATE_UI_PROPS and IOS_SYNCHRONOUSLY_UPDATE_UI_PROPS, which let Reanimated skip the shadow tree commit when only non-layout props (like transform and opacity) are updated. A meaningful optimization worth calling out separately.

Note: RN 0.85 introduced a new Shared Animation Backend that will eventually make the feature flags unnecessary. Reanimated’s integration is in progress but not yet released.

How the benchmark measures per-frame overhead

We built a benchmark screen into the example app that animates N views simultaneously in a loop (translateX, 2s, linear, repeating). We used a custom Expo native module to measure per-frame overhead:

iOS: We swizzle CADisplayLink’s factory method to intercept all display link callbacks registered by any framework, then measure wall-clock time per callback aggregated by frame timestamp.
Android: We use Window.OnFrameMetricsAvailableListener, which reports ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, and DRAW_DURATION from the platform’s frame metrics system.

We ran 5-second collection windows per test and multiple configurations to show both worst-case and best-case Reanimated performance.

Benchmark results: per-frame UI thread cost on iOS and Android

Android (Moto G8 Plus)

Android is the most apples-to-apples comparison between libraries. Every approach runs on the UI thread, so what you’re seeing is a direct measure of how much work each animation engine adds per frame. No tricks, no shortcuts.

How much does build configuration matter? (50 views, avg ms)

The single biggest variable for Reanimated performance isn’t which animation API you pick. It’s whether you’re testing in a debug or release build.

The red line is the 16.67ms frame budget at 60fps. In debug mode, Reanimated SV and CSS both blow past it at just 50 views, actively dropping frames. The same animation in a release build comes in at 11ms. Debug builds lie. If you notice animation jank during development, reproduce it in a release build before panicking.

The feature flags add another 11–19% on top by bypassing the shadow tree commit for non-layout props. They can cause visual bugs in some apps so they’re opt-in, but worth testing if you’re seeing overhead.

How does overhead scale with view count? (Release, all FF, avg ms)

💡 500 views is a stress test, not a realistic target. If you're animating 500 things at once, the animation library might not be your biggest problem.

At 10–100 views, all approaches stay under the frame budget on average, though Reanimated and RN Animated are within 5ms of it at 100 views, leaving little headroom for the rest of your frame work. At 500 views, only Ease stays under budget. Reanimated SV hits 36ms, more than twice the frame budget; and this is the optimized configuration.

iOS (iPhone 15 Pro)

iOS is where the architectural difference becomes impossible to ignore. On Android, all libraries share the UI thread, so the comparison is fair. On iOS, Ease gets to cheat (in the best way). Core Animation runs in a separate OS render server process, completely outside your app. Once Ease registers a CAAnimation, the system takes over and your thread is free to do other work. That’s why Ease shows ~0.01ms across the board: there is genuinely nothing happening on the UI thread per frame. The tradeoff is that Core Animation animations can’t be read or interrupted from JS mid-flight, which is exactly why gesture-driven animations still belong to Reanimated.

Display link callback time per frame, ms (release build)

The absolute numbers are lower than Android because the measurement captures only UI thread callback time. But the point stands: on iOS, Ease adds no UI thread cost regardless of how many views are animating, while every other approach keeps doing work every frame.

Why React Native animation libraries differ in per-frame cost

The shadow tree tax

Every frame, Reanimated’s worklet computes new values and commits a prop update through the shadow tree. That commit runs Yoga layout, prop diffing, and view mutations. When you’re animating transform or opacity (properties with zero effect on layout) every bit of that work is wasted. You’re paying the full price of a layout pass to nudge a blob three pixels to the left. Yoga doesn’t need to know.

The feature flags (ANDROID/IOS_SYNCHRONOUSLY_UPDATE_UI_PROPS) short-circuit this by pushing visual prop updates directly to the UI layer, skipping the layout pass entirely. On the Moto G8 Plus at 50 views they cut Reanimated SV from 11.87ms to 10.57ms (-11%) and CSS from 11.20ms to 9.06ms (-19%). They’re opt-in because they can cause visual bugs in some apps, but if you’re chasing overhead they’re the first thing to try.

RN Animated

RN Animated with useNativeDriver: true skips the JS thread per frame too, but drives animations through a separate native animation module that carries bookkeeping overhead per animated node. It holds up fine at low-to-mid view counts, but scales worse than Reanimated CSS as the number of animated views climbs. This is partly because it lacks the shadow tree optimizations the feature flags enable.

When your animation library choice matters in production apps

It matters most for long-running or slow animations: skeleton loaders, drifting backgrounds, ambient UI effects. A single dropped frame in a 5-second animation is noticeable, and other work (data fetching, re-renders, user interaction) is almost always happening at the same time. It also matters for anything in a list, where you can easily have hundreds of animated items on screen at once. On low-end devices, small per-frame overhead compounds fast, and your users notice before you do.

For short one-shot transitions (a button press, a toast, a modal) the overhead is negligible and any library works fine.

Worth noting: Ease only covers this specific use case. Gesture-driven animations (scroll-linked, drag, swipe) and anything that changes layout properties (width, height, padding) still need Reanimated or RN Animated. Ease is purpose-built for declarative, trigger-based animations on visual properties.

React Native 0.85 and the Shared Animation Backend

React Native 0.85 ships an experimental Shared Animation Backend, a unified animation engine built directly into the renderer by Meta and Software Mansion. Once Reanimated’s integration ships, SYNCHRONOUSLY_UPDATE_UI_PROPS becomes unnecessary because shadow tree bypass will be the default path, and the gap between “default Reanimated” and “optimized Reanimated” effectively goes away.

The architectural difference remains, though. Ease has no per-frame animation engine at all. Even with a faster backend, Reanimated still computes values and pushes prop updates every frame. That overhead doesn’t disappear; it just gets smaller. We’ll update the benchmarks once the integration ships.

Running the React Native animation benchmark yourself

The benchmark is built into the example app. Clone the repo, run yarn example ios or yarn example android, and tap Benchmark from the demo screen. Source is in example/src/demos/BenchmarkDemo.tsx and the native module is in example/modules/frame-metrics/.

One note: use release builds. Debug mode inflates Reanimated’s numbers significantly. So if your numbers look alarming, that’s likely why.

yarn example ios --configuration Release
yarn example android --variant release

*react-native-ease is built by App & Flow, a Montreal-based React Native engineering studio recommended by Expo.*

5 proven strategies to increase adoption of your B2B mobile app

Dan — Thu, 25 Jun 2026 16:19:04 +0000

Originally published on expo.dev/blog by Dan Kelly.

B2B mobile apps face a different challenge than consumer apps. You're not competing for attention on social media. You're competing for budget approval, security reviews, and change management bandwidth.

The decision to adopt your app isn't made by one person scrolling through the App Store at 11pm. It's made by a team evaluating ROI, integration complexity, and whether your app will actually get used after the procurement process ends.

Customer acquisition costs have climbed 60% in five years, but throwing money at ads won't solve the B2B adoption problem. Enterprise buyers don't install apps because they saw a Facebook ad. They install apps because they trust your business, understand the ROI of your app, and believe their team will actually use it.

Here's what actually works for driving adoption of B2B mobile apps in 2026.

Focus on onboarding that delivers the "Aha!" moment fast

Your app has 60 seconds to prove its value. Maybe less.

Enterprise users are busy. They're evaluating your app between meetings, during a commute, or while waiting for their coffee. If they don't immediately understand what problem you solve and how to solve it, they'll uninstall and tell procurement it "wasn't a good fit."

Show the value immediately

Don't start with account creation. Don't ask for 12 fields of company information. Don't require them to "sync data" before they can do anything.

Show them what your app does first. Let them experience the core value before asking for commitment.

Expensify nails this. Take a photo of a receipt. The app instantly extracts the vendor, amount, date, and category. Within 15 seconds of opening the app for the first time, you've seen it work. That's your "Aha!" moment. Everything else (creating an account, connecting to your company's expense system) happens after you've already experienced the value.
Figma's mobile app lets you view and comment on designs immediately. No account required for viewing shared links. By the time you're ready to create an account, you've already collaborated on three designs and understand exactly why your team needs this.

Guide users to one meaningful action

The best mobile onboarding focuses on completing one core action, not explaining every feature.

For a project management app, that's creating their first task. For a sales tool, that's logging their first activity. For an analytics app, that's seeing their first dashboard (dashboards = dollars, after all).

Everything else can wait. Get them to that moment where they think "oh, this actually helps me" and the rest of onboarding becomes easier.

Test with real users before you launch

Don't wait until your app is "perfect" to get feedback. Use TestFlight (iOS) and internal testing tracks (Android) to get your app in front of real users early (Expo Launch is the fastest way to get to TestFlight).

You can have up to 10,000 external testers on TestFlight. That's more than enough to validate your onboarding, find confusing flows, and identify bugs before they hit the App Store.

Here's the workflow that works:

Week 1-2 of development: Ship to TestFlight with just the core feature
Recruit 20-50 testers from your target industry (not friends and family)
Watch them use it: Schedule video calls where they share their screen
Count completions: If fewer than 80% complete the core action in 5 minutes, iterate
Repeat weekly: Each TestFlight build should be better than the last

More teams should be doing this. TestFlight exists precisely for this purpose, and the feedback you get is worth 100x more than internal testing alone.

Build case studies and ROI calculators into your marketing

B2B buyers need to justify the purchase. They're spending company money, not their own. That means they need evidence this will work.

Your job is to help your users sell your product to their managers. Give them the nutrients they need to make the business case internally.

Create case studies that show real results

"Acme Corp increased productivity by 30%" is better than "our app is great for productivity." But the best case studies go deeper.

They explain the problem Acme faced, the specific features they used, and the measurable outcome. They include a real person's name and title. They provide enough detail that a prospect can think "that sounds like us."

Your case studies should answer:

What problem were they trying to solve?
Why did they choose your app over alternatives?
How did they roll it out to their team?
What specific metrics improved and by how much?
What would they tell someone else your app?

Let your customer write it. The best case studies are written by the customer themselves, with light editing from your team. This creates authenticity that a ghostwritten case study never achieves. Prospects can tell the difference between "here's what the vendor says we said" and "here's what we actually experienced."

Offer to help with structure and editing, but let their voice come through. Awkward phrasing and industry-specific jargon actually make case studies more credible.

Build an ROI calculator

Let prospects input their own numbers and see potential value. "If your team of 50 people saves 30 minutes per week using our app, that's $156,000 in annual productivity gains."

The calculator doesn't need to be sophisticated. It needs to be honest and help them make the business case internally.

Put it on your website. Link to it from your app store listing. Make it easy to screenshot and include in a procurement document.

Use customer quotes everywhere

Real companies using your app is social proof. Use their logos. Quote their teams. Link to their case studies.

People are tribal. We trust people who are like us more than we trust companies selling to us. When a prospect sees that companies like theirs are already using your app successfully, it reduces perceived risk. The question shifts from "will this work?" to "how do we implement this?"

This is why "Trusted by 10,000+ businesses" is less powerful than "Trusted by teams at [Logo] [Logo] [Logo]." Seeing specific companies in your industry creates tribal trust that generic numbers never will.

Target LinkedIn and industry-specific communities (not just Reddit)

B2B buyers aren't only browsing r/AppHookup looking for enterprise software, but decisions do get influenced on Reddit. They're also on LinkedIn, in industry Slack channels, and on specialized forums for their profession.

LinkedIn is where B2B decisions happen

Developers tend to roll their eyes when I talk about Linkedin. I get it. But your target users are on LinkedIn every week. They're reading industry news, following thought leaders, and looking for solutions to their problems.

Post content that addresses their specific challenges. "5 ways operations managers are using mobile apps to reduce manual data entry" will perform better than "check out our cool app."

Use LinkedIn's targeting to reach decision makers. You can target by job title, company size, and industry. A well-targeted post to 1,000 operations managers at mid-sized logistics companies will drive more qualified installs than a viral tweet (we see this often at Expo).

Find where your users already gather

Every industry has its digital watercoolers. For developers, it's GitHub, Twitter, and Reddit (it used to also include Stack Overflow and Hacknews). For marketers, it's specialized Slack communities and forums. For healthcare professionals, it's HIPAA-compliant messaging platforms and professional associations.

Figure out where your target users already spend time professionally. Tools like SparkToro can help you discover where your audience actually hangs out online, what podcasts they listen to, and what websites they visit. Stop guessing and start using data to find your people.

Once you know where they are, show up there with genuinely helpful content. Answer questions. Share insights. Demonstrate expertise. Mention your app when it's relevant, but don't make that the primary goal. Build trust first.

Write for industry publications

Getting featured in an industry publication carries more weight than any ad you could run.

Pitch editors with genuinely useful content. "How mobile apps are changing field service management" is interesting. "Download our app" is not.

The article should educate first and mention your app second. The goal is to position your company as an authority in the space. When readers need a solution later, they'll remember you.

Offer pilot programs and soft launches with key accounts

Enterprise sales works differently than consumer sales. You can't expect companies to commit to a full rollout without proof it will work for their team.

Start with a pilot program

Offer a free or heavily discounted pilot to 10-20 users at a target company. Give them 30-60 days to test the app with real work.

The pilot should include:

Dedicated onboarding support (not just a welcome email)
Weekly check-ins to address issues and answer questions
Clear success metrics you're tracking together
An easy path to expand to the full organization

Most pilots either prove the value quickly (leading to expansion) or reveal issues you need to fix (leading to a better product).

Make expansion frictionless

If the pilot succeeds, make it easy to expand. Have pricing ready. Have the contract ready. Have the rollout plan ready.

The momentum from a successful pilot can disappear quickly if procurement takes 6 weeks to process the expansion. Strike while the team is excited and seeing results.

Document everything for the next pilot

What worked in this pilot? What questions did users ask repeatedly? What friction points slowed adoption?

Use these insights to improve the next pilot. Each one should be smoother and more successful than the last.

Optimize for search intent with long-tail professional keywords

Enterprise buyers search differently than consumers. They search for solutions to specific work problems, not generic app categories.

Target problem-based search terms

"App for tracking construction site inspections" is how someone actually searches. "Construction app" is too broad.

"Mobile CRM for pharmaceutical sales reps" is specific. "CRM app" could mean anything.

Long-tail keywords have lower competition and higher conversion because the searcher knows exactly what they need.

Write your app store description for search

Your app store description should include the specific problems you solve and the industries you serve.

"Field service management app for HVAC contractors to schedule jobs, track inventory, and generate invoices" tells Google and the App Store exactly what you do. It also tells the right prospects they're in the right place.

Optimize your website for these searches too

When someone searches "mobile app for restaurant inventory management," your website should rank, not just your app store listing.

Create dedicated landing pages for your target use cases. Include the search terms naturally in the content. Link to your app store listings.

This expands your discoverability beyond the app stores and gives prospects more information to evaluate your solution.

The enterprise reality you're working with

B2B app adoption is slow. It requires multiple touchpoints. It involves multiple decision makers. The median app makes under $50 per month after a year, and B2B apps follow similar patterns without focused effort.

But B2B apps have advantages consumer apps don't:

Higher lifetime value per user
More predictable revenue (contracts and subscriptions)
Easier to target decision makers
Word of mouth within industries is powerful
Successful deployments lead to referrals

The key is focusing on ROI, trust, and demonstrable value. B2B buyers will pay for solutions that work. They just need proof before they commit.

Start with onboarding because it determines whether your pilot succeeds. Build case studies because they enable prospects to justify the purchase internally. Target the right channels because enterprise buyers aren't where consumer buyers are. Offer pilots because companies need to test before they buy. Optimize for search because that's how problems turn into solutions.

Try it now: If you have an existing B2B app, audit your first-time user experience. Open the app as if you've never seen it before. Can you complete one valuable action in under 3 minutes without help? If not, that's your starting point.

What Expo shipped in 2026: New performance tools and AI integrations

Dan — Tue, 23 Jun 2026 13:50:50 +0000

App.js 2026 just wrapped up in Kraków with over 500 React Native developers gathering for two days of ecosystem updates. We shared some major announcements, including our new production performance library and a year's worth of platform improvements.

Why React Native fits the AI development wave

AI changed who builds apps and how quickly they ship. React Native and Expo happened to be positioned well for this shift, thanks to decisions made years before anyone thought about prompting models to write code.

The foundation matters here. Building with JavaScript, TypeScript, and React gives AI models massive training datasets to work from. When a model generates Expo code, it's drawing from years of public React and TypeScript repos, not just a few examples.

Documentation plays a bigger role than you might expect. Over the past year, docs commits made up the largest portion of changes to the Expo repo. That documentation becomes training data, so better docs directly improve how well models write Expo apps.

Universal deployment helps too. When someone prompts an app builder ("make me an app that streams my radio station"), the model doesn't need platform-specific knowledge. It can default to Expo, build once, and target everything.

The community amplifies all of this. When you solve a React Native problem and write about it, both developers and models learn from your solution. This creates a compounding effect across the ecosystem.

What we're working on next

Agents need feedback loops. When an agent can run an app, interact with it, and verify it works correctly, it can debug and iterate independently. Tools like Argent from Software Mansion and Agent Device from Callstack that let agents screenshot, tap, and inspect running apps enable this workflow.

Speed remains important. Since writing code got faster for most developers, the bottleneck shifted to builds, distribution, and boot times. Much of our upcoming work targets making these parts as fast as possible.

We want the default path to produce good results. Tools like Expo Router should give you a polished, native-feeling app without extra configuration.

A year of major releases

Here's what shipped over the past twelve months:

TV app support extends universal apps to living rooms. You can share about 85% of your code between mobile, Apple TV, and Android TV.

Expo UI reached stability in Expo SDK 56 with a default template. It renders real SwiftUI and Jetpack Compose widgets from a single JavaScript API, letting you use OS primitives without writing native modules.

Expo Launch provides a web-based flow for getting apps to TestFlight, App Store, and web without manually writing config files.

The Expo MCP server connects agents to your project's SDK version, config, dev server, and cloud services. It's free for all Expo accounts. The simulator integration stands out: multimodal agents can screenshot and interact with running apps, pull React Native DevTools data, and debug build failures using TestFlight and crash reports.

Expo skills contains official skills for building, deploying, and debugging apps. It covers UI development, deployment, SDK upgrades, DOM components, and dev clients. With deep Expo Router integration, agents can generate native-feeling UIs in single attempts.

Expo widgets simplifies building home screen widgets and live activities on iOS without native code.

Expo Router v56 adds more native navigation primitives: native toolbars, link transitions, and platform-specific behaviors. The demo showed an accessory sliding into the tab bar on scroll, smooth shared element transitions, and a search bar that collapsed the tab bar while floating above the keyboard.

Expo SDK 56 focuses on performance

SDK 56 prioritizes speed improvements. Pre-compiled binaries accelerate builds, and Android cold start times dropped 40%. Hermes V1 is now default, along with numerous smaller optimizations.

The new starter app makes a bigger impact than expected. Fresh projects now open with a polished first screen, including clean entrance animations and built-in explore tab animations.

Starting from something that looks good changes how development feels from day one.

The expo.dev dashboard got a complete redesign with better organization and more data. EAS Workflows added prepackaged jobs: GitHub comment jobs that report builds and updates on PRs, Apple device registration jobs for ad hoc provisioning profiles, and approval jobs that add human checkpoints to workflows.

Introducing Observe for production performance

The biggest announcement was Observe, our new open source library for capturing real performance metrics from production apps.

Local development doesn't match user reality. You test on good Wi-Fi with a fast device. Users have every kind of device and network imaginable. Performance problems hide in that gap.

Observe tracks the complete user journey: from tapping your app icon to actually using it. It measures launch time, bundle load time, time to render, and time to interactive. Each measurement includes device metadata, app version, and location. Time-to-interactive metrics also capture device state: battery level, Wi-Fi status, and dropped frame counts. You can attach custom objects to track screen-specific data.

Per-screen metrics answer the most common developer questions. Mobile apps behave like SPAs, making it hard to identify slow screens. Since every Expo Router route has a URL, Observe can report metrics per page. After rebuilds, you see cold and warm time-to-render and time-to-interactive for each screen.

Version tracking gets clearer too. React Native apps have native layers and JavaScript bundles, making version identification tricky. Observe shows exactly which version each user is running. In a two-version example (1.0.0 and 1.0.1), you see installs and active users for each version.

Custom event tracking lets you capture any serializable data.

Reading the data uses AI assistance. Instead of scanning dashboards for problematic metrics, you can ask questions in plain text and let agents analyze the data. Observe ships with skills for installation and metric interpretation.

Expo Observe is in public beta, free for up to 10,000 monthly active users for at least three months. It will become a paid service after that. We want feedback while preparing for general availability.

More features are coming in future releases.

Building is getting more accessible

Seth Webster's closing talk, "It's a great time to be a builder," argued that one person with good judgment and the right tools can now create what used to require ten-person teams.

Many React developers once saw mobile development as requiring Objective-C or Java knowledge to ship real apps. React Native and Expo removed that barrier. If AI is opening similar doors for more developers, that's worth celebrating.

Check out the recorded talks from Software Mansion. The full two days feature some of the best people working in React Native. Thanks to Software Mansion and all sponsors who made the conference happen.

Now go build something! Join us in Portland at Chain React Conf.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Skip Recompiling 70+ iOS Packages on Every Build

Dan — Mon, 22 Jun 2026 13:55:58 +0000

React Native developers know the pain: every clean iOS build recompiles your entire dependency tree from scratch. React Native core, Expo modules, third-party libraries — everything rebuilds, every time.

Expo SDK 56 changes this by shipping Expo modules as precompiled XCFrameworks. Your app links these binaries directly instead of rebuilding from source. Clean builds become dramatically faster with zero configuration.

This also marks the start of a bigger shift: moving the entire ecosystem from CocoaPods to Swift Package Manager, Apple's modern dependency system.

What precompiled XCFrameworks do for you

Previously, every iOS build meant compiling these items from source:

React Native core
All Expo modules
Every third-party library with native code

SDK 56 distributes many Expo modules as precompiled XCFrameworks through npm. Your build process links these binaries instead of recompiling source code.

The results: fewer compilation steps, faster local development, faster EAS Builds, and more predictable build environments.

No migration needed. This works automatically in existing apps.

XCFrameworks explained: Apple's format for distributing precompiled native libraries. Instead of source code that every app compiles locally, you get binary artifacts already compiled for iOS devices, simulators, and multiple architectures. React Native already uses XCFrameworks internally — SDK 56 extends this to Expo modules.

Two problems this solves

This work addresses major long-term issues in React Native development.

CocoaPods is going away

React Native and most RN libraries currently depend on CocoaPods for dependency resolution, native autolinking, project integration, and build orchestration.

CocoaPods is Ruby-based legacy infrastructure. It becomes read-only in December 2026.

Swift Package Manager is Apple's standard tooling for native dependencies, builds, and package distribution. React Native itself has started moving toward SPM support, including distributing parts of RN as precompiled XCFrameworks.

SDK 56 continues this direction.

Native builds are expensive and slow

As apps grow, native build times increase. This hurts especially in CI environments, EAS Build, and large monorepos with many native dependencies.

Precompiled XCFrameworks move compilation work earlier in the pipeline. Frameworks get compiled once, packaged, then reused across builds. This eliminates repeated native compilation work.

Why this was technically difficult

React Native and Expo were originally built around CocoaPods and source-based compilation. That environment is permissive: headers are globally available, source files can import almost anything, pod targets have loose isolation.

XCFrameworks impose strict rules. Every framework must be fully modular, self-contained, and isolated from implementation details outside its module boundary.

Many assumptions that work in CocoaPods break when building distributable XCFrameworks.

Rewriting the native architecture from scratch wasn't realistic. We built incremental compatibility layers and new build infrastructure instead.

Build time improvements

These numbers come from an Apple M4 Max with 64 GB memory, running clean iOS builds of a stock Expo app while enabling each layer of precompiled XCFrameworks:

Build configuration	Reduction vs previous	Reduction vs from-source
Everything from source	—	—
+ React Native core	~44%	~44%
+ Expo modules prebuilt	~10%	~50%
+ Third-party libraries prebuilt	~30%	~65%

Larger projects see benefits based on coverage: React Native and Expo modules are always precompiled, but only widely-used third-party libraries are included. Projects using uncommon native dependencies will compile those from source and see smaller reductions.

Making Expo Modules Core work with SPM

The first step was adapting expo-modules-core. Nearly every Expo module depends on it, so it sits at the root of the dependency graph. If it can't build as a modular XCFramework, nothing else can.

This required solving several architectural problems.

Removing illegal header exports

Some Expo Modules Core public headers exposed React Native headers directly:

#import <React/RCTView.h>

This works in CocoaPods because all headers are globally available during compilation. Framework interfaces don't allow this.

A framework cannot publicly expose headers from another framework unless those dependencies are themselves modularized correctly.

We solved this by refactoring public interfaces, isolating React Native internals, and restructuring APIs so non-modular dependencies don't leak into exported interfaces.

Breaking Swift ↔ Objective-C cycles

Swift Package Manager is much stricter about mixed-language targets than CocoaPods.

Expo Modules Core had cyclic dependencies where Objective-C referenced Swift types while Swift referenced Objective-C types.

SPM requires clear dependency direction between targets. We introduced new interface abstractions, separated implementation layers, and refactored internal APIs.

In some cases, we used Objective-C runtime reflection to dynamically invoke Swift implementations without illegal compile-time dependencies.

Separating source trees for SPM

Swift Package Manager is strict about source ownership. The same source file cannot belong to multiple targets in the same package graph.

Expo's repository structure wasn't designed around this assumption. Rather than permanently reorganizing repositories, we generate temporary isolated source structures during builds using symlinks, generated folders, and build-time source separation.

This preserves the existing repository layout while satisfying SPM's isolation requirements.

React Native and Virtual File System overlays

Another challenge was React Native's header structure.

React Native's current XCFramework support still depends on the legacy CocoaPods-generated header layout. That layout doesn't naturally exist in Swift Package Manager builds.

To bridge this gap, we added support for Clang Virtual File System (VFS) overlays inside React Native.

A VFS overlay lets the compiler "see" a virtual header layout different from the physical filesystem structure.

This allows us to preserve existing include paths, avoid massive source refactors, and present a modular structure to the compiler without physically reorganizing React Native's source tree.

This is common when modernizing large legacy native codebases into distributable modular frameworks.

Auto-generating Package.swift files

Swift Package Manager uses Package.swift manifests to define targets, dependencies, platforms, and build settings. Maintaining these manually across Expo packages would become difficult and error-prone.

We added new tooling to expo-tools that automatically generates Package.swift manifests, isolated source structures, dependency graphs, and XCFramework packaging steps.

This infrastructure runs fully in CI and will eventually power large-scale precompiled package distribution.

Supporting both CocoaPods and SPM

This transition takes time.

The React Native ecosystem still depends heavily on CocoaPods, and many libraries aren't yet compatible with Swift Package Manager. SDK 56 focuses on coexistence rather than replacement.

Expo modules can switch between building from source or consuming precompiled XCFrameworks.

This lets existing apps continue working while keeping CocoaPods supported as the ecosystem gradually modernizes.

If needed, precompiled modules can be disabled:

EXPO_USE_PRECOMPILED_MODULES=0

Long-term, we expect more of Expo's autolinking, native integration, and build tooling to move into Swift Package Manager itself.

Part of broader modernization

Precompiled XCFrameworks are part of broader modernization in Expo SDK 56, which also introduces inline native modules, continued React Native modernization work, and infrastructure improvements for future native tooling.

Together, these changes move Expo toward faster native builds, cleaner modular architecture, and deeper integration with Apple's modern development ecosystem.

What's next

Our current focus is stabilizing compatibility, expanding package coverage, validating build performance improvements, and continuing upstream collaboration with React Native.

This is one of the largest infrastructure migrations we've undertaken on the iOS side of Expo. But it opens up a much more scalable future for React Native development on Apple platforms: faster builds, better tooling, cleaner native boundaries, and eventually a world without CocoaPods.

SDK 56 is the beginning of that transition.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Native UI Components from One Import: Expo UI is Production-Ready

Dan — Fri, 19 Jun 2026 13:41:05 +0000

With SDK 56, @expo/ui gives you real SwiftUI and Jetpack Compose components in React Native. No JavaScript reimplementations, no platform-specific code splitting. Just import once and get native components that follow platform conventions.

Universal components in Expo UI, across Android, iOS and web.

The library is bundled into Expo Go and included in the default [create-expo-app](https://docs.expo.dev/more/create-expo/) template. You can start using it immediately in any new project.

This release caps three SDK cycles of development:

SDK 53 — basic SwiftUI and Jetpack Compose components
SDK 54 — [<Host>](https://expo.dev/blog/liquid-glass-app-with-expo-ui-and-swiftui), modifiers, and container views like [Form](https://expo.dev/blog/liquid-glass-app-with-expo-ui-and-swiftui) and [List](https://expo.dev/blog/liquid-glass-app-with-expo-ui-and-swiftui). The hot-chocolate demo showed you could build complete apps with it.
SDK 55 — Jetpack Compose support in beta, plus API alignment with Apple's SwiftUI documentation
SDK 56 — Compose API audit, universal layer, and drop-in replacements for popular community packages

Here's what each piece looks like in practice.

Universal components: write once, run natively everywhere

The universal layer is the biggest change in SDK 56. Instead of importing from platform-specific packages like @expo/ui/swift-ui or @expo/ui/jetpack-compose, you import from @expo/ui and get the right implementation automatically:

import { Host, FieldGroup, Row, Switch, Slider, Text, Spacer } from '@expo/ui';

Each universal component is a thin wrapper that renders the SwiftUI version on iOS and the Compose version on Android. No JavaScript fallback layer means you're always using the actual platform component. The universal layer covers layout primitives, text, inputs, controls, and sheets: Host, Row, Column, ScrollView, and more. Learn more about universal components.

The naming leans toward React Native conventions. You write Switch instead of Toggle, and Column/Row instead of HStack/VStack. The SwiftUI-style names are still available under @expo/ui/swift-ui when you need them.

Building a settings screen with universal components

FieldGroup is the universal equivalent of SwiftUI's Form. It creates grouped, sectioned lists with section titles, footers, and platform-appropriate styling on iOS and Android. The component uses compound patterns like FieldGroup.Section and FieldGroup.SectionFooter:

import { useState } from 'react';
import { Button, FieldGroup, Host, Row, Slider, Spacer, Switch, Text } from '@expo/ui';

export default function SettingsScreen() {
  const [notifications, setNotifications] = useState(true);
  const [sounds, setSounds] = useState(false);
  const [brightness, setBrightness] = useState(0.6);

  return (
    <Host style={{ flex: 1 }}>
      <FieldGroup>
        <FieldGroup.Section title="Notifications">
          <LabeledRow label="Push notifications">
            <Switch value={notifications} onValueChange={setNotifications} />
          </LabeledRow>
          <LabeledRow label="Sounds">
            <Switch value={sounds} onValueChange={setSounds} />
          </LabeledRow>
          <FieldGroup.SectionFooter>
            <Text textStyle={{ fontSize: 13, color: '#6c6c70' }}>
              Notification previews can expose sensitive content on the lock screen.
            </Text>
          </FieldGroup.SectionFooter>
        </FieldGroup.Section>

        <FieldGroup.Section title="Display">
          <LabeledRow label="Brightness">
            <Slider value={brightness} onValueChange={setBrightness} />
          </LabeledRow>
        </FieldGroup.Section>

        <FieldGroup.Section>
          <Row alignment="center" style={{ padding: 12 }}>
            <Spacer flexible />
            <Button variant="outlined" onPress={() => alert('Signed out')} label="Sign out" />
            <Spacer flexible />
          </Row>
        </FieldGroup.Section>
      </FieldGroup>
    </Host>
  );
}

function LabeledRow({ label, children }: { label: string; children: React.ReactNode }) {
  return (
    <Row alignment="center" spacing={16}>
      <Text>{label}</Text>
      <Spacer flexible />
      {children}
    </Row>
  );
}

This single code snippet produces a SwiftUI Form with inset-grouped sections on iOS and a Material 3 grouped list on Android. The Switch and Slider components automatically become system controls on iOS and Material components on Android. No platform-specific files needed.

You can still reach for @expo/ui/swift-ui and @expo/ui/jetpack-compose when you need platform-specific features like SwiftUI's glassEffect() or Compose's DockedSearchBar. Mix them freely within the same Host.

Notes on the universal layer:

This is version one. Some universal components work well across all platforms, others don't because SwiftUI, Compose, and web don't always offer equivalent primitives. Let us know which components work, which don't, which are missing, and where you use the platform-specific packages directly.
Web is experimental. Universal components have web implementations but they're not production-quality yet. Expect improvements in upcoming releases based on your feedback.

Stable APIs and new capabilities

Both the SwiftUI and Compose APIs now match their platform documentation. Most code samples you find online (Apple docs, Google docs, blog posts) are one search-and-replace away from working in Expo UI. Component names, prop names, modifier names all match.

SwiftUI's Toggle and Form keep their names in @expo/ui/swift-ui. Compose's LazyColumn keeps its name in @expo/ui/jetpack-compose. Props and modifiers follow the same pattern.

SDK 56 includes new features alongside the API stabilization:

Build your own components. SwiftUI and Jetpack Compose have hundreds of views and modifiers. To bridge that gap, you can now create your own SwiftUI and Jetpack Compose views and modifiers while Expo UI handles the layout, props, and events. Learn more for SwiftUI and Jetpack Compose.
Material 3 Dynamic Colors. [useMaterialColors](https://docs.expo.dev/versions/v56.0.0/sdk/ui/jetpack-compose/colors/) gives you Material 3 Dynamic Colors that adapt to the system theme.
Full Material Symbols access. The [Icon](https://docs.expo.dev/versions/v56.0.0/sdk/ui/jetpack-compose/icon/) component works with [@expo/material-symbols](https://www.npmjs.com/package/@expo/material-symbols) to make the entire Material Symbols catalog importable.
UI thread state management. useNativeState for SwiftUI and Jetpack Compose lets you build smooth, UI-thread-driven controls without flicker. We'll cover this in a dedicated post soon.

Replace community packages with native alternatives

Most React Native apps install similar community packages for platform primitives like pickers and sliders. Each adds a native dependency with its own release schedule and potential SDK compatibility issues. SDK 56 ships native replacements for seven common packages under @expo/ui/community:

Community package	Drop-in replacement
@react-native-community/datetimepicker	@expo/ui/community/datetime-picker
@react-native-community/slider	@expo/ui/community/slider
react-native-pager-view	@expo/ui/community/pager-view
@react-native-picker/picker	@expo/ui/community/picker
@react-native-segmented-control/segmented-control	@expo/ui/community/segmented-control
@react-native-masked-view/masked-view	@expo/ui/community/masked-view
@react-native-menu/menu	@expo/ui/community/menu
@gorhom/bottom-sheet	@expo/ui/community/bottom-sheet

Most migrations are simple import swaps. Some props differ because Expo UI uses SwiftUI and Jetpack Compose instead of UIKit and Android Views:

// Before
import DateTimePicker from '@react-native-community/datetimepicker';

// After
import DateTimePicker from '@expo/ui/community/datetime-picker';

Learn more about drop-in replacements.

The result: fewer dependencies, one upgrade path, consistent foundation.

Choose the right tool for each use case

Expo UI isn't a UI component library or design system. Like writing <div> and <span> in react-dom, you write Column and Row in @expo/ui. It exposes the primitives iOS and Android already provide as React components.

But you don't have to use Expo UI everywhere. The Expo framework lets you mix different approaches within the same app:

For custom designs — brand pages, bespoke design systems, anything highly styled — use React Native **View**** / `Text**`. These styling-agnostic primitives work with CSS-style props, flexbox layout, and styling libraries like NativeWind.
For native-feeling UI — settings screens, modals, pickers, sheets, anything users expect to "look like the OS" — use Expo UI. Inside a Host, layout uses SwiftUI/Compose primitives (HStack/VStack, Row/Column) instead of Yoga flexbox.
For custom graphics — charts, shaders, complex animations — use react-native-skia.
For 3D and GPU work — use react-native-webgpu and TypeGPU.
For web ecosystem solutions (like shadcn) — use DOM components to run web code in webviews on native and directly on web.

These tools compose at the component level. You can mix React Native, Expo UI, Skia, WebGPU/TypeGPU, and DOM components in the same screen and view tree. Build experiences that are both universal and deeply platform-native.

Updated demo apps

We've updated hot-chocolate to SDK 56. The app started as SwiftUI-only but now uses universal components and runs on Android and web too.

Apple TV and Android TV support

Expo UI now works on Apple TV and Android TV, thanks largely to Douglas Lowder. Most components and APIs work on TV platforms, though some native SwiftUI and Compose APIs aren't available on TV. The ExpoUITV app demonstrates supported APIs on both TV and mobile.

Community contributions

Expo UI reached stability because of community involvement. SDK 56 was unusually community-driven. You filed issues, audited APIs, added components, and fixed crashes before we found them. Special thanks to:

2hwayoung, AKSHAY JADHAV, Axel, Benjamin Komen, Beto, Christian Wooldridge, Dennis Morello, Dylan, Eliot Gevers, fedeciancaglini, Gregory Moskaliuk, Hugo Extrat, hypnokermit, Ian Berry, Isaiah Hamilton, JeroenG, Joss Mackison, K.Dileepa Thushan Peiris, Kfir Fitousi, kimchi-developer, Leonardo E. Dominguez, Liès, Loic CHOLLIER, Louis, lucabc2000, Petr Chalupa, Pflaumenbaum, Ray, Sam Shubham, Shubh Porwal, starsky-nev, Suvesh Moza, Terijaki, ThiMal, Yousof Abouhalawa, Zhovtonizhko Dmitriy

Thanks to everyone who tested, filed issues, joined office hours, or participated in Discord discussions. Your feedback shaped this release as much as the code contributions.

Getting started

npx create-expo-app@latest --template default@sdk-56 — Expo UI comes with the default template, so Host, Switch, and Picker are ready to import.
If you have any packages from the drop-in table, try swapping one import to test the replacement.
Check out the demo apps: hot-chocolate and ExpoUITV.
Report issues, send PRs, chat with us in Discord. Stable means the foundation is solid for the next phase of building.

Expo UI is stable and ready for production. Time to build something native.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Kotlin Compiler Plugin Cuts Android Startup Time by 30% in Expo SDK 56

Dan — Thu, 18 Jun 2026 18:37:38 +0000

Expo SDK 56 ships with a custom Kotlin compiler plugin that eliminates reflection from Expo Modules on Android. The result: 70% faster module initialization and a 30% reduction in time to first render.

The plugin runs during compilation, so app developers get these performance gains automatically without changing any code. Module authors can unlock even bigger wins with a single annotation.

This post walks through how we built it and why this approach succeeded where previous attempts failed. For the Swift side where we now talk to JSI directly, check out our companion post Talking to JSI in Swift.

The reflection problem we inherited

Before Expo Modules, we had Unimodules. They worked like old React Native bridge modules: you'd sprinkle annotations across methods you wanted to expose, and the runtime would discover everything through reflection.

class ClipboardModule(context: Context) : ExportedModule(context) {
  override fun getName() = "ExpoClipboard"

  @ExpoMethod
  fun getStringAsync(promise: Promise) {
    val clip = clipboardManager.primaryClip?.getItemAt(0)
    promise.resolve(clip?.text?.toString() ?: "")
  }

  @ExpoMethod
  fun setStringAsync(content: String, promise: Promise) {
    clipboardManager.setPrimaryClip(ClipData.newPlainText(null, content))
    promise.resolve(true)
  }
}

Reflection made sense when we needed metadata about our own code. What methods does this module export? What arguments do they accept? The JVM could answer those questions. But reflection costs time, and on Android that time comes straight out of your startup budget. Every module the runtime introspects adds milliseconds before users see your app.

Building the Expo Modules API gave us a chance to fix this. We wanted better ergonomics and less reflection. The Kotlin DSL delivered both in one move, removing most reflection while making modules easier to write. But we couldn't eliminate all of it. Type information for function arguments and Record properties still required runtime reflection calls like typeOf<T>() and the metadata parsing that comes with them.

Where reflection actually hurts

The remaining cost shows up in two places. First, reconstructing type parameters. Our DSL reads argument and return types through typeOf<T>(), which works because T is reified. The JVM normally erases generics at runtime, so you can't ask what T actually was. Reified type parameters work around this limitation. The compiler inlines the function and substitutes the real type directly. Getting type information this way is usually cheap, but costs add up when modules have many functions or deeply nested generics.

The second cost is heavier: Record conversion. A Record represents a typed JS object on the native side. Converting one means discovering its shape at runtime: which properties it declares, which ones are exposed to JS, and what type each property has.

This discovery process is expensive because it involves multiple layers of reflection. You ask the JVM for the class's memberProperties, then ask each property for its annotations and type, then make the field accessible for writing. Some of that information isn't even directly available in bytecode. The JVM knows about classes and members, but nothing about Kotlin's type system. The Kotlin reflection library has to reconstruct that by parsing the @Metadata annotation, which contains a binary blob the compiler generates.

We could sidestep some of this work. Top-level nullability doesn't need full reflection with a reified T, a simple null is T check answers it. But nested cases like the T in List<T> are different. The JVM erases generics, so type arguments disappear from bytecode at runtime. It has no concept of Kotlin nullability either. The only place that information survives is the @Metadata annotation, and there's no shortcut to reading it. You have to parse that metadata, which is exactly the cost we were trying to avoid.

Why we skipped code generation

The standard solution for this problem is code generation. Both Java and Kotlin have established tools for it. Annotation processors (kapt) and the Kotlin Symbol Processing API (KSP) run at build time and emit source files that pre-compute type metadata, so you never touch reflection at runtime. We also looked at standalone codegen tools that run before compilation, like React Native's TurboModule generator.

We tested this approach and didn't like what we found. Generated code becomes part of your project. It appears in call stacks, you step through it in the debugger, and when something breaks in the JS-to-native bridge, you're reading machine output that's painful to debug. Also, kapt and KSP can only add new files, never modify existing ones. Instead of augmenting a Record class in place, you'd generate a parallel class from scratch. Standalone tools just swap those problems for others: another build step, more toolchain integration, more maintenance overhead.

We were stuck for a while. We lived with the reflection cost and watched for better options.

What K2 changed

Kotlin 2.0 shipped with the new K2 compiler and changed what was possible. The add-only limitation of kapt and KSP is exactly what K2 removes. The new compiler plugin API gives you access to the intermediate representation (IR) the compiler produces. You're editing code as the compiler sees it, before it becomes bytecode. If you produce invalid code, the compiler catches it. You can write tests against the transformed IR. Unlike codegen, the result isn't a parallel layer of code you have to maintain. It's small, surgical changes in well-defined places.

We always knew we could modify bytecode directly, but we didn't want to maintain that. Too fragile, too easy to produce something that only breaks at runtime on specific Android versions. The compiler plugin API gives the same power with actual safety guarantees.

How the plugin works

The plugin's approach is simple: everything reflection discovers at runtime, the compiler already knew at build time. Built on the K2 API, the plugin targets the two most expensive operations we described:

1. Pre-computed type descriptors

When an Expo Module needs type information, it calls typeDescriptorOf<T>(). The function itself is a stub that throws if it ever runs:

fun <T> typeDescriptorOf(): PTypeDescriptor =
  throw NotImplementedError(
    "typeDescriptorOf<T>() should be replaced by the compiler plugin"
  )

It exists so code compiles, but should never execute. During compilation, the plugin intercepts every call to typeDescriptorOf<T>() and replaces it with a direct reference to a pre-computed type descriptor object:

// What you write:
typeDescriptorOf<List<Int>>()

// The equivalent of what the compiler emits:
PTypeDescriptorRegistry.getOrCreateParameterized(
  List::class.java,
  isNullable = false,
  parameters = arrayOf(
    PTypeDescriptorRegistry.getOrCreateConcrete(
      Int::class.java, 
      isNullable = false
    )
  )
)

Think of typeDescriptorOf<T>() as our own, leaner version of typeOf<T>(). Both return objects that describe types, but where typeOf returns a full KType, ours returns a PTypeDescriptor (P for Pika, the plugin's internal codename) that carries only what we actually use: a Class<?> reference, a nullability flag, and a list of parameter descriptors. No dependency on the Kotlin reflection library.

The lean shape also reduces allocation. For simple types like String or Int, the registry returns pre-allocated static fields, so there's no allocation. For parameterized generics, descriptors are cached and deduplicated across modules, so the cost is paid once. In JVM microbenchmarks, building descriptors this way runs roughly 2x faster than typeOf for complex types like Map<String, List<Int?>>.

2. Pre-computed Record metadata

The fix for reflection-heavy conversion is a single annotation. Mark a Record with @OptimizedRecord and the plugin takes over:

@OptimizedRecord
class UserRecord : Record {
  @Field val name: String = ""
  @Field val age: Int = 0
  @Field val address: AddressRecord? = null
}

That annotation is the opt-in. For any class marked with @OptimizedRecord, the plugin does at compile time exactly what SDK 55 did at startup: reads property names, types, and annotations and bakes them into bytecode as plain objects, paired with direct accessors that use simple index-based dispatch. Setting a field goes from "make it accessible via reflection, then set it" to a plain assignment.

If compiled metadata is present, the runtime takes the fast path. If not (annotation was omitted or plugin didn't run), it falls back to the same reflection-based conversion from SDK 55. Either way, your module keeps working.

Records aren't the only beneficiary. Jetpack Compose props marked with @OptimizedComposeProps get the same treatment, applied to prop resolution instead of field conversion. This matters because prop resolution was a major bottleneck for packages like expo-ui that use Android's declarative UI heavily.

Performance results

Performance gains depend on how many Expo Modules your app uses and what types they export. We measured cold starts of a module-heavy test app (all official Expo modules plus popular third-party TurboModules) on two devices: a OnePlus 9 Pro and an older Samsung Galaxy S9.

The results:

Android module initialization: ~70% faster
Time to first render: ~30% improvement
Record conversion: ~6x faster

Raw cold-start numbers from our module-heavy test app (clean mean over 150 iterations, outliers removed):

Metric	SDK 55	SDK 56	Change
Cold launch (Activity.onCreate)	93 ms	55 ms	-41%
Time to first render	797 ms	508 ms	-36%
First animation frame	808 ms	520 ms	-36%

What you need to do

App developers: nothing. The compiler plugin runs automatically in SDK 56. The typeDescriptorOf replacement applies to all types without code changes.

Module maintainers who use Records can opt into faster conversion with @OptimizedRecord:

@OptimizedRecord
class MyConfig : Record {
  @Field val apiUrl: String = ""
  @Field val timeout: Int = 30
}

If you use props with our Compose integration, annotate with @OptimizedComposeProps:

@OptimizedComposeProps
data class MyViewProps(
  val title: MutableState<String> = mutableStateOf(""),
  val count: MutableState<Int> = mutableIntStateOf(0)
) : ComposeProps

Skipping these annotations doesn't break anything. Modules fall back to the same reflection-based conversion from SDK 55. You just miss out on the 6x speedup for Records.

Looking ahead

This isn't the finish line. The compiler plugin currently handles type metadata and Record conversion, but the same approach can extend to other parts of the module lifecycle, like function dispatch. We're also investing in the plugin itself, making it more capable and easier to maintain, so we can expand its scope without expanding maintenance costs. The goal remains the same: keep the ergonomic APIs module authors write today while pushing more work to compile time.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Why You Should Drop @expo/vector-icons for React Native Vector Icons

Dan — Wed, 17 Jun 2026 20:19:00 +0000

Switching from @expo/vector-icons to React Native's official icon packages can cut your bundle size by 4MB or more. Here's how to make the change and why Expo now recommends it.

If you've built React Native apps with Expo, you've probably used @expo/vector-icons. It's been the go-to solution for icons, but that's changing. Expo now recommends switching to the official @react-native-vector-icons packages, and for good reason.

The Problem with @expo/vector-icons

When Expo first created @expo/vector-icons, it solved a real problem. The original react-native-vector-icons didn't work well with Expo projects, especially in Expo Go or with over-the-air updates. So Expo built a wrapper that used expo-font to load icon fonts dynamically.

But this solution came with baggage. To support libraries that expected react-native-vector-icons, Expo had to alias it to @expo/vector-icons using Babel transforms. This created complexity and maintenance overhead.

More importantly, maintaining icon font packages isn't what Expo does best. They focus on platform-level capabilities, not wrapping third-party icon sets.

The New Approach Works Better

The latest @react-native-vector-icons packages (different from the old deprecated react-native-vector-icons package) now integrate directly with expo-font. They call the native font loading API when needed, so they work everywhere: Expo Go, development builds, and production apps.

Since these packages handle Expo integration natively, there's no need for Expo's wrapper anymore. Expo plans to deprecate @expo/vector-icons in a future SDK release.

What You Get from Migrating

Smaller bundles: Apps often accidentally bundle all icon fonts, even when they only use one or two sets. Our test app shrank by 4MB just by changing imports and dependencies.

Latest icon sets: Access to newer versions and icon sets that weren't available in @expo/vector-icons, like Lucide.

Better tooling: You can now type-check icon names when using createIconSetFromFontello or createIconSetFromIcoMoon. Creating custom icon sets is easier with the generator.

Cleaner setup: No more aliasing configuration or version drift between packages.

Making the Switch

Expo provides a codemod that handles most of the migration automatically:

Run npx @react-native-vector-icons/codemod in your project root. Check the changes it makes before committing.

Verify the migration worked by running npx expo doctor. This checks that old packages aren't lingering in your project.

Make sure expo-font is installed and configured properly. Don't add font paths from node_modules/@react-native-vector-icons/ to the expo-font config plugin—this will break your build.

If you use custom fonts, double-check any icons created with createIconSetFromIcoMoon or similar helpers.

Watch Out for These Issues

Font conflicts: If your project mixes old and new icon packages, you might see icons render as ? or empty squares. The expo doctor command warns about these conflicts.

Dependency confusion: Some libraries might still expect the old package names. Most should work fine, but check your dependencies if you see unexpected behavior.

About 60% of apps on EAS Build currently use @expo/vector-icons, so Expo knows this affects many projects. That's why they built the codemod and will maintain the old package during the transition period.

The Migration is Worth It

This change reduces complexity in your project and can significantly shrink your bundle size. It's part of Expo's broader effort to simplify the ecosystem while improving performance.

The new packages give you direct access to the latest icon sets and better development tools. Plus, you're future-proofing your app since Expo will eventually deprecate the old wrapper.

If you run into problems during migration, Expo wants to hear about them. The smoother this transition goes, the better it is for the entire React Native ecosystem.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Expo's MCP Server is Now Free - Connect Your AI Assistant to Expo Projects

Dan — Thu, 11 Jun 2026 13:34:29 +0000

The Expo MCP Server dropped its paywall. Anyone with an Expo account can now hook up their AI coding assistant to Expo docs and tools.

Previously, you needed a paid plan to use MCP (Model Context Protocol) with Expo. That barrier is gone. Free accounts now include monthly MCP usage for individual development and prototyping.

How developers use Expo MCP

MCP is an open standard that connects AI assistants to external tools and project context. We built the Expo MCP Server to give your assistant direct access to Expo's ecosystem. Here's how teams are using it:

Getting Expo answers without tab-switching. Your assistant pulls official documentation and SDK guidance while you're deep in code. No more breaking focus to search docs.

Debugging builds from chat. The assistant can inspect EAS build status, check workflow runs, parse logs, and even pull in TestFlight crash reports or user feedback.

Testing apps through conversation. Point it at your local dev server and simulator. It takes screenshots, navigates flows, inspects UI elements, and grabs console logs.

This workflow was detailed in Become an AI-native developer with the Expo MCP Server. Now it's available to everyone.

Free plan limits and usage

Free accounts get monthly MCP usage designed for individual developers, evaluation projects, and occasional Expo-specific help. Usage counts at the billing account level.

If you're on a team account, all members share the same monthly allowance. Hit the limit and MCP requests fail with an error until the next billing cycle.

Paid plans include higher usage limits. They also get early access to new MCP features before they roll out to free accounts.

Setting it up

The MCP docs walk through connecting your AI assistant to Expo. MCP handles the technical connection. Expo Skills provide the Expo-specific knowledge your assistant needs for building, deploying, and debugging.

What's next

We're curious about your MCP use cases. Checking release readiness? Monitoring update rollouts? Turning build failures into actionable fixes? Let us know in Discord or on X.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Expo Router v56 Ships SSR and Breaks Free from React Navigation

Dan — Wed, 10 Jun 2026 13:15:36 +0000

Expo Router just made its biggest change since launch. Version 56 forks from React Navigation, adds streaming server-side rendering, and gives Android developers the toolbar API they've been waiting for.

The fork is the big story here, affecting every Expo Router app. But there's more: new SSR capabilities, an Android toolbar that matches iOS, and expanded Native Tabs. Let's break down what changed and why it matters.

The React Navigation fork explained

Expo has deep roots with React Navigation. Brent Vatne, Expo's VP of Engineering, led React Navigation through versions 1.0 and 2.0 alongside @ericvicenti and @satya164. We helped React Navigation grow from an early experiment, influenced by React Native's NavigationExperimental and our own ex-navigation, into the standard navigation solution for React Native.

React Navigation remains in Satya's capable hands while our focus shifted to Expo Router. As Expo Router evolved, we needed deeper control over React Navigation's internals. After talking with Satya, we agreed that forking the pieces Expo Router depends on would serve both projects better.

This isn't about abandoning React Navigation. It's about giving each project room to grow in different directions.

For Expo Router, the fork opens space for changes specific to file-based routing, web features, and server rendering. Some improvements we want to make wouldn't help React Navigation users directly, and pushing those changes upstream would add unnecessary complexity.

We can now create a focused version of React Navigation's internals that works specifically for Expo Router. This lets us simplify integration, reduce workaround code, and make maintenance easier.

There's also a practical benefit: dependency versioning. Projects sometimes ended up with multiple React Navigation versions installed, causing conflicts. Forking the internal pieces gives us better control over compatibility and makes releases more predictable.

Expo Router's web capabilities like data loaders and server-side rendering need changes that are easier to make in a codebase built specifically for these features.

How the fork affects your code

Since Expo Router no longer depends on React Navigation, you can't import code directly from @react-navigation/* packages. We know this breaks existing code, so we built tools to help with migration.

Use our codemod to migrate all React Navigation imports to expo-router/react-navigation:

Our migration guide walks through manual migration steps. To ease the transition, imports of @react-navigation/core from libraries will automatically redirect to expo-router/react-navigation for at least one release cycle.

If you run into problems, let us know.

What's next for both projects

We're working with the React Navigation team on a shared API for library authors who need to support both libraries.

If you maintain a library that should work with both Expo Router and React Navigation, reach out. We'd like to collaborate on adapting it to the new APIs.

Custom Suspense fallbacks

You can now customize the Suspense fallback for routes within a _layout. Export a [SuspenseFallback](https://docs.expo.dev/router/error-handling/#loading-states-with-suspense-fallback) to customize the loading screen:

import { ActivityIndicator, View } from 'react-native';
import { Stack } from 'expo-router';

export function SuspenseFallback() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <ActivityIndicator size="large" />
    </View>
  );
}

export default function Layout() {
  return <Stack />;
}

Streaming SSR arrives

Expo Router already supported API routes, middleware, data loaders, and static rendering. Version 56 adds streaming server-side rendering, which improves perceived performance by letting you prioritize important UI elements over slower, data-dependent components.

Enable it by setting unstable_useServerRendering to true in your Expo Router config.

Streaming SSR includes a new way to generate HTML metadata using a generateMetadata function.

We also added helper utilities for type-safe data loaders: [createStaticLoader](https://docs.expo.dev/versions/latest/sdk/server/#createstaticloaderfn) and [createServerLoader](https://docs.expo.dev/versions/latest/sdk/server/#createserverloaderfn).

Android gets the toolbar

SDK 55 brought toolbar support to iOS. Version 56 adds the same feature to Android, achieving cross-platform compatibility. Like iOS, you can place the Android toolbar in three positions: left, right, and bottom.

See all available options in the toolbar documentation.

Native Tabs expansion

Last fall, in Router v6 (we changed our Router naming convention since then), we added Native Tabs support. We're working toward full cross-platform support and plan to mark the API as stable in the next release.

Expo Router v56 adds new options to Native Tabs. The most requested feature was preventing tab selection. You can now use the disabled property to show a tab in the tab bar while preventing user interaction.

Check all available options and platform support in the Native Tabs reference page.

Getting started with v56

Three key takeaways from this release:

The React Navigation fork requires a one-time import update for every Expo Router app. Our codemod and compatibility layer make migration straightforward.

Streaming SSR, generateMetadata, and new loader helpers improve web experiences with Expo Router.

Android now has toolbar support and expanded Native Tabs, matching iOS feature parity.

For existing apps, start with the migration guide and run the codemod. New projects get all these features by default in SDK 56.

Find us on Discord and GitHub. We want to hear what you build and when something breaks.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Write Swift and Kotlin directly in your React Native app with Expo SDK 56

Dan — Tue, 09 Jun 2026 13:19:36 +0000

Working with native code in React Native usually involves creating separate packages and manually maintaining TypeScript interfaces. Expo SDK 56 changes this by letting you write Swift and Kotlin files right alongside your React components and automatically generating the TypeScript types for you.

Writing Expo modules traditionally meant dealing with package boilerplate and keeping multiple interfaces in sync. You'd create a module as a standalone package, then manually maintain TypeScript interfaces that matched your native Swift and Kotlin code. This workflow worked but added friction.

SDK 56 introduces inline modules and the expo-type-information package to remove these pain points. You can now write native modules directly in your project structure and generate matching TypeScript types automatically.

Writing native code next to your components

Inline modules let you place Swift and Kotlin files anywhere in your project structure. Need a custom native view? Create NativeView.kt and NativeView.swift files right next to your App.tsx and write your view there.

Setting up inline modules is simple. In your app configuration file, specify watchedDirectories - the directories containing your inline modules. After running npx expo prebuild to sync the native projects, you're ready to go.

{
  "expo": {
    "experiments": {
      "inlineModules": {
        "watchedDirectories": ["app"]
      }
    }
  }
}

With "app" in your watchedDirectories, you can create Swift and Kotlin files anywhere within the app directory or its subdirectories. Open app/nested/InlineModule.swift and write your Expo module:

internal import ExpoModulesCore

class InlineModule: Module {
  public func definition() -> ModuleDefinition {
    Constant("Hello") {
      return "Hello iOS inline modules!"
    }
  }
}

Once written, access it from JavaScript using requireNativeModule('InlineModule'). For views, use requireNativeView('InlineModule').

Automatic TypeScript type generation

The expo-type-information package parses your Swift modules and generates matching TypeScript types automatically. This eliminates the manual work of maintaining type interfaces.

The package includes a CLI tool with commands designed for inline modules.

The inline-modules-interface command finds all Swift inline modules in your project and generates two TypeScript files for each one. After running the command, you'll see these files appear next to your Swift file:

The Generated File ([ModuleName].generated.ts) contains all type information about the module, including function declarations, constants, classes, and views. This file gets overwritten every time you run the command.

// InlineModule.generated.ts
/*Automatically generated by expo-type-information.*/

import { ViewProps } from 'react-native';

import { NativeModule } from 'expo';

export declare class InlineModuleNativeModuleType extends NativeModule {
  readonly Hello: string;
}

The Stable File ([ModuleName].tsx) re-exports the module interface and provides a default export for the main view if one exists. You can edit this file and it won't be overwritten.

// InlineModule.tsx
// File hash: 8dfc86f5416afbe08cc1ee581c850fc9cec446479211d85501d9a5e2d24cc534
import { InlineModuleNativeModuleType } from './InlineModule.generated';

import { requireNativeModule, requireNativeView } from 'expo';

const InlineModule: InlineModuleNativeModuleType =
  requireNativeModule<InlineModuleNativeModuleType>('InlineModule');

export const Hello: string = InlineModule.Hello;

This split lets you tweak imperfect generated output while still allowing core declarations to be regenerated when you update the native side.

Current limitations

File naming requires that an inline module's name exactly matches its file name. Module names must be globally unique since the name identifies the module in the global object. You can't have both app/InlineView.swift and src/InlineView.swift in the same project.

Type generation currently only works for Swift modules and on macOS.

When types can't be resolved

Sometimes the tool can't resolve types of native module declarations. This happens because of SourceKitten limitations and our decision to parse only provided files instead of doing full compilation. When we can't resolve a Swift type, we generate an unknown type in TypeScript.

Common scenarios include nested declarations where SourceKitten has trouble with deeply nested closures, making it hard to find types inside a Class. Consider this ExpoBlob module:

// ExpoBlob.swift
import Foundation
import ExpoModulesCore

public class ExpoBlob: Module {
  public func definition() -> ModuleDefinition {
    Name("ExpoBlob")

    Class(Blob.self) {
      Constructor { (blobParts: [EitherOfThree<String, Blob, TypedArray>]?, options: BlobOptions?) in
        let endings = options?.endings ?? .transparent
        let blobPartsProcessed = processBlobParts(blobParts, endings: endings)
        return Blob(blobParts: blobPartsProcessed, options: options ?? BlobOptions())
      }

      Property("size") { (blob: Blob) in
        blob.size
      }

      Property("type") { (blob: Blob) in
        blob.type
      }

      Function("slice") { (blob: Blob, start: Int?, end: Int?, contentType: String?) in
        let blobSize = blob.size
        let safeStart = start ?? 0
        let safeEnd = end ?? blobSize

        let relativeStart = safeStart < 0 ? max(blobSize + safeStart, 0) : min(safeStart, blobSize)
        let relativeEnd = safeEnd < 0 ? max(blobSize + safeEnd, 0) : min(safeEnd, blobSize)

        return blob.slice(start: relativeStart, end: relativeEnd, contentType: contentType ?? "")
      }

      AsyncFunction("text") { (blob: Blob) async -> String in
        await blob.text()
      }

      AsyncFunction("bytes") { (blob: Blob) async -> Data in
        let bytes = await blob.bytes()
        return Data(bytes)
      }
    }
  }
}

// ExpoBlob.generated.ts
/*Automatically generated by expo-type-information.*/

import { ViewProps } from 'react-native';

import { NativeModule } from 'expo';

// These types haven't been defined in provided file(s).
export type Data = unknown;
export type TypedArray = unknown;

export type BlobOptions = {
  type: string;
  endings: EndingType;
};

export enum EndingType {
  transparent = 'transparent',
  native = 'native'
}
export enum BlobPart {
  string = 'string',
  blob = 'blob',
  data = 'data'
}

export declare class Blob {
  slice(
    blob: Blob,
    start: number | undefined,
    end: number | undefined,
    contentType: string | undefined
  ): unknown /*The type couldn't be resolved automatically.*/;
  text(blob: Blob): Promise<string>;
  bytes(blob: Blob): Promise<Data>;
  readonly size: unknown /*The type couldn't be resolved automatically.*/;
  readonly type: unknown /*The type couldn't be resolved automatically.*/;
  constructor(
    blobParts: (string | Blob | TypedArray)[] | undefined,
    options: BlobOptions | undefined
  );
}

export declare class ExpoBlobNativeModuleType extends NativeModule {
  Blob: typeof Blob;
}

Notice how the return types of slice, type, and size haven't been resolved. You can often fix this by manually annotating the return type of the closure in Swift.

Imported declarations also cause issues since we only parse provided files and ignore imports. If a function or type from outside influences a return value, the tool may not resolve it.

The tool struggles with return types if you omit the return keyword and don't explicitly annotate the closure. To avoid this, annotate DSL declarations or include the return keyword. Try using --type-inference PREPROCESS_AND_INFERENCE in the CLI for better return type inference.

How it works under the hood

Let's examine what happens when you use inline modules. Suppose you've created a module at app/nested/InlineModule.swift and set watchedDirectories to include the app folder.

{
  "expo": {
    "experiments": {
      "inlineModules": {
        "watchedDirectories": ["app"]
      }
    }
  }
}

Prebuild process

Running npx expo prebuild updates your native projects in two ways:

The Xcode project gets updated so the app folder becomes a file system synchronized group. This makes all files in the folder show up in the Xcode editor and get automatically included in the iOS build.

Project properties for both iOS and Android get updated with your watchedDirectories. On Android, this is essential for adding files to Android Studio. These properties are used later during autolinking.

// Podfile.properties.json
{
  "expo.jsEngine": "hermes",
  "EX_DEV_CLIENT_NETWORK_INSPECTOR": "true",
  "expo.inlineModules.watchedDirectories": "[\"app\"]"
}

// gradle.properties
# ...
expo.inlineModules.watchedDirectories=["app"]

Android project updates

On Android, the project updates during the Gradle configuration phase. This happens when you click Sync Project with Gradle Files in Android Studio or automatically before building the app.

During this phase, a folder structure gets created that mirrors your watchedDirectories. Symlinks are created to the Kotlin files inside those directory trees.

This mirror structure ensures native files get compiled and are visible in Android Studio, while other project files are ignored. JavaScript and TypeScript files won't be indexed by Android Studio since they're not in this mirror directory.

Module registration

All Expo modules live on a global object exposed through native module providers. During build on both iOS and Android, a module provider class gets generated containing references to all regular Expo modules and your inline modules. When you call requireNativeModule('InlineModule') in JavaScript, it accesses this global object.

Type generation internals

Type generation works by parsing the native module's structured declaration and generating its TypeScript interface directly from native code. The expo-type-information package has four main parts:

Swift parser
Abstraction over module types
TypeScript code generator
CLI tool

They work together to automate writing TypeScript interfaces for your modules.

Bridging type systems

When defining a module in the DSL, you provide the native interface with functions, constants, classes, and views - all strictly typed in Swift's type system.

When interfacing with the module from TypeScript, you're working with JavaScript objects under TypeScript's type system. This differs from Swift or Kotlin, and there's no strict one-to-one mapping between them. The conversions between JavaScript and Swift aren't always obvious.

Expo provides converters for many types, but multiple TypeScript constructs sometimes convert to the same Swift type.

For example, when working with Swift's UIColor, Expo can convert several JavaScript objects: color strings ('red'), hex strings (#00ffaa00), or hex numbers (0xff66dd00). All of these can be type-annotated differently in TypeScript - string, number and ColorValue (from react-native) all convert to UIColor.

Currently we only support mapping basic types (number, string, boolean, etc.). Check the exact list in the reference. We'll continue updating the package with additional type mappings based on converters available in expo-modules-core.

Library components

The expo-type-information package consists of several components working together.

Swift file parsing

We use SourceKitten to parse Swift files. SourceKitten provides structured information about the whole code, letting us parse the Swift DSL, enums, and structs.

Consider the Hello constant declaration from InlineModule.swift:

Constant("Hello") {
  return "Hello iOS inline modules!"
}

That Swift declaration corresponds to this SourceKitten output:

{
  "key.bodylength": 56,
  "key.bodyoffset": 124,
  "key.kind": "source.lang.swift.expr.call",
  "key.length": 66,
  "key.name": "Constant",
  "key.namelength": 8,
  "key.nameoffset": 115,
  "key.offset": 115,
  "key.substructure": [
    {
      "key.bodylength": 7,
      "key.bodyoffset": 124,
      "key.kind": "source.lang.swift.expr.argument",
      "key.length": 7,
      "key.offset": 124
    },
    {
      "key.bodylength": 48,
      "key.bodyoffset": 133,
      "key.kind": "source.lang.swift.expr.argument",
      "key.length": 48,
      "key.offset": 133,
      "key.substructure": [
        {
          "key.bodylength": 46,
          "key.bodyoffset": 134,
          "key.kind": "source.lang.swift.expr.closure",
          "key.length": 48,
          "key.offset": 133,
          "key.substructure": [
            {
              "key.bodylength": 46,
              "key.bodyoffset": 134,
              "key.kind": "source.lang.swift.stmt.brace",
              "key.length": 48,
              "key.offset": 133
            }
          ]
        }
      ]
    }
  ]
}

SourceKitten lets us parse just a single file. This saves time since it doesn't have to compile the whole Xcode project, which is essential when you want to constantly regenerate TypeScript interfaces. But not having access to the whole project means types and functions defined in other files can't be resolved.

Type information abstraction

An abstraction layer defines what type information is relevant for Expo modules. The abstraction is agnostic to the underlying native language, so we can add Kotlin support in the future. It's close to the TypeScript type system since it generates TS declarations. Our SourceKitten-based parser outputs this abstraction.

/**
 * `FileTypeInformation` object abstracts over type related information in a file.
 * The abstraction is closely related to Typescript and expo NativeModules (both to be independent of the actual native side
 * and to give accurate information about what and how we can use the given module).
 * @header TypeInfoTypes
 */
export type FileTypeInformation = {
  /**
   * @field Set of all type identifiers declared and used in the file.
   */
  usedTypeIdentifiers: Set<string>;
  /**
   * @field Set of all type identifiers declared in the file.
   */
  declaredTypeIdentifiers: Set<string>;
  /**
   * @field For parametrized types it is the maximum number of parameters this type is used with.
   * This map is useful if we want to infer how many parameters a type declared in other file has.
   *
   * For example if `Set<string>` exists in a file then inferredTypeParametersCount['Set'] == 1.
   * If `Map<number, string>` exists then inferredTypeParametersCount['Map'] == 2.
   * If you use both `SomeParametrizedType<Type1, Type2>` and `SomeParametrizedType<Type3>` then inferredTypeParametersCount['SomeParametrizedType'] == 2.
   */
  inferredTypeParametersCount: Map<string, number>;
  /**
   * @field Maps string identifier to the appropriate declaration object. For now only enum and records identifiers are mapped.
   */
  typeIdentifierDefinitionMap: TypeIdentifierDefinitionMap;
  /**
   * @field Array of all module classes declared in the given file.
   */
  moduleClasses: ModuleClassDeclaration[];
  /**
   * @field Array of all record classes declared in the given file.
   */
  records: RecordType[];
  /**
   * @field Array of all enums declared in the given file.
   */
  enums: EnumType[];
};

TypeScript emission

With Expo Modules types abstracted, we generate a TypeScript Abstract Syntax Tree (AST). We build this using the Compiler API with custom wrappers that handle different declaration types - imports, enums, classes, functions, types, interfaces. Once the AST is complete, we format the generated TypeScript with Prettier.

CLI interface

The CLI tool sits on top of everything. It exposes commands to work with regular modules, inline modules, and to debug the functions from previous steps.

Next steps

Check out the tutorials for inline modules and type generation, plus the reference pages for inline modules and the expo-type-information package.

Both features are experimental, so your feedback matters as we continue developing them. File an issue or create a pull request on GitHub, or share your thoughts on Twitter.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Swift Calls JSI Directly in Expo SDK 56: Removing the Objective-C++ Layer

Dan — Mon, 08 Jun 2026 20:28:57 +0000

SDK 56 makes JavaScript to native calls significantly faster on iOS by letting Swift talk to JSI directly. We eliminated the Objective-C++ layer and saw 1.6-2.3x performance improvements across our benchmarks.

Before this change, every native module call went through three languages. Now it's just Swift making a direct C++ call. Here's how we did it and what the performance gains look like.

The three-language problem

Prior to SDK 56, calling an Expo native module from JavaScript meant crossing multiple language boundaries. Your Swift module code sat behind an Objective-C++ translation layer (EXJavaScriptRuntime, EXJavaScriptValue, etc.), which then called into JSI's C++ implementation.

This architecture existed for one reason: Swift couldn't talk to C++ directly. Objective-C++ was the only practical bridge between them.

The performance cost was significant. Every call crossed two language boundaries in each direction. Each value got converted twice: std::string → NSString → Swift String, std::vector → NSArray → Swift Array. Each conversion allocated memory and copied data.

Three different languages in the call path meant three different ways to debug problems. Stack traces changed shape mid-call. Memory management worked differently at each layer. When something went wrong, you had to understand all three languages to fix it.

Swift/C++ interop changes the game

Swift historically needed Objective-C as a bridge to reach C++. Any C++ type had to be wrapped in an Objective-C class before Swift could use it.

Swift/C++ interop (introduced in Swift 5.9) removes this requirement. Swift can import C++ headers directly. The compiler automatically maps C++ classes and methods onto Swift types you can use naturally.

The result: what used to be a three-language relay race becomes a single Swift expression that compiles down to a direct C++ call. Performance matches what you'd get writing the call in C++ from the start.

We're not the first to explore this in React Native. Nitro Modules pioneered this approach when Swift/C++ interop was even less mature.

Building ExpoModulesJSI

ExpoModulesJSI is our Swift package that wraps JSI in Swift types. Despite the name, it's purely a JSI wrapper with no Expo-specific code. We could ship it standalone, but JSI only exists in React Native contexts, so the naming stays conservative.

The type system mirrors JSI exactly: JavaScriptRuntime, JavaScriptValue, JavaScriptObject, JavaScriptArray, JavaScriptFunction, etc. Each maps to its JSI equivalent but with a modern Swift API.

We preserve JSI's ownership model using non-copyable types. JSI's value types like jsi::Value and jsi::Object own runtime resources and follow move-only semantics. Swift 5.9's ~Copyable protocol lets us mirror this behavior. The Swift compiler enforces the same single-owner rules that JSI expects underneath.

The package builds as a SwiftPM package with C++ interop enabled, then gets bundled into an xcframework. Most React Native projects use CocoaPods, so we also provide a podspec that wraps the prebuilt binary. The podspec creates a stub xcframework at pod install time, then a build script runs the real SwiftPM build with content-hash caching.

Handling different concurrency models

React Native's threading predates Swift Concurrency. JavaScript runs on a dedicated thread with a run loop. Native work uses dispatch_queue_ts and callbacks. No actors, no await points, just queues and blocks with thread-switching contracts.

We wanted our Swift API to use modern Swift: async/await, structured concurrency, actor isolation where appropriate. This required building a bridge between Swift Concurrency and React Native's callback world without breaking either system's invariants.

The boundary layer handles most of this work. We'll skip the implementation details here since they could fill another post and the design is still evolving under production load.

Implementation challenges

Swift/C++ interop is experimental and comes with compilation costs. Here are the main issues we encountered:

Experimental status. Years after Swift 5.9, C++ interop remains opt-in and officially experimental. APIs and behavior can change between Swift versions. Not a blocker for us, but worth knowing.

Capability gaps. Swift and C++ have different memory models. ARC and value semantics versus manual lifetime management and raw pointers. Complex template metaprogramming and some inheritance patterns have no clean Swift mapping. Some gaps will close with tooling improvements; others are conceptually unbridgeable.

Compilation performance. Enabling C++ interop adds noticeable compile time per file. It also spreads: any module importing an interop-enabled module must enable interop too. We solve this by shipping prebuilt xcframeworks. Apps link against binaries instead of recompiling interop sources, and downstream modules see a regular Swift library.

Generated headers. Swift emits a C++ header exposing all public symbols to C++. This gets large quickly and sometimes emits declarations in the wrong order. There's an undocumented flag -clang-header-expose-decls=has-expose-attr that restricts the header to explicitly annotated declarations. It's mentioned only in FrontendOptions.td in the Swift compiler source.

Third-party type annotations. Swift imports C++ classes as value types by default, but types with virtual methods need reference semantics. For code we control, Swift provides macros like SWIFT_SHARED_REFERENCE. For third-party headers like JSI, we use Clang's APINotes - YAML files that add import attributes without modifying the original headers.

Exception handling. C++ exceptions don't cross into Swift. Swift assumes imported C++ functions don't throw unless proven otherwise. When JSI methods like evaluateJavaScript throw jsi::JSError, the exception crashes the app if it reaches Swift frames. We built a bridge that catches C++ exceptions, stores them in thread-local storage, and rethrows them as Swift errors after each call.

Performance benchmarks

Our goal was simple: don't sacrifice performance for better Swift APIs. Turbo Modules set the bar for modern React Native native modules, and we wanted to match that performance while providing superior ergonomics.

Methodology

We tested four micro-benchmarks across three native module architectures on two SDK versions. Each benchmark ran 100,000 iterations, averaged across three trials on an iPhone 16 Pro release build:

Sync no-op function
Adding two numbers (0 + 1)
String concatenation ('hello' + 'world')
Async no-op function

The architectures tested were Expo Modules, React Native Turbo Modules, and the legacy Bridge. We used trivial inputs intentionally - these measure boundary crossing costs, not computation costs.

Note on async testing: Expo Modules use Swift Concurrency (async/await), which requires more work per call than callback-style async (Task creation, continuations, scheduler interaction). Turbo Modules and Bridge use callbacks. This compares the same logical operation done idiomatically in each system.

Results

CODE_BLOCK_N

Expo Modules became 1.6-2.3x faster across all benchmarks. The improvements match our architectural changes: boundary costs dominated the no-op test, marshaling costs affected strings most, and async showed the largest absolute gains due to removed overhead.

Before SDK 56, Expo Modules trailed Turbo Modules on every test. After the rewrite, we match Turbo Modules on simple sync calls and lead by 55% on async operations. The async advantage matters most in real apps where promises chain across module boundaries.

Turbo Modules also improved between SDK 55 and 56 from upstream React Native changes, so we were catching up to a moving target.

The Bridge results show the old story: 3-4x slower on sync operations due to JSON serialization overhead. The async gap narrows to 1.6x because Promise allocation and scheduling costs affect all architectures similarly.

Limitations

These micro-benchmarks measure boundary crossing costs. Real app performance depends on call frequency, payload size, and actual work being done. Device differences, OS versions, and Hermes builds will shift absolute numbers, but the performance ratios should remain consistent.

What comes next

Removing the Objective-C++ layer makes previously difficult features straightforward to implement. It also opens up performance optimizations that are now practical with a single-language call path.

This rewrite provides the foundation for the next round of API improvements we're planning.

Using SDK 56 native modules

SDK 56 ships the new native module architecture on iOS, tvOS, and macOS. Check the SDK 56 release notes for complete details. The expo-modules-jsi package is available on GitHub for bug reports, feature requests, and contributions.

Android takes a different approach in SDK 56. The major win there is our Kotlin compiler plugin, which moves more work to compile time and delivers larger performance gains than a JSI rewrite would provide. We may explore a Kotlin-first JSI wrapper eventually, but Android's JSI performance was already in better shape.

One final note: AI significantly accelerated this rewrite. It covered almost the entire JSI C++ surface in Swift and pushed test coverage to nearly 90%. Doing this work manually would have taken much longer.

This post is based on content from the Expo blog. Follow @expo for more React Native content.