DEV Community: Dan

How SWSH turned 300 monthly builds into a release pipeline nobody has to babysit

Dan — Sat, 05 Sep 2026 15:04:16 +0000

"Expo's ecosystem helped us take human error and effort out of the release process, from a local build to a validated release."

— Nathan Ahn, CTO, SWSH

You've shipped a mobile app before, so you know the drill: cut the builds, wrestle with signing credentials, submit to two different app stores, then hope nothing regressed on the way out. Do that by hand often enough and one of those steps eventually bites you.

SWSH, a social photo-sharing app for shared albums and events, ships across iOS, an iOS App Clip, Android, and the web from a single React Native codebase, and its release process barely needs a person in the loop. The team runs 300 builds a month on its own hardware, never touches signing credentials directly, drives App Store Connect through its API instead of a browser, and validates every release with a home-built end-to-end suite before it goes out.

This post breaks down how that pipeline is put together, piece by piece, using Expo, EAS Build, EAS Submit, EAS Update, and EAS Observe.

One codebase, every target

The web deploys on its own track, so the rest of this is about the three native targets: iOS, the App Clip, and Android. A change starts life as a local build, runs through an end-to-end test suite on iOS simulators and Android emulators, and lands in both app stores with almost no human involvement. Native releases go out about once a week, and the pipeline is what gets them there without anyone standing over it.

The problem: every manual step is a place to break something

Cut a build, handle credentials, submit to App Store Connect and Google Play, confirm nothing regressed. Done by hand, each of those steps is a place a release can quietly go wrong, and the more often you ship, the more those mistakes cost.

SWSH decided to go after the whole chain at once instead of patching individual steps: automate the entire release process so human error has nowhere left to enter. Expo's build and submit tooling gave them that automation out of the box, and a foundation solid enough to build custom pieces on top where they needed more.

Why Expo works as the base for this

Expo gave SWSH one automated path from source to store: builds, credentials, submission, and over-the-air updates, all under the same toolchain.

Continuous Native Generation (expo prebuild) means the team regenerates native iOS and Android projects on demand instead of hand-maintaining Xcode and Gradle files, while still being able to drop into native code when a feature needs it. And because EAS runs the same build tooling whether it's local or in the cloud, SWSH could adopt EAS's orchestration, credential management, and submission logic without giving up control over where the actual compilation happens.

Inside the pipeline

Local builds, run at SWSH's own scale

For most teams, Expo's cloud builds are the obvious call. SWSH is the exception, and the reason is volume: full iOS and Android builds on every pull request that touches native code, plus per-environment release builds, totaling roughly 300 a month. At that volume the economics shift, so SWSH moved compilation onto self-hosted macOS and Android runners with local EAS builds.

This is the detail that's easy to overlook about EAS: because eas build behaves identically whether it runs locally or in Expo's cloud, SWSH kept the orchestration, credential handling, and submission logic exactly as they were, and moved only the compute-heavy compilation step onto hardware it owns.

Credentials nobody on the team has to touch

Signing credentials for both App Store Connect and Google Play live in EAS. The only secret SWSH's CI holds is a single Expo access token. Code signing is the part of a mobile release you least want sitting in a CI config or a repo, and for SWSH it just isn't there.

Submission across both stores, with a custom layer for iOS

EAS Submit pushes each build directly to Google Play and App Store Connect with no custom code needed. On Google Play, that's the entire job. iOS asks for more work around the binary: a new App Store version, metadata and release notes, a configured App Clip experience, and a submission for review.

So SWSH pairs EAS Submit with an App Store Connect pipeline it built itself. Once EAS Submit uploads the build, that pipeline talks to the App Store Connect API directly: it polls until the build finishes processing, creates the App Store version, fills in metadata and the "What's New" text, configures the App Clip's default experience (card subtitle, card image, all of it), and submits the version for review.

If you've ever configured an App Clip experience by hand, you know how many screens that involves. SWSH turned all of it into one more automated step.

SWSH manages App Store metadata through this custom pipeline instead of EAS Metadata, Expo's declarative metadata solution. Most teams don't need to build something like this and should just reach for EAS Metadata directly.

Validating a release before it ships

Before anything goes out, SWSH runs an in-house end-to-end testing framework called Meridian, built on Appium and WebDriverIO and driven by Vitest. Meridian exercises the flows that actually matter (login, sign-up, upload, deep linking) across iOS, the App Clip, and Android, on simulators and emulators, in CI. When SWSH marks a release as validated, that means the app was actually driven through those flows, not just that it compiled without errors.

Shipping JS-only fixes without a store review

For changes that don't touch native code, EAS Update lets SWSH push JavaScript fixes immediately, no store review required.

The part worth stealing: Meridian validates these too. An EAS Update ships new JavaScript onto a native build that's already installed on users' devices, so SWSH runs the same test suite against the updated bundle paired with the build it's landing on, to confirm the combination works and nothing regressed.

Watching for regressions after release

Shipping isn't where the release ends. SWSH uses EAS Observe to watch app performance in production, tracking runtime metrics like first render and time-to-interactive. When a release introduces a startup or rendering regression, it shows up there, and the team pushes a fix over the air instead of waiting for the next native release.

What this buys them

Engineers push changes and move on. The pipeline builds, validates, submits, and monitors each release on its own, across roughly 300 builds a month, a native release about once a week, and same-day JavaScript fixes shipped over the air.

SWSH's setup is a decent argument that shipping often and shipping safely aren't opposites. Get the pipeline right once, and the attention that used to go into release logistics goes back into the app itself.

Where to start

If you're eyeing something like this for your own app:

Start with EAS Build and EAS Submit in the cloud before you consider local builds. Most teams never need to self-host.
Add EAS Update for JS-only fixes once your native release cadence settles into a rhythm.
Look at EAS Metadata before building a custom App Store Connect integration like SWSH's. It covers most teams' needs without the extra maintenance.

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

Life is too short for pasting images into TextInput to be this hard

Dan — Fri, 04 Sep 2026 15:26:01 +0000

This is a guest post from *Arunabh Verma, a **React Native developer and founder of Powstać who spends most of his time building mobile products with React Native, focusing on performance, interaction design, and the small details that make apps feel polished and intuitive.*

expo-paste-input: pasting images into TextInput shouldn't be this hard

You copy a screenshot from another app, tap into your chat composer, and paste it. On any native app, that just works. No file picker, no extra taps, no ceremony.

Powstać was building a chat app, and that one interaction was missing. We had image attachments, file uploads, media sharing, all the stuff you'd expect. But paste-to-attach wasn't there, and once I noticed it was missing, I couldn't unnotice it.

So I built it. It eventually became expo-paste-input, a native Expo module that wraps the standard React Native TextInput and adds onPaste support for images, GIFs, and even iOS stickers, without replacing the input or asking developers to learn a new component.

Here's how it came together, including the parts that didn't work.

The library we started with

At first we used Mattermost's react-native-paste-input, the same library Bluesky was using at the time. It supported image pasting on iOS and Android and solved our problem without us writing any native code. Small feature, but the UX improvement was immediate.

Then we migrated to React Native's New Architecture, and things started breaking. Not with one clean error, but in pieces: some parts worked, some didn't, and behavior diverged between platforms. We patched it, then patched it again. iOS stayed mostly functional. Android got harder to maintain with every release. At some point I realized we were spending more time working around the library than benefiting from it.

Why I didn't build a custom input

Around the same time, Software Mansion was working on richer input capabilities with react-native-enriched, a genuinely interesting project for rich text and rich input in React Native. I considered adopting it. I also considered writing a fully custom input from scratch.

Then I made a list of everything a native text input already handles: text selection, cursor management, autofill, accessibility, keyboard behavior, clipboard integration, IME support, input accessories, and a long tail of platform-specific edge cases. That's years of native behavior users already expect. I didn't want to rebuild TextInput. I wanted paste support.

react-native-enriched solves a bigger problem: rich content editing with embedded media. My use case was narrower. When a user pastes an image into a chat app, I don't want that image inserted into the text field itself. I want the file. I want a URI. I want to treat it as an attachment, same as if they'd picked it from the gallery.

That distinction became the whole design.

Wrap it, don't rebuild it

While researching approaches, I found Fernando Rojo's write-up on how v0 handled paste. The idea: don't rebuild TextInput, wrap it.

Instead of a new input component with its own styling and API surface, a wrapper sits around the normal TextInput, observes native paste events, and hands the app a file instead of inserting content into the field. The app keeps full control of the input. The library only adds paste intelligence.

That's the API I wanted:

// Composer.tsx
import { TextInput } from "react-native";
import { PasteInputWrapper } from "expo-paste-input";

export function Composer() {
  return (
    <PasteInputWrapper
      onPaste={(event) => {
        if (event.type === "images") {
          console.log(event.uris);
        }

        if (event.type === "text") {
          console.log(event.value);
        }
      }}
    >
      <TextInput placeholder="Type a message" />
    </PasteInputWrapper>
  );
}

No custom editor, no prop mirroring, no special styling system, no replacing a component developers already trust.

iOS: clipboard access is delicate

I started on iOS, where the first surprise was how careful you have to be with clipboard access. Modern iOS versions can show privacy prompts if an app inspects clipboard contents too early, so checking the pasteboard on every focus event is a bad idea. The wrapper only reads from UIPasteboard after the user explicitly triggers a paste.

Once that happens, the native layer inspects the clipboard for text, images, GIFs, WebP, HEIC, and other useful formats. If it finds media, it writes the content to temporary files and sends local file URIs back to JavaScript. The payload stays small on purpose:

type PasteEventPayload =
  | { type: "text"; value: string }
  | { type: "images"; uris: string[] }
  | { type: "unsupported" };

That gave me the shape I wanted from the start: a paste event, and the app decides what happens next.

Android: more fragmented, more work

Android's clipboard and content system is more spread out. For Android 12 and above, the right path is OnReceiveContentListener, which lets native views accept rich content like images and media. But that alone wasn't enough, because Android also has insertion menus, selection menus, clipboard managers, and multiple ways a paste can get triggered. To make this reliable, the library also hooks into native paste actions through Android's text editing APIs.

The behavior needed is simple to state: paste text and it appears as text, paste an image and it becomes an attachment. Getting there took more care. If the clipboard has text, Android should behave normally and the user shouldn't lose standard input behavior. If it has media, the wrapper intercepts it, saves the content to cache storage, and emits file URIs to JavaScript. That's the difference between a broken "can't paste image" moment and a composer that just works.

The edge cases that never stop

Once the basics worked, the real work started. GIFs needed to stay GIFs instead of collapsing into static images. Transparent PNGs needed to stay transparent, so the library preserves PNG output when there's an alpha channel and only uses JPEG when appropriate.

Screenshots were their own surprise. An image copied from the Photos app looks different on the clipboard than a screenshot copied directly from the system screenshot UI. Different payloads, different underlying data types. My original assumptions about "an image is an image" were wrong, so the implementation got smarter about identifying content types instead of assuming every image arrives the same way.

Stickers, and the issue that changed my thinking

Somebody opened an issue asking about iOS stickers. Even before stickers were supported, they pointed out the library should at least avoid inserting stray characters into the text field when someone pasted one. They were right, and most apps don't handle this well.

On iOS, stickers aren't always exposed as normal clipboard images. Newer iOS versions can insert them through text attachments and adaptive image glyphs instead of traditional image formats. So the library started watching for NSTextAttachment and, on iOS 18, NSAdaptiveImageGlyph. When sticker content shows up, the wrapper extracts the underlying image data, strips the attachment content out of the text field, keeps the cursor position intact, writes the media to temporary storage, and emits a normal image paste event.

The first version only handled static stickers. Animated sticker support came later. This ended up being my favorite part of the module, because it's the kind of thing users just expect to work, and when it works, nobody notices, which is exactly the point.

What it does today

expo-paste-input now supports text paste, image paste, multiple image paste, GIF paste, transparent images, screenshots, iOS stickers, and animated stickers, all while keeping developers on the standard TextInput they already use. No custom editor, no custom composer, no special rendering pipeline. Just a wrapper.

Limitations

This is a young, community-maintained module, not something Expo ships as core. If your app has a heavily customized text editing pipeline (rich text, embedded content, multi-format documents), react-native-enriched or a similar rich editor is probably a better fit than wrapping paste behavior around a plain TextInput. And clipboard/content APIs on both platforms keep changing across OS versions, so expect some new edge cases to show up over time, especially around newer iOS sticker formats.

Why this started as a client problem, not an open source project

This didn't begin as a library. It began as a requirement inside a real client product with real users and real platform constraints. That's what made it worth solving properly instead of shipping a quick patch.

We solved it for the app first. Once the implementation got more complete, it was clear other React Native developers were probably hitting the same wall. I also reached out to the Bluesky team, since they were using the same Mattermost-based approach we started with, and ended up contributing changes back to that conversation too.

That's the part of React Native I like most: a small fix in one app turning into something useful for a lot of other developers.

Where to start

Behind a single paste action sits clipboard privacy rules, temporary file handling, GIF and image format detection, Android content APIs, native text editing internals, and platform-specific sticker formats, none of which the user should ever have to think about.

If you're building a chat app, social feed, notes app, or anything where people share media constantly, try expo-paste-input in your project. If you hit an edge case I haven't found yet, open an issue on the repo, I'd genuinely like to know about it.

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

From Istanbul to #1 in the US App Store: why FERASET bet its AI app studio on Expo

Dan — Mon, 31 Aug 2026 20:44:40 +0000

Originally published on expo.dev/blog by Said Y. Kaban.

*This is a guest post from Said Kaban - he is the CTO and Co-Founder of FERASET. *

…

In late 2022, most mobile engineers I knew thought Expo was a prototyping tool. Something you'd use for a demo or a hackathon, then switch to the React Native CLI when you wanted to build anything real. Especially in Turkey, where we're based, this was the default take.

We thought differently. We looked at where Expo was going and saw the same trajectory as Next.js in the React ecosystem. An opinionated, managed layer that doesn't limit you but makes you way faster. So we went all in.

Today FERASET is an AI consumer app studio of ~40 people in Istanbul. We've hit #1 globally in the App Store in multiple countries including the US. Our entire mobile stack runs on Expo. It has since day one.

Here's how that played out.

We started at the right time, with the right bet

FERASET started right when the AI boom hit. ChatGPT had just launched. DALL-E was making headlines. Midjourney was everywhere. But they were all web products. If you wanted to create with AI, you were on a desktop or in a mobile browser. Nobody had built great native mobile experiences for AI yet and we knew that's where the users actually were.

So speed was the only thing that mattered. The teams that got polished AI apps into the stores first would win. Every week of delay meant losing ground.

We needed a framework that would let a small team ship to both platforms fast and not waste time on native toolchain issues. Expo gave us that. Music AI, our first app, went from the first line of code to live in the App Store in 4 weeks. A full MVP, both platforms, submitted and approved. That's the kind of speed Expo made possible and it's what let us move before the market got crowded.

Our first app hit #1 globally

Our first app was Music AI, an AI cover generation app. You could create AI covers of songs with different voices, or even train a custom voice of yourself or your loved ones and make them sing. It took off fast.

Music AI became the best AI cover app in the world. We surpassed Spotify in the App Store charts and reached the #1 spot globally in multiple countries including the US and major European markets.

That confirmed two things for us. The mobile AI market was real and massive. And Expo could absolutely handle production at scale. This wasn't a prototyping tool. This was the framework we'd build the whole company on.

From there, the next step felt obvious. The AI consumer space isn't a single-app market. Different users want different experiences: image generation, video, specific creative tools. One app can't serve all of them well. So instead of trying to stuff everything into Music AI, we decided to run FERASET as a studio. Multiple apps, each focused on a specific use case, all built by the same core team on Expo.

A real example of what we build on Expo

The best way to show what building on Expo actually looks like for us is through a specific example: expo-ai-kit.

expo-ai-kit: on-device AI for Expo apps

All of our apps use language models for things like prompt refinement, content guideline checks and text generation. Tasks that need an LLM but don't need a state-of-the-art model. For a long time, that meant API calls to cloud providers for every single request. It worked, but we were paying for inference on tasks that a small on-device model could handle just fine and user prompts were leaving the device when they didn't need to.

Apple Foundation Models on iOS and Google ML Kit's Prompt API on Android changed that equation. For the kind of tasks we need, these on-device models are more than good enough. And they're free. No API keys, no per-token costs, no network dependency. The problem was there was no clean way to use them from Expo. So we built expo-ai-kit.

It's an open-source Expo module that gives you a simple JavaScript API for on-device language models on both platforms. Here's what it looks like:

import { isAvailable, sendMessage } from 'expo-ai-kit';

const available = await isAvailable();

if (available) {
  const response = await sendMessage(
    [{ role: 'user', content: 'Refine this prompt for image generation: a cat sitting' }],
    { systemPrompt: 'You are a prompt engineering assistant.' }
  );
  console.log(response.text);
}

There's also streaming support for progressive text display:

import { streamMessage } from 'expo-ai-kit';

const { promise, stop } = streamMessage(
  [{ role: 'user', content: 'Check this text against content guidelines...' }],
  (event) => {
    setResponseText(event.accumulatedText);
  },
  { systemPrompt: 'You are a content moderation assistant.' }
);

Just npm install expo-ai-kit, add the config plugin and you're running on-device inference. The library currently gets tens of thousands of weekly downloads on npm.

For us, tasks that used to cost money on every request now run for free on the device. Response times for simple tasks dropped because there's no network round trip. And as on-device models keep getting more capable with every new chip generation, the range of tasks we can offload from the cloud will only grow.

We open-sourced it because we figured other developers would run into the same problem. And building it reinforced something we'd been experiencing all along: expo-ai-kit is real Swift and Kotlin code, talking to platform-level AI frameworks, integrated through Expo's module system and distributed as a config plugin. No ejecting, no bare workflow. You can go deep into native when you need to and still stay in the managed ecosystem.

The hardest part wasn't the tech

The biggest challenge we faced was the developer ecosystem in Turkey.

When we started, most mobile engineers here were more comfortable with other frameworks. Expo wasn't really on their radar for production apps and to be fair, that was a reasonable take at the time given how young the ecosystem was. Getting experienced engineers to give it a serious look took some convincing.

Hiring was tough early on. We couldn't just post a listing for an Expo engineer and get a pile of qualified candidates. We had to find engineers who were open to it, educate them on why Expo was the right choice and prove it through results.

We spent time building up the React Native and Expo community in Turkey. Sharing what we were learning, making the case that the React ecosystem would win mobile the same way React won the web. We wanted to spearhead that in Turkey rather than wait for the market to catch up.

It worked. But it took effort that had nothing to do with writing code.

What surprised us about Expo

The stability of Expo's managed workflow at scale was the biggest surprise. We're on CNG which helps immensely because we ship so fast and we create different builds constantly: dev, preview, prod. The ease of creating those builds and distributing them to our product teams for testing and submission has been amazingly smooth.

When you're a small team, managed workflows feel like training wheels. You assume you'll outgrow them. We haven't. The team is bigger, the apps are more complex, the user base is in the millions and we're still fully managed. The benefits scale with your app and your team.

The upgrade path between SDK versions has also been smoother than expected. Upgrading a single app is one thing. Upgrading multiple apps that share code is a coordination challenge. Expo's upgrade tooling and migration guides make this significantly less painful than it could be.

And honestly, the pace of innovation from the Expo team keeps impressing us. They've consistently been ahead of the curve. File-based routing was a great example of that. They saw where the developer experience was going and got there early.

What's next?

Now that the era of agentic coding has officially taken over, Expo is pushing that front too. We're eagerly expecting the official launch of Expo Agent, which we believe will continue to power and accelerate our client-side development process. The idea of AI-assisted development built directly into the framework we already use is exactly the kind of forward-thinking move that made us bet on Expo in the first place.

On our side, we're continuing to expand our product portfolio. The AI consumer space is still growing fast and we see big opportunities in video generation and real-time AI experiences on mobile. All of it will be built on Expo.

If you're a small team somewhere thinking about building consumer apps, here's what I'd say: don't overthink your stack. Pick Expo, start shipping and focus your energy on the product. The framework will scale with you. Ours did, from a tiny team in Istanbul to apps that hit number one globally. And we're just getting started.

FERASET is an AI consumer app studio based in Istanbul. Our apps are available on the App Store and Google Play. As is standard practice among AI app studios and mobile gaming studios, our apps are published under different developer accounts for various operational purposes, so you won't find them all under the FERASET name.

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.