Someone in the Expo community (Aras Diler) shipped a social app called udictio and wrote up how the App Intents work. Good read if you've wondered how far you can push native iOS features while keeping one Expo project as the source of truth.
https://expo.dev/blog/building-a-native-first-social-platform-with-expo
eas integrations:convex:connect
That's it. The command provisions Convex and sets your env vars for local dev and builds in one shot. useQuery updates itself when the data changes.
Full details are in the new blog from Wayne Sutton (from convex):
We talked to a founder named Deepak who runs a company called Social Spaces. The company is one person. He designs the app, engineers it, does the business paperwork, and ships the builds. The product is Pollzy, a social app where you create polls, people vote, and you compare your results against friends.
The thing he said that we keep thinking about: this exact company would have failed five years ago, and not because of effort. A cross-platform mobile product has about six specialist disciplines baked into it, and nobody has all six. The old solution was hiring, which needs money, which needs traction, which needs the app you haven't built.
Two things changed, and they fix different halves of the problem.
AI closed his knowledge gaps. His phrasing: "AI basically allows me to be the architect I want to be." Note that's not a claim about code generation volume. It's that the systems he'd never touched stopped being blockers, so he could stay at the decision-making level he's actually good at.
But writing code and getting a signed binary into two app stores are unrelated problems, and the second one is where solo projects die. That's the half he solved with Expo. His description: "All I run is two commands and it builds an iOS version and an Android version and then autosubmits it to the store for approval." Roughly eas build --platform all and eas submit --platform all. The builds run on hosted workers, including macOS runners for iOS, so he owns no Mac build machine and maintains no Xcode versions. Signing credentials are generated and stored for him.
Result: a new build in front of testers every couple of days, 5 to 10 minutes from deciding he likes a feature to people using it. That cadence is the part that matters. When shipping costs an afternoon you batch changes and learn slowly. When it costs ten minutes you ship the risky idea Tuesday and know by Wednesday.
Software Mansion put out a walkthrough on the Expo blog about deferred deep linking, and it's worth a read if you've ever dealt with the Installation Gap.
The setup: standard deep links (Universal Links, App Links) are fine when the app is already installed. But when a new user goes through the App Store or Play Store first, iOS and Android drop the URL context, so the app opens with no idea which link brought them in.
Attribution tools have handled this for years, but deep linking is a side feature for them. You get a raw URL in a callback and end up writing the glue to connect it to your router yourself, which means dealing with lifecycle timing, duplicate navigation, and auth gate races.
Detour comes at it from the navigation side. It resolves the link inside Expo Router's +native-intent.tsx before the first screen renders, so there's no post-mount useEffect race. DetourProvider keeps the intent in memory through your auth gate and fires navigation once, so a /login redirect doesn't eat it. Matching is deterministic on Android (Install Referrer API) and probabilistic on iOS, since Apple treats the App Store as a privacy boundary.
Detour 1.0 covers custom domains and SDKs for React Native, Flutter, and native. They're looking for feedback from the community.
Full post: https://expo.dev/blog/deferred-deep-linking-the-right-way
Docs: https://docs.swmansion.com/detour/
If you've ever uninstalled your production app just to reproduce a bug in your dev build, then reinstalled it, then done it again a day later, app variants fix that for good.
A device keeps one app per identifier, so if dev and production share a bundle ID, installing one replaces the other. App variants give each build its own identity, so they coexist as separate apps.
The setup, roughly:
β Move from a static πππ.ππππ to a dynamic πππ.ππππππ.ππ that reads one env var, π°πΏπΏ_π π°ππΈπ°π½π, and switches the bundle identifier / package name per variant. Keep πππ.ππππ as the base layer since EAS tooling writes into it.
β Set π°πΏπΏ_π π°ππΈπ°π½π per build profile in πππ.ππππ, or move it to EAS environment variables and pull it locally with πππ πππ:ππππ so there's one source of truth.
β Give each variant its own icon so you stop tapping the wrong app.
β Set ππππΆππππππππππππππ to development only, otherwise every installed variant answers the same ππ‘π+<ππππ> scheme and the QR code may open the wrong build.
One gotcha worth knowing: a development build (with expo-dev-client) pulls its config from the dev server every launch, so if you start the server as preview and open your dev build, it'll happily run with preview's values and no error. Match the server's variant to the build you open.
Full writeup with the config snippets and EAS Update channel setup: https://expo.dev/blog/app-variants-side-by-side
We did a case study about this app (Wellspoken) a while ago, and then we kept in touch while the app exploded.
So we followed up with the builder to see if he would share his secrets for driving usage, reviews, and revenue. They are all in the blog post from today. There is a lot of actionable stuff in here.
A few key thoughts:
β The product does the heavy lifting. Copycats clone the screens and convert an order of magnitude worse, so buying traffic before the product earns it is wasted spend.
β ASO is mostly fundamentals: retention feeds ranking, keep the listing tuned to how people search, and use Apple Search Ads for keywords you can't rank for yet.
β For UGC, the viral clip and the converting clip are often different videos. Worth tracking separately.
β The paywall was won through relentless A/B testing (copy, pricing, trial length, placement), not one big redesign.
β Review prompts convert best when triggered at a genuine high point. They used ππ‘ππ-πππππ-ππππππ to keep it in-app and gated it behind real engagement.
Here's the link: https://try.expo.dev/reddit-wellspoken
Most AI tooling is noise. After a lot of building, three things consistently earn their place: skills, MCP servers, and context discipline. Here's the tactical version, with a habit tracker as the example.
Skills: instruction files an agent reads on demand
A skill is a folder with a single ππΊπΈπ»π».ππ file. The agent only pulls in the full instructions when a task needs them, so it's cheap on context. Only the short description loads up front. Install the Expo set from expo.dev/skills, then call one by name (slash command) or let the agent invoke it on its own. Works with Claude Code, Cursor, and Codex.
MCP servers: hands outside the editor
When the answer lives in a system the agent can't see from the repo, that's MCP. The Expo MCP server reads your EAS builds, logs, and crash reports, and its local tools drive a simulator (screenshots, taps, native and JS logs). Free for everyone now. One warning: MCP servers are token-heavy. Every tool definition loads up front. Only connect one for a service the project actually uses.
Context discipline: the part most people skip
Past a certain fill level the model degrades and each reply costs more. Watch usage with a status line like ccstatusline. Rule of thumb: stay under 50%. Two habits that help are one conversation per outcome, and branching a new thread when the task changes (plan, spec, build) instead of piling onto one.
One more tactical tip: run ππ‘ππ ππππππ before you burn tokens debugging a failed build. It catches dependency version mismatches in seconds.
Full write-up and video: https://expo.dev/blog/how-to-build-mobile-apps-with-ai-the-three-tools-that-actually-matter. Curious what skills other people are reaching for.
We're working on ππ‘ππ-πππ-πππππππ module, which will allow you to add AppIntent (Apple Intelligence, App Shortcuts, Siri) support to your Expo app.
Open repo is here: https://github.com/expo/expo/pull/47207
You already know your company needs a mobile app. The bar for building one is surprisingly low. The hard part is convincing leadership to let you build it.
So we put together the argument you can actually bring to that conversation. A few of the numbers that tend to land in a budget meeting:
β 94% of smartphone time is spent in apps, 6% on mobile web
β Apps convert 3x higher than mobile web (157% higher for e-commerce, 307% for on-demand)
β Push notifications get a 10% CTR vs 1% for email
β App users carry 2.8 to 5x the lifetime value of web-only users
The post also breaks down use cases by industry and how to frame the ask so it lands as a revenue conversation, not a "we should build an app" wish.
The cost/timeline objection is the one worth addressing head on. One React codebase to both platforms, cloud builds, and OTA updates change the math a lot from the old "hire two native teams" days.
We'd like to hear if this helps any of you sell it internally, or what objections your boss threw back. Or if you've already sold the idea and you have some knowledge to share from your experience (we'll update the blog and credit you!)
https://expo.dev/blog/how-to-make-the-case-for-a-mobile-app-at-your-company
Building iOS widgets and Live Activities from a React Native app has historically meant a separate Xcode target, App Groups, SwiftUI layout code, and keeping that extension in sync with the rest of your app.
As of SDK 56, ππ‘ππ-π ππππππ is stable. You write widgets and Live Activities as React components with Expo UI, and Continuous Native Generation handles the Widget Extension target, the App Group config, and the SwiftUI scaffolding. There's no separate iOS project to maintain.
This is the same library that shipped as alpha in SDK 55, hardened and promoted. The core idea is unchanged: write widgets in React, let the system render them through SwiftUI, manage updates from your Expo app. What changed:
β Widgets and Live Activities receive their full environment through πππππππ΄ππππππππππ (widget family, content margins, color scheme, rendering mode, accessibility context)
β No pre-rendering in the app. The widget bundle renders independently with the context it needs
β Configurable widgets, so users pick what a widget shows from the gallery
β Better error handling
The 'widget' directive marks a function body as a widget render context. It runs in a sandboxed JS runtime separate from your main app, and the Expo UI components map directly to SwiftUI primitives, so rendering is native while your logic stays in TypeScript.
If you want a starting point: pick one piece of info users benefit from seeing outside the app, ship that widget first, then add a Live Activity if you have a flow with a clear start, active updates, and an end. Feedback and bug reports go to Discord or the expo/expo GitHub issues.
Writeup with the code sample: https://try.expo.dev/reddit-widgets
When an app feels slower, there is almost always a real cold-start regression behind it, on a specific build, on specific devices. The problem has never been the hunch, it has been proving it. By the time the feeling turns into a complaint or a churn dashboard, the release that caused it is days back.
Observe is built to close that gap. It measures how your app actually performs for real users across real devices, networks, and conditions, so the workflow shifts:
β Ship a release and see by that evening whether startup or a screen got slower, broken down by device, OS, region, and network
β Each regression is tied to the build or update that introduced it, so you skip the detective work
β Full distributions (median, P90, P99), since the slowest 10% of sessions is where churn actually lives
β Per-screen metrics for Expo Router and React Navigation, plus OTA update download times
β Every metric is queryable from the CLI with --json, so you can pipe it into an agent and have it investigate a regression for you
Setup runs about five minutes on Expo SDK 56, no custom instrumentation. It can be even faster if you use the Observe Skill (linked in the blog below)
Observe is free during the open beta, including the first 10,000 monthly active users. When the beta ends there will be paid plans that scale with MAUs plus a free tier up to 1,000 MAUs, and they have committed to at least 60 days notice before any pricing kicks in.
We're biased. We build one of the services in this CI/CD comparison. And it's the only CI/CD built specifically for React Native. So it should be a good fit for people in this subreddit.
But we endeavor to be fair in this comparison. We point out where other tools win. Let us know if it sounds like we're off on anything.
The thing we kept coming back to is the: most CI reruns a full iOS build even when you only touched JavaScript. Our CI/CD Workflows service knows when not to build.
Here's how it works:
β Checks whether your native layer actually changed
β If it didn't, skips the full build
β Repacks the last binary with the new JS on top
A ~15 min build becomes ~2 min. No other CI/CD has this built in.
What else matters when picking a CI/CD:
β Build speed on Apple Silicon (M4 Pro ~6 min vs ~20 on M1)
β Code signing and credentials, where most teams lose time
β Artifact storage and sharing
β How much YAML you maintain
β Pricing you can predict before the first invoice
Here's the full breakdown: https://try.expo.dev/mobile-cicd-reddit
SDK 56 distributes many Expo modules as precompiled XCFrameworks through npm. Instead of compiling every module from source on every build, your app links binaries that were compiled once. It's on by default, locally and on EAS Build, with no migration steps. You can disable it if you need to build from source.
The honest caveat: how much faster your builds get depends on coverage. React Native (precompiled since SDK 55) and Expo modules are always covered, but only the most widely used third-party native libraries are. If your app leans on less common native deps, those still compile from source.
The more interesting part is what's underneath. CocoaPods goes read-only in December 2026, and this work is the first step toward Swift Package Manager. Getting there wasn't trivial:
β Framework interfaces can't expose headers from non-modular dependencies, so public APIs that leaked React Native internals had to be refactored
β SPM is strict about mixed-language targets, which meant breaking long-standing Swift β Objective-C dependency cycles in expo-modules-core
β React Native's XCFramework support still expects the CocoaPods-generated header layout, so Clang VFS overlays present a virtual header structure to the compiler without reorganizing the source tree
β Package.swift manifests are auto-generated by tooling rather than maintained by hand
SDK 56 supports CocoaPods and SPM side by side, so nothing breaks while the ecosystem catches up. Full writeup: https://try.expo.dev/precompiled-reddit
Happy to answer questions.
SDK 56 includes a compiler plugin built on the K2 API that bakes type metadata and Record structure directly into bytecode. The result: 70% faster module initialization, 30% faster time to first render, and Record conversions running 6Γ faster than SDK 55.
β App developers: automatic, no changes needed
β Module maintainers: add @ππ₯π©ππ’ππ―ππππππ€π§π to get the Record speedup; skip it and the module falls back gracefully
The post covers why codegen (kapt/KSP) wasn't the right call and how the K2 IR API changed what was possible. There's also a companion post on the Swift/JSI work on iOS.
We've published a migration guide for moving off expo/vector-icons.
expo/vector-icons was originally built because the community react-native-vector-icons packages didn't work in Expo Go. They do now. They integrate directly with expo-font and work in Expo Go, dev builds, all platforms. The wrapper is extra complexity at this point.
We recommend switching to react-native-vector-icons/* packages. Formal deprecation of expo/vector-icons comes in a future SDK release, but it stays maintained until then.
For most projects, migration is two commands:
npx icons/codemod
npx expo doctor
The codemod handles the import rewrites. A few things worth checking manually: custom icon sets, anything using createIconSetFromIcoMoon, and watch out for mixing old and new packages in the same project. That can cause icons to render as ? or empty squares β expo doctor will flag it if you do.
Around 60% of EAS Build apps use expo/vector-icons today. Happy to answer questions here.
Full post: https://try.expo.dev/vector-icons-reddit
Your next native module can live right next to your App.tsx.
SDK 56 ships two experimental features that cut down the busywork around Expo modules.
β Inline modules let you write Swift and Kotlin directly in your project, next to your app files. No standalone package to set up first.
β expo-type-information reads your Swift module and generates the matching TypeScript interface, so you stop maintaining a parallel definition by hand.
Inline module setup is short. Add the directories that hold your modules to watchedDirectories in the app config, then run npx expo prebuild to sync the native projects:
{
"expo": {
"experiments": {
"inlineModules": {
"watchedDirectories": ["app"]
}
}
}
}
Now any Swift or Kotlin file in that directory or its subfolders gets compiled and autolinked. You reach it from JS with requireNativeModule('InlineModule'), or requireNativeView for a view.
For types, the inline-modules-interface command finds every Swift inline module and writes two files per module: a .generated.ts file with the type info, overwritten on each run, and a stable .tsx file that re-exports the interface and is safe to edit. Run it in watch mode and the types track your changes to the native side.
Two caveats:
Both features are experimental and the team is after feedback. The full post digs into how prebuild, autolinking, and the SourceKitten-based parser actually work: https://try.expo.dev/native-code-reddit
We (mostly Brent Vatne) helped grow React Navigation from the π½ππππππππππ΄π‘ππππππππππ era into the navigation library most React Native apps run today. But, as Expo Router matured, we kept hitting cases where we needed deeper control over internals shared with the rest of React Nav. We talked with Satyajit Sahoo, who runs React Nav now, and forked the parts Expo Router uses. Both libraries keep going in their own direction.
For your codebase:
β Update imports from @πππππ-ππππππππππ/* to ππ‘ππ-ππππππ/πππππ-ππππππππππ
β Run our codemod for most of the migration
β A compatibility layer keeps libraries working for one release cycle
Also new in v56:
β Streaming SSR via ππππππππ_ππππππππππππππππππ
β generateMetadata for per-route HTML metadata
β Type-safe loaders: πππππππππππππ»πππππ and πππππππππππππ»πππππ
β Android toolbar with left, right, and bottom placements
β Native Tabs gains a ππππππππ property, with stable status coming next release
If you're upgrading an app use our Migration guide + codemod. All new projects will have this built in beginning with SDK 56.
SDK 56 ships first-class integration with πππππ-ππππππ-π πππππππ, which means @ππ‘ππ/ππ components can update shared state synchronously, without ever hopping to the JS thread.
The immediate payoff is input masking that just works. A credit card field can format πΊπΈπΊπΈπΊπΈπΊπΈπΊπΈπΊπΈπΊπΈπΊπΈ into πΊπΈπΊπΈ πΊπΈπΊπΈ πΊπΈπΊπΈ πΊπΈπΊπΈ on the same frame the keystroke arrives. No unmasked flicker, no async round-trip.
How it fits together:
β ππππ½ππππππππππ creates an πΎππππππππππππππ that lives on native (πΎππππππππππΎπππππ on iOS, πΌπππππππππππ on Android), observed by both SwiftUI and Compose
β Worklet callbacks like πππππ‘ππ²πππππ execute directly on the UI thread when the native view fires its event
For developers coming from SwiftUI, the API maps almost 1:1. ππππ½ππππππππππ plays the role of @πππππ, πππ‘π={πππ‘π} is the equivalent of πππ‘ππ΅ππππ(πππ‘π: $πππ‘π), and the worklet πππππ‘ππ²πππππ mirrors .πππ²πππππ(ππ:). The same shape works on Compose with πππππππππππππΎπ and πππ πππππ²πππππ.
πππ‘ππΈππππ is the first component wired up. More form controls will gain sync callbacks in upcoming releases.
Details are in the blog:
Expo UI hit stable this cycle. Quick rundown of what's in the release:
β Universal layer. One import from u/expo/ui gives you SwiftUI on iOS and Jetpack Compose on Android. Each universal component wraps the real platform primitive, no JS reimplementation sitting in between. Layout, text, inputs, controls, sheets are all in scope.
β Stable native APIs. Both the SwiftUI and Compose surfaces are audited so component, prop, and modifier names map 1-to-1 with Apple and Google docs. Most samples you find online are roughly a search-and-replace away from compiling.
β Drop-in replacements for seven common community packages under u/expo/ui/community. Near-API-compatible, mostly a one-line import swap, fewer native deps to track on SDK bumps.
β Extensibility. You can build your own SwiftUI and Compose views and modifiers, and Expo UI handles the layout, prop, and event plumbing.
β Plus Material 3 dynamic colors via useMaterialColors, the full Material Symbols catalog via u/expo/material-symbols, and useNativeState for UI-thread-driven, flicker-free controls.
Naming note worth calling out for RN folks: it's Switch, not Toggle. It's Column / Row, not HStack / VStack. The universal layer leans toward names a React Native dev already types every day. The SwiftUI-flavored names still live under u/expo/ui/swift-ui for the moments you want them.
Expo UI sits alongside React Native View / Text, Skia, WebGPU, and DOM components inside the same view tree. Use the right primitive per screen, mix them inside a single one.
Try it:
npx create-expo-app@latest --template default@sdk-56
Updated hot-chocolate showcase (now universal, runs on iOS, Android, web) and ExpoUITV (Apple TV + Android TV) are linked in the post.
Full writeup: https://try.expo.dev/ui-reddit
It's only been two months since SDK 55, and the cycle ended up packed end to end. React Native 0.85 and React 19.2 are under the hood. Here's a link to the release notes: https://try.expo.dev/sdk-56-reddit
And here's a list of some highlights that are important to note:
β Expo UI is stable on both iOS and Android. SwiftUI and Jetpack Compose APIs are production ready, with universal components for shared interfaces and drop-in replacements for libraries like u/react-native-community/datetimepicker, u/react-native-picker/picker, and u/gorhom/bottom-sheet.
β iOS clean builds drop ~16% from precompiled Expo modules (XCFrameworks shipped with the SDK). EAS Build adds another ~20% on top from precompiled community libraries like Reanimated and Screens. Roughly a minute and a half of your life back on every clean build, give or take.
β Android cold starts are ~40% faster thanks to a new Kotlin compiler plugin in expo-modules-core that replaces reflection with build-time code generation.
β Expo Router is decoupled from React Navigation. Expo Router used to depend on u/react-navigation/*. After collaborating with the React Navigation team, the parts Expo Router builds on have been forked into Expo Router so both libraries can evolve independently. You can still use React Navigation directly if you prefer it. A codemod handles most of the import migration.
β Inline native modules: write Swift and Kotlin files right in your project tree alongside your TS, with auto-generated TypeScript interfaces from a CLI watcher. Most curious to see what people build with this.
β Hermes v1 is the default JS engine. Hermes bytecode diffing for EAS Update is on by default. In the 24 hours before this post, diffed bundles averaged 58% smaller than the full bundle.
β iOS Widgets are stable, expo-status-bar and expo-navigation-bar now share a consistent declarative API, and the redesigned expo-calendar, expo-contacts, and expo-media-library are stable.
β Brownfield: multiple isolated Expo apps in one host, plus host apps can register their own Turbo Modules with the inner React Native runtime.
β AI scaffolding: AGENTS.md, CLAUDE.md, and .claude/settings.json ship in new projects by default.
Questions welcome. Office hours are on Wednesdays at 12PM Pacific on Discord if you want to talk through upgrading.