DEV Community: Dan

How Hipcamp upgraded Expo SDK versions with Claude Code

Dan — Wed, 22 Jul 2026 16:59:21 +0000

Originally published on expo.dev/blog by Armaiz Adenwala.

This is a guest post from Armaiz Adenwala - Armaiz is responsible for the mobile app experience at Hipcamp.

…

Upgrading React Native has always been a scary task for any engineer. It requires touching unfamiliar native code, crucial libraries, and resolving breaking changes. Anything could raise an error if not tested thoroughly. Over time tools like React Native Upgrade helper eased the process and frameworks like Expo were built around making this process go smoother.

The complexity of upgrades

Unfortunately, not every React Native app is in a perfect state. It can be very difficult for a fast paced company to balance maintaining dependencies and shipping features. As a result, upgrades become a much larger endeavor. At Hipcamp, we recently faced the challenge of upgrading to New Architecture + Expo 54. With New Architecture, we had a few dozen libraries that were outdated and needed to be either upgraded or replaced.

If you have worked on React Native enough, you would know that simply bumping to the latest version is not enough. There is a large amount of time spent debugging and addressing issues. Additionally, multiple libraries could conflict with each other and you may need to find compatible versions between the two.

Luckily, this time we had already built Scout, an AI agent designed to tackle whatever task we throw at it. What would have taken an engineer weeks of tedious dependency research and version resolution, Scout handled across a few focused sessions over several days. While having an internal agent like Scout helps, we will be sharing how you can tackle React Native upgrades with pure Claude Code.

The State of the Hipcamp App pre-upgrade

We haven’t kept up with our app versioning enough outside security updates. Abandoned packages, outdated packages from 4-6 years ago, etc. We had over 100 dependencies with roughly 40 of them needing to be upgraded to support New Arch.

Given how lean our company is, we didn’t have cycles to juggle upgrades on top of regular product work. It wasn’t a cost issue, it was a time issue for us. We couldn’t justify taking an engineer off an impactful project to work on this major upgrade for a couple months.

How to scope an upgrade

Before we dive into how we accomplished this upgrade, we need to discuss the key goals of this process in order to design our prompts.

We landed on the following:

Only focus on dependencies that are needed
- We only upgrade libraries that don’t currently support new arch / 16kb android
Replace dependencies with an Expo equivalent
- Expo’s modules are well maintained, reliable, and popular.
Leverage patch-package as a last resort

The upgrade workflow

We then decided how we wanted this upgrade process to go. We determined we needed to build a multi-phase approach.

We had to decide how much time/money we were willing to spend on each phase of the work. Ultimately we realized that tokens are far cheaper than having an engineer tirelessly navigate through docs, code, and Github issues. Not to mention, our engineers spent their time saved on developing product features that bring us revenue. So it was a no brainer to not let budget restrict this project.

Phase 1: Build your agent

We highly recommending building an agent like Scout internally or leverage Expo’s upgrade skill. Teach the agent your codebase, design a way to index the architecture of your codebase. We spent a day running our documenter command, /scout-document-architecture, to take notes on every aspect and detail of our app. This prevented Scout from hallucinating or missing anything.

Phase 2: Audit all of your dependencies

We sent our agent on a task to audit all of our dependencies. We recommend using an sqlite db to track everything, you can sync this db to your project management tool, or just resort to using a markdown file.

We then provided it a prompt. Here is an example of what we gave ours:

# Expo SDK 50 → 54 Dependency Audit

Audit every dependency in the app for Expo 50 → 54 upgrade compatibility.

## Context
- **Current:** Expo 50 (RN 0.73, React 18.2)
- **Target:** Expo 54 (RN 0.81, React 19.1)
- Expo 52+ enables New Architecture by default
- Expo 52+ requires 16kb Android page size support

## Research
For each dependency, you MUST:
- **Read GitHub changelogs/releases** between the Expo 50 and Expo 54 compatible versions
- **Search GitHub issues** for bugs, errors, risks, complaints
- **Read setup docs** and migration guides
- **Check for conflicts** with other dependencies in our stack
- **Check if the setup switch is risky or complex**

Then answer:
1. Can this be **replaced with an Expo module**?
2. Can this be **removed entirely**?
3. Are there **known New Arch blockers** in GitHub issues?
4. Are there **16kb page size issues** reported?
5. Does this have **peer dependency conflicts** with other deps?
6. Is the **upgrade path smooth** or does it require code changes?
7. Are there **community complaints** about recent versions?

## Subagent Strategy
- **1 subagent** for small/simple JS-only dependencies
- **5 subagents** for medium/harder native dependencies
- **10 subagents** for extreme-complexity dependencies (react-native core, reanimated, maps, firebase, sentry)
- Each subagent works on exactly ONE dependency — do not batch

## Output
- One notes file per dependency in `./dependencies/{name}.md`
- SQLite DB at `./dependencies.db` with columns: name, expo_50_version, max_version_expo_50, expo_54_version, new_arch_support, sixteenkb_support, status, type (javascript/native), change_recommendation (upgrade/remove/swap), swap_target, complexity (0-10), notes
- **Always prefer replacing with an Expo equivalent library if possible**
- Process dependencies one at a time — do not skip ahead

## References
- https://reactnative.directory/
- https://docs.expo.dev/workflow/upgrading-expo-sdk-walkthrough/

Phase 3: Review and begin the upgrade!

Then, we manually went through each upgrade item and confirmed it all looked right. We make sure its not removing libraries it shouldn’t, and pick the right alternative library if it recommended any. We highly recommend using Expo’s libraries if available as they are actively maintained and well documented.

Once complete, we sent off an agent to work on creating prs for every upgrade. For us, the initial run was 3 days of non stop upgrading. We HIGHLY recommend using subagents for every step when dealing with long running tasks. Having each dependency in its own context is critical for a reliable upgrade.

We gave it the following process:

Pick a dependency
Send a subagent to look at notes from previous step
Have 1-3 subagents attempt to upgrade to the version specified
Once complete, send reviewer subagents to review changes
Run yarn lint, tsc, and react native bundle and address any errors that come up
Create an EAS build for ios and android, validate that the build was successful. Address any errors that may come up
Create a final EAS Build for ios + android
Create a pr and add builds, manual QA steps, affected screens, and anything else

When I came back, I had numerous prs to review. It was very quick to go through all of the prs. There were of course a few prs that needed close engineer involvement, but were easy to work on as our agent already shared all of the context, docs, related Github issues, and more in the PR.

From our experience, we only had a week spent debugging some New Architecture build issues. Our entire upgrade process went from what was estimated to be 2-3 months to a couple weeks. From one quarter to a sprint. Our dependency situation was very concerning, for smaller apps you may notice even less time spent.

Of course we still had polishing but the bulk of the work was done.

Phase 4: QA, rollout, and monitoring

We wanted a very safe rollout, we required our fellow Hipcamp employees to use the app and call out bugs. We threw a QA party where people from the company joined and QA’d the app together. These are extremely productive.

We then used the slow rollout feature on iOS and Android. We released iOS first then released Android after we felt confident on iOS.

Monitoring:

It is crucial you have some form of error tracking in place. In addition, it is a good idea to integrate performance profiling into the app. There are many out there, one of which being Expo Observe - we are lucky to be participants in their private preview!

We also had our agent monitor and fix errors for us as they came through. Whether this was from the QA party or from production, our agent was able to resolve most bugs with minimal engineering involvement.

To our surprise we saw no major new errors other than a high memory usage issue that became magnified on New Architecture. In fact we saw less errors in total. We attribute this to the fact that engineers can spend time solving the complex work and throughly QA’ing while an agent works through the rest.

Conclusion

AI is changing how engineers work. The hours spent skimming documentation, racing against deadlines, and debugging obscure issues may soon be a thing of the past. This upgrade was proof that AI agents can be a reliable partner on important, challenging projects, and that the real benefit of AI-assisted engineering isn't replacing engineers but freeing them to focus on complex problems instead of toiling through tedious ones.

I joined Expo.

Dan — Tue, 14 Jul 2026 23:43:31 +0000

Originally published on expo.dev/blog by Seth Webster.

I recently joined Expo as Chief Developer Evangelist while I continue to serve as Executive Director of the newly formed React Foundation. I want to share my excitement about where we are, and why I am so thrilled to be here.

Why I made this move

Most teams do not run out of ideas. They run into drag.

Over time, more and more effort goes into managing complexity instead of creating value. At some point even the cost of your own success can be debilitating.

That is the category of problems Expo has been solving for people for years.

Expo gives developers the fastest path from their brain to a shipped product. Period. It helps teams start quickly, iterate with tight feedback loops, and reach multiple platforms without turning every product decision into infrastructure work.

That matters because developer velocity is not just about convenience… It is how teams learn faster. It is how companies stay close to their users. It is how more good ideas actually make it into the world.

This is also how I see React… an incredibly high leverage tool when it comes to my north star: unleashing all of humanity on the totality of the world’s problems. Anything that shortens the distance between a random thought and a solution will, at the very least, catch my eye.

Expo & AI

What makes this moment especially compelling to me is the convergence of two shifts.

AI has become a collaborator in software development and mobile remains one of the primary ways we experience software.

Those things together matter. When software becomes easier to generate, the bottleneck moves from tooling to shipping. The teams that win will be the ones with the shortest path from intent to working product.

Expo is incredibly well positioned for that future… I have yet to meet a more developer-obsessed team than the one here at Expo.

Expo already gives teams rapid feedback loops, a strong foundation in React, and a practical path to building across platforms. Just as important, the team understands something many people miss: speed only matters when it helps people build better products, and better products only happen when people have the time to sweat the small stuff.

For me, the product Expo is building matters. The people matter just as much.

In Charlie Cheever, James Ide, and the broader engineering team, I saw something I care deeply about: real technical conviction paired with long-term ecosystem thinking. Then I met Evan Bacon, and it was a transformative meeting for me, one that stayed with me and became part of my story.

Moments like that are rare and not easily dismissed.

The best platform teams do not just solve today’s problems. They create leverage for everyone building on top of them. They think about trust. They think about durability. They think about what developers, and now agents, will need next, not just what they need right now.

I knew then that these were people I wanted to work with. That this was the kind of work I wanted to be part of.

My role at Expo

As Chief Developer Evangelist, my job is to help the Expo ecosystem grow in depth, reach, and impact.

That means helping teams adopt Expo at scale, strengthening the connection between Expo and the broader React ecosystem, supporting the next generation of AI-assisted development workflows, and growing the global community around Expo and React Native.

In practical terms, I’ll be spending time with developers, companies, and community leaders to help more ideas become real products.

I’ve believed for a long time that the most important technology in the world is not software itself.

It is the people who build it.

Tools give people leverage. Good tools give them velocity. Great tools give them momentum.

We knew this when we (React) recommended Expo as the default framework for developing for mobile, but the number of exciting things this team has in store for this next era boggles the mind.

I couldn’t be more thrilled to be here, and look forward to spending more time with you all.

P.S. If you want to come work with me/us, [*we're hiring](https://expo.dev/careers)!*

Build an AI QA Agent for Expo Apps with EAS Workflows in minutes today

Dan — Fri, 03 Jul 2026 16:13:49 +0000

Originally published on expo.dev/blog by Michał Pierzchała.

This is a guest post from Michał Pierzchała - Principal Engineer at Callstack's R&D Incubator; created agent-device, React Native Testing Library.

…

AI agents are great at producing a lot of code, quickly. More code means more PRs targeting our codebase, and even more demand for a code quality assurance process that works and scales together with agents generating it.

While AI agents contributing to backend codebases will often do well with integration tests, things are not so bright on the frontend side. When it comes to generating code that produces UI, such as mobile iOS and Android apps, the latest models will often do amazingly well without even checking the results (thank you React for declarative UI that makes this easier). But many times they’ll just miss the mark. Imagine a hardcore React Native developer that can only read code, without access to a mobile device. How certain you can be they’ll nail the job just by looking at the code? Hint: not much. Verification is key.

This is the gap we want to close for our Expo apps. And in this article, I’ll show you how to do it using existing tools at no extra cost. Let’s dive in!

With EAS Workflows, you can already reuse builds, run custom jobs on Android and iOS, and comment on GitHub pull requests. That turns out to be enough to build a lightweight QA agent today, without introducing a big custom platform.

I put together a minimal template here: callstackincubator/eas-agent-device.

The setup is intentionally small:

Expo app with CNG
EAS Workflows for orchestration
a tiny Node.js QA agent using AI SDK
agent-device for Android and iOS automation
one GitHub comment with Android and iOS QA results

The important part is not the “AI” label. It’s that you can start with a working baseline in minutes, then expand it as your team needs more coverage.

The goal

For every pull request, we want to:

reuse an existing mobile release build with latest JS when possible
boot an emulator or simulator
install and launch the app
let an agent inspect the UI and take screenshots
post a short QA summary under the PR

That’s it. Not a giant test framework. Not a replacement for all E2E tests. Just a practical QA loop around mobile UI changes.

Why EAS Workflows fits this really well

The main reason is that EAS Workflows already understands mobile-specific CI.

What you get easily:

fingerprint to detect native changes
get-build to find reusable builds
repack to avoid rebuilding native code when only JS changed
linux and macos runners with virtualization that run Android and iOS devices
github-comment to send the result back to the PR

So instead of forcing mobile automation into a generic CI system, you can keep the whole pipeline where the mobile pieces already exist. That makes the setup much easier to reason about.

I’ll note here we’ll need a linux-medium-nested-virtualization image for Android job to be able to open Android Emulators, which we’ll need to install from scratch, and macos-medium image (or larger) for iOS Simulators, which are already available. I must say I was positively surprised with the flexibility of the machines and to what extent I can script them.

Start from this workflow shape

The core workflow is simple and fits on a single screen:

jobs:
  fingerprint:
    type: fingerprint

  android_get_build:
    type: get-build
    params:
      platform: android
      profile: qa-release

  android_repack:
    type: repack

  android_build:
    type: build

  qa_android:
    runs_on: linux-medium-nested-virtualization
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/download_build
      - id: provision_android_emulator
        run: bash ./scripts/agent-qa/provision-android-emulator.sh
      - id: run_agent_qa
        run: bash ./scripts/agent-qa/run-and-export.sh "${{ steps.download_build.outputs.artifact_path }}"
        env:
          AGENT_DEVICE_SESSION: qa-android
          AGENT_DEVICE_PLATFORM: android

  qa_comment:
    type: github-comment

For iOS, it’s the same idea, just on a macOS worker with a simulator build. The full working version, with Android and iOS running in parallel, is in the repo: .eas/workflows/agent-qa-mobile.yml

The key design choice: split bootstrap from QA

This is the one thing I’d strongly recommend.

At first glance, you might want the agent to do everything: install the app, open it, navigate, inspect, report. In practice, that makes the system more fragile than it needs to be. Agents can use our tools incorrectly, chose not to read the instructions we asked them to use, or hallucinate flags for CLIs they’re using (been there).

So the key to make our AI agent work for us reliably, not only at times, is to keep the workflow deterministic as much as it’s possible. And with agent-device we can script these pretty easily to always provide correct bootstrap parameters when installing and opening the app on a device:

#!/usr/bin/env bash

# Phase 1: deterministic bootstrap
agent-device install "${APP_ID}" "${APP_PATH}"
agent-device open "${APP_ID}" --relaunch

agent-device knows which platform to run thanks to AGENT_DEVICE_PLATFORM environment variable set in our job.

The other part of QA process that’s harder to script, can stay agent-driven. The agent will infer acceptance criteria from the PR, inspect the UI in a token-efficient way through accessibility tree, navigate a little, take screenshots, and summarize what happene

# Phase 2: variable agent-driven flow
npm run agent-qa

From my own experience building various agents over past month, that split makes the workflow much more reliable. That means the agent never has to guess artifact paths or install commands.

The agent can stay very small

Once the app is already running, the agent only needs a few tools:

read PR context
load the agent-device skill
run UI actions like snapshot, press, screenshot through agent-device
write a final report

A simplified version looks like this:

import { ToolLoopAgent } from 'ai';

const agent = new ToolLoopAgent({
  model: 'openai/gpt-5.4-mini',
  instructions: `
    You are a mobile QA agent running inside EAS Workflows.
    Treat the app as a black box.
    Infer acceptance criteria from the PR.
    The app is already installed and launched.
    Use agent-device to inspect the UI, navigate, take screenshots, and write a report.
    If the result is visually plausible but not fully confirmed from structured UI output, use "unsure".
    You must call write_report exactly once.
  `,
  tools: {
    get_pr_context,
    load_skill,
    read_skill_file,
    agent_device,
    write_report,
  },
});

That’s enough to get us started fast and iterate to greatness. I’m using Vercel’s AI SDK as it provides good balance of control vs batteries-included tools. On top of that I can access all the models I like through their AI Gateway service (with no markup, at least yet) or if you don’t want another subscription, you can use your good old OPENAI_API_KEY and use openai provider instead. Applies to providers too, not only OpenAI.

The full agent is here: scripts/agent-qa/index.ts - I tried to keep it brief.

Report only what’s necessary

Keep the output small and useful. In our template, each platform produces verification status, one of: passed, failed ,blocked ,unsure. And then a short section with a summary, checks performed, issues found, screenshots, and a full JSON report in a collapsible block (for debugging failed QA verification mostly).

That last status, unsure, is important. Mobile UI is not always easy to verify from structured automation output alone. Sometimes accessibility trees help a lot. Sometimes the screenshot is the strongest evidence. If the agent cannot prove the result cleanly, it should say so and attach the image.

That is much better than pretending it knows.

Final step: a comment under Pull Request

Like with human verification, a short comment under our work is often time all we need to get a good overview of what agent was able to verify (or not), together with a visual confirmation that we often need so much to truly assess the change is not breaking our app. A single PR comment works really well:

## Agent QA

| Platform | Status    |
| -------- | --------- |
| Android  | ✅ passed |
| iOS      | 🤔 unsure |

### Android
Short summary...
Screenshots

### iOS
Short summary...
Screenshots

That puts the result exactly where reviewers already are, with necessary information and visual feedback at hand.

💡There’s no official API to upload screenshots to GitHub comments, so instead in our example we used Vercel Blob as a 3rd party cloud to store images. Replace it with the solution that works for your use case, e.g. AWS S3.

What I’d recommend if you want to try this today

Connect your GitHub project to EAS Workflows from Expo dashboard
Start with one platform first, e.g. Android.
Use CNG and keep native build reuse enabled.
Keep your QA build profiles separate from production.
Make bootstrap deterministic.
Keep the agent black-box only.
Post one PR comment, not ten different artifacts.
Add screenshots early. They help a lot.

Then, once that works, extend it:

add iOS
upload screenshots to Blob storage
add better selectors
turn successful exploratory checks into more deterministic flows

The main takeaway

You do not need a huge AI testing platform to get useful mobile QA automation.

Expo together with EAS Workflows already gives you most of the infrastructure:

build reuse: for fast iteration and repack for up-to-date JS bundle
mobile CI workers: with scripting and virtualization, so simulators and emulators are available
workflow orchestration: to put this all together
GitHub integration: to reduce cognitive load and keep verification inside Pull Requests

From there, a custom QA agent can stay surprisingly small. And thanks to TypeScript-based AI SDK, you can bend it to all your needs (and it’s pretty flexible).

That’s why I like this setup: it’s something you can build today, in minutes, starting from a simple template, and grow only when you actually need more.

Start here: callstackincubator/eas-agent-device

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.

From React web to Native in one week

Dan — Thu, 25 Jun 2026 16:18:10 +0000

Originally published on expo.dev/blog
By Ishika Chakraborty

I am a React dev who writes Next.js, Tailwind, component libraries, and design systems every day - a world that feels completely familiar. Native does not, and for years that gap felt enormous.

Every time I thought about building an iOS app, I pictured Xcode, Swift, provisioning profiles, and two weeks disappearing before I even got to “Hello World.”

Until I built a real native iOS app running on my iPhone in a week - setup, native debugging, device testing, and the build, end to end.

Not a tutorial app, not a counter, not another todo list. I built Sun Buddy - a native iOS app with a cute, animated sun mascot, real-time UV tracking from my location, haptic feedback, daily local notifications, persistent progress, and a sleeping nighttime state when the sun is down.

I built it with Expo, Claude Code, and Expo Skills.

Setup at a glance: Expo SDK (latest), Claude Code (latest), Expo Skills installed via /plugin marketplace add expo/skills then /plugin install expo, latest macOS and Xcode, developed in the iOS Simulator and on a physical iPhone, final build via EAS.

This is my end-to-end journey: what transferred from React, what did not, where Expo made native feel approachable, and where platform reality still showed up.

The short version: I did not have to become an app developer to build this app. I had to learn the native edges around the React skills I already had.

The idea: Sun Buddy

The app needed to be real enough to test native development properly. I did not want to build something that could have just been a web page in disguise - I wanted to touch actual device capabilities: location, haptics, notifications, native animation, local storage, and a real build running on my iPhone.

So I landed on a sunlight exposure tracker. Sun Buddy is a daily habit app that helps you hit your recommended outdoor sunlight goal - tracked by UV index from your real location.

The idea was simple: you are supposed to get some outdoor sunlight every day, and most people do not. I wanted a little mascot named Sunny who reacts emotionally to your progress.

Sunny has a few states:

drowsy at 0%
curious when you have started
happy when you are halfway there
absolutely radiant when you hit your goal
asleep at night when the sun is down

A little weird. A little cute. The kind of app I would actually keep on my phone.

Sun Buddy was deliberately small, which was the point. I wanted a contained app that still forced me through real native surfaces: location permissions, device APIs, haptics, local notifications, persistent state, animation, app config, and an actual device build.

Those patterns are not specific to a sun mascot; they are the same patterns you hit in fitness apps, habit trackers, field tools, travel apps, internal dashboards, delivery workflows, or anything else that needs to feel at home on a phone.

The setup: Expo first, Claude Code second

The most important part of this experience was not that I used AI. It was that I was able to build a native app using the React mental model I already had, and that is where **Expo**** mattered**.
Expo gave me the app structure, routing, device APIs, build path, and the bridge from "I know React" to "this is running on my phone."

Claude Code gave me the pairing loop, and Expo Skills made that pairing loop much more useful.

That distinction matters. Claude Code on its own can help you write code, but native development has a lot of details where generic advice is not enough: permissions, config plugins, EAS Build profiles, App Store constraints, native module support. These are exactly the places where stale or vague guidance wastes time.

**A concrete example: **early on, Sunny's animations broke as soon as I added Reanimated. Generic AI suggestions sent me chasing version mismatches and bad imports for half an hour. The expo-dev-client Skill knew immediately to check that the Reanimated Babel plugin was registered in babel.config.js and that the Metro cache had been cleared. Two lines of config, one --clear flag, animation working. That is the kind of native-specific context generic advice routinely misses.

Expo Skills brought Expo-specific context into the workflow.

I noticed the difference most when I asked native-specific questions. Generic AI help could tell me how to write a component, but that was not the hard part. The harder questions were things like:

Should this be a normal Expo Go flow or a dev client?
Where does this permission need to be configured?
Is this a runtime library, a config plugin, or both?
What is the right path to a real iPhone build?
What changes when I move from simulator testing to TestFlight?

That is where Expo Skills mattered - they gave the pairing loop Expo-specific context instead of generic React Native guesses. I added the Skills inside Claude Code:

// expo-skills
/plugin marketplace add expo/skills
/plugin install expo

Expo Skills are structured instruction files that work with Claude Code, Cursor, Codex, and other agents. I leaned on the expo plugin, which bundles three actively-maintained Expo Skills:

**building-native-ui** - Expo Router patterns, native UI structure, Apple HIG guidance
**expo-deployment** - EAS Build, TestFlight, App Store, credentials
**expo-dev-client** - development builds and native module support

That made Claude Code feel less like a generic coding assistant and more like a collaborator that understood the Expo ecosystem.

**On the same note: **I started in Expo Go to get the React shell rendering on my iPhone within minutes. The moment I added Skia for Sunny and Reanimated for the animations, I moved to a development build, because both rely on native modules Expo Go does not ship with. The Skills made that transition explicit rather than something I had to discover by crashing the app.

The surprise: my React skills transferred almost immediately

This was the biggest mental shift. The component code was just React - useState, useEffect, custom hooks, JSX, component composition, conditional rendering, fetching data, managing loading and error states. All of it came with me.

The primitives changed: View instead of div, Text instead of p, Pressable instead of button. But the mental model did not feel foreign at all. I wrote useUVIndex.ts and useSunTracking.ts the same way I would write hooks for a web app: fetch data, manage state, return values to the component. The layout model was familiar too - it was flexbox.

That does not mean everything from web transfers perfectly. But the core React instincts transferred much more than I expected.

Here is how it felt in practice:

What I knew from web	How it mapped to native
React components	React Native components
useState, useEffect, custom hooks	Same patterns
Next.js file-based routing	Expo Router
Flexbox layout	React Native flexbox
Browser geolocation	expo-location
localStorage	AsyncStorage
CSS/Framer-style motion instincts	Reanimated
Deploying a web app	EAS Build / TestFlight / App Store

That last row deserves a footnote: EAS simplifies the path, but App Store and TestFlight still involve Apple-specific review, code signing, metadata, and account requirements that have no real web equivalent.

That table explains why this felt approachable. I was not starting over, I was learning the edges of a new runtime.

The part that did not transfer automatically

The surrounding layer is where native feels different. Not the component model, not the React part, but the native edges

Things like:

permission prompts
device APIs
build-time configuration
native modules
simulator state
development builds
code signing
App Store constraints
testing on a real device

That is where I would have taken wrong turns without Expo and Expo Skills.

For example, location on native is not navigator.geolocation. With expo-location, I needed to request foreground permissions first, check the result, handle denial gracefully, and only then get the device position.

The shape of the logic was familiar, but the platform expectations were different - not hard code, but you do need to know the right sequence.

const { status } = await Location.requestForegroundPermissionsAsync();

if (status !== "granted") {
  // Handle denial properly
  return;
}

const location = await Location.getCurrentPositionAsync({});

The same was true with config. On web, I rarely think about something like app.json. In Expo, that file matters. Some libraries are not just JS imports - they also modify native project configuration. expo-location needs an iOS usage description string so the system knows what to show in the permission dialog. expo-notifications registers an icon and notification channel. expo-router wires up the native navigation stack.

My app needed plugin entries like this:

"plugins": [
  "expo-router",
  "expo-location",
  [
    "expo-notifications",
    {
      "icon": "./assets/notification-icon.png"
    }
  ]
]

This is exactly where Expo-specific context helped. Without it, I probably would have written perfectly reasonable React code and then wasted time debugging native behavior that had nothing to do with my components.

The native capabilities I added

Once the app structure was in place, the fun part was adding things that actually feel native.

I used expo-location to get the phone's GPS coordinates, then passed those to the Open-Meteo API to get the current UV index - no API key, no backend, just the phone's location and a public weather API. That alone made the app feel different from a normal web project. It was not asking the user to type a city; it already knew where the device was.

Then I added haptics. This was the smallest feature that made the biggest difference. I used expo-haptics for two moments:

light impact feedback when starting a sun session
success feedback when hitting 100%

The code was tiny:

await Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Light);

And:

await Haptics.notificationAsync(
  Haptics.NotificationFeedbackType.Success
);

But the effect was immediate.

Tap. Bounce. Haptic.

Suddenly it did not feel like a React screen pretending to be an app. It felt like something that belonged on the phone.

Web developers do not usually think about haptics because there is no real web equivalent worth designing around. On native, two lines of code can change how the whole interaction feels.

I used expo-notifications for daily local reminders with copy that felt intentionally a little strange - scheduled on-device, not remote push. (Remote push would require APNs credentials and the paid Apple Developer Program, neither of which the app needed.)

Sunny is waiting for you outside. Probably.

That felt right for the mascot's personality.

Sunny was built with @shopify/react-native-skia and animated with react-native-reanimated - bouncing, blinking, emotional state transitions. If you have used Framer Motion, the mental model is not alien, and the result was much smoother than I expected. Not "good enough for a demo" smooth but actually smooth.

For daily progress, I used @react-native-async-storage/async-storage, which felt like async localStorage. I used expo-font for Nunito and @expo/vector-icons for tab icons. None of this felt like learning mobile development from scratch. Instead, it felt like using React to reach parts of the device that the web usually cannot reach.

Where things actually broke

A lot worked faster than I expected, and some things broke.

The Skia crash on web

I wanted the app to run on both native and web while developing. The native version of Sunny used Skia, but on web, Skia depends on CanvasKit and WebAssembly. I called Skia.Path.Make() before CanvasKit was ready, and the web build crashed immediately. I understood the bug once I saw it; what I did not know was the idiomatic React Native fix.

The fix was platform file splitting:

components/
  SunBuddy.native.tsx   # full Skia implementation
  SunBuddy.web.tsx      # SVG fallback

Metro automatically resolves .native.tsx for iOS and .web.tsx for web.

That pattern was new to me.

This convention is worth burning into muscle memory: instead of branching at runtime, Metro picks the right file at bundle time, which means platform-specific code never ships to the wrong target.

On web, I would probably reach for a runtime check or a lazy load. In React Native, platform-specific files are a first-class convention. My debugging instincts transferred; my knowledge of native patterns did not always. Expo Skills helped fill that gap.

The stale Metro bundler

After adding react-native-reanimated, I opened the simulator and the app crashed. The error was not especially helpful, and I spent about fifteen minutes assuming I had misconfigured something. The actual fix was clearing Metro:

npx expo start --clear

The old bundle was still being served without the Reanimated Babel plugin properly registered.

This is the canonical "try this first" move in Expo and React Native projects whenever you add a library with a Babel plugin and the simulator starts behaving oddly. Worth committing to muscle memory.

This is not a problem I am used to from web development. Vite usually restarts, refreshes, and gets out of the way. Native development has more state outside your editor.

I did not love that, but once I hit it and understood it, it became one of those "okay, now I know" moments.

The nighttime bug

This was my favorite bug because it was not really a technical one. I was testing Sun Buddy at 9pm, dark outside, and tapped "start sun session." Sunny bounced. Progress increased. The app happily tracked sunlight I was absolutely not getting.

The funny part is that the app was doing exactly what I had designed - a sunlight tracker that logged sessions and accumulated progress. However, the product logic I missed was obvious only once I used it: a sun tracker should probably check whether the sun is actually up. That was not an AI failure; it was my product thinking.

Tools execute on your intent, and your job is to have the right intent.

So I added sunrise and sunset calculation based on GPS coordinates. At night, Sunny goes into a sleeping state: half-lidded eyes, a little "zzz," drooped arms, and a disabled button that reads:

Sunny is sleeping. See you at sunrise.

That one bug made the app much better, and it reminded me that building with AI does not remove the need to actually use what you build.

Code signing

The most "native is still native" moment was code signing. On the EAS build, the push notification capability blocked signing on my free Apple Developer account, because remote push is a paid Developer Program feature, which was not really an Expo issue, just Apple being Apple.

I dropped the push notification capability via the Expo config rather than poking through Xcode. The Expo-native approach is to express the change in app.json and let Continuous Native Generation (CNG) regenerate the native project on the next build -either with a config plugin or expo-build-properties - so the change lives in source instead of in Xcode UI state. Local notifications still worked, because they do not need the push capability and no user-facing behavior changed.

But I did have to understand what was happening.

That was a useful reminder: Expo smooths a lot of the native path, but it does not erase platform reality. Apple still has certificates, capabilities, account types, and rules.

Apple's gating happens at distinct stages, and it is worth knowing the staircase before you start: a free Apple ID lets you run a build on your own device (with seven-day signing limits). TestFlight and App Store distribution require the paid Apple Developer Program. Certain capabilities - push notifications, in-app purchase, sign in with Apple - require the paid program even for development.

If you want TestFlight or App Store distribution, you need the Apple Developer Program and that part is not going away.

EAS is the path I recommend first

I tried local iOS setup because I wanted to understand what was happening under the hood, but if I were telling another React web developer how to start, I would point them to EAS earlier.

The basic flow is:

eas build:configure
eas build --platform ios
eas submit --platform ios

The exact profile depends on what you are building. development is for the dev client. preview is for internal distribution to a small group of testers. production is the App Store / TestFlight target. Profiles live in eas.json and you control them there.

One more nuance: eas submit uploads the binary to App Store Connect and makes it available in TestFlight after processing. It does not release the app to production. You still need App Store Connect metadata, screenshots, the privacy questionnaire, build selection, and App Review.

That gives you cloud builds, credentials management, and a cleaner path to TestFlight and App Store submission - removing a lot of the local machine pain from the first serious build.

**Expo Skills **also helped here because deployment advice gets stale quickly. Build profiles, credentials, submission flows, internal distribution, TestFlight - these are exactly the places where current Expo-specific context matters.

I also tried the local setup: Xcode, CocoaPods, device trust, signing. It took about an hour. Not zero friction, but also not the two-week nightmare I had invented in my head.

The risk of trying is lower than it looks.

You do not have to start by becoming an iOS developer, buying every tool, and committing to an App Store release. The lowest-friction first step is: npx create-expo-app, open it in the iOS Simulator with Expo Go, and wire up one native capability (location or haptics is a good pick). That is a one-evening loop. Move to a development build only when you reach for a library Expo Go does not ship with - Skia, Reanimated, custom native modules.

If it does, EAS gives you a path toward real builds and distribution. If it does not, you have spent a weekend learning how your React skills map to another surface area.

Native setup is real, but it is not a reason to avoid native forever.

The moment it clicked

The moment this stopped feeling theoretical was when I ran Sun Buddy on my actual iPhone. Sunny bounced. The Skia progress ring rendered. The UV badge showed a real number pulled from my real location. I tapped the start button and felt the haptic, then tapped it again, then a few more times because the loop felt good.

Tap. Animation. Haptic. Progress. Not a browser tab, not a responsive web view, not a prototype pretending to be an app, but a real thing on my phone, built with React.

It was on my home screen. It knew where I was. It responded to touch in a way the web usually does not.

That was the moment native stopped feeling like a completely different career path and started feeling like another surface area for the skills I already had.

What I would tell another React web developer

Your skills transfer. That is the main thing. The component model, the hooks, the debugging instincts - all of it comes with you. You are not starting from zero.

But native has edges, and you will hit them. A permission sequence. A stale Metro bundle. A config plugin. A signing capability. There will probably be a moment where you think: this is why I do not build native apps. For me, that moment was usually one --clear flag or one config entry away from being solved.

The AI part did not remove the work. I still had to decide what the app should do. I still had to notice that my sun tracker happily tracked sunlight at 9pm, which was ridiculous. The product thinking was mine. The judgment was mine.

If you write React and you have been avoiding native, do not start by trying to become a mobile expert. Start with one thing the web cannot really give you: location, haptics, camera, notifications, gestures.

Build something small around that. Run it on a device.

You will know pretty quickly whether it still feels like a separate world, or whether it starts to feel like another surface area for the skills you already have.

Sun Buddy was built with Expo, Claude Code, and Expo Skills. If you are a React web developer thinking about going native, I would start here: Expo for React web developers.

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.