MAR 4, 2026
We're building Expo Observe, a new way to understand how your app performs in the real world.
You ship your app, but do you know how fast it actually launches for your users? What about users on older devices or slower networks? When you push an update, does performance improve or regress? Did adding all those new libraries slow down your app?
These questions are hard to answer without dedicated tooling, and existing solutions often require significant setup or don't integrate well with the React Native ecosystem.
Debugging performance in React Native has been a long-standing difficulty: a challenge the React Native team have recently addressed with the new DevTools and Performance panel, but these are development-time tools. With Observe, we focus on tracking performance in production.
In this initial Preview release, we've focused on tracking startup metrics for your app:
Once integrated, Observe collects these metrics from real user sessions and gives you tools to understand them:
This is just the beginning. We're starting with startup metrics because they're critical to user experience and retention, but we have plans to expand Observe's capabilities based on what we learn from early testers.
We're looking for developers to help us test and shape Expo Observe. If you're interested in early access, please join the waitlist.
Date: March 3, 2026
Author: Dan Kelly
You may have received (or will soon receive) an email from GitHub asking you to approve updated permissions for the Expo GitHub App. This is a legitimate request from Expo.
Action required: Click approve when you see the GitHub email.
Expo is building new features for the Expo GitHub App, and GitHub's permission model requires apps to request expanded access before using new API capabilities. Expo needs "Repository Administration" access to enable automatic EAS project setup for new and existing repositories.
Specific feature details will be shared as they roll out.
The Expo GitHub App connects GitHub repositories to EAS. When installed and linked to an Expo project, it enables:
These existing features will continue to work regardless of whether you approve the new permissions.
Nothing breaks. If you choose not to approve the updated permissions, your current EAS Workflows, builds, and updates will continue to function normally. You can also set up a new Expo account, connect it to an existing GitHub project, and run workflows without issue.
The only limitation is access to new agentic features as they become available. Permissions can be approved later when ready.
Organizations with strict access policies should know:
For questions about specific permission scopes, contact security@expo.dev or Discord.
The page shows an error message indicating that the requested release notes content for Expo SDK 55 could not be loaded properly. The actual release notes content is not available.
FEB 6, 2026 | By Mustafa Abban
Expo MCP Server now includes tools that allow your AI assistants to interact directly with your EAS Builds and Workflows. These tools enable you to manage builds, trigger workflows, and automate debugging issues, all through interacting with your favorite AI-assisted development tools like Claude Code, Cursor, and VS Code.
You can now ask your AI assistant to:
build_info Check build status: "Get the status of my latest iOS build"build_list List builds: "What are my recent builds"build_logs View build logs: "Show me the logs for the failed build"build_run Trigger new builds: "Run a production build for iOS"build_cancel Cancel running builds: "Cancel the build that is currently in progress"build_submit Submit to app stores: "Submit the latest build to the App Store"Manage your entire workflow pipeline through conversational prompts:
workflow_create Create workflows: "Create a workflow for building and deploying"workflow_info Monitor runs: "Get the status of the latest workflow run"workflow_list List workflows: "What are my recent workflows"workflow_logs View logs: "Show me the logs for the build job in the workflow"workflow_run Trigger runs: "Run the build-and-deploy workflow"workflow_validate Validate configurations: "Validate my workflow file"workflow_cancel Cancel workflows: "Cancel the running workflow"Retrieve recent workflow runs and investigate the root cause behind their failures:
> what are my recent workflows
Here are your recent EAS workflows:
| Date | Workflow | Status | Branch | Commit |
|--------------|----------------------|-------------|--------|----------------|
| Feb 4, 2026 | Android Build | ✅ SUCCESS | main | 186dbaa - "ex" |
| Jan 30, 2026 | iOS Build and Submit | ❌ FAILURE | main | 186dbaa - "ex" |
| Jan 28, 2026 | iOS Build and Submit | ❌ FAILURE | main | 186dbaa - "ex" |
| Jan 28, 2026 | Android Build | ⚪ CANCELED | main | 186dbaa - "ex" |
Example scenario with interacting with build tools to inspect and rerun a build:
> what are the logs of my recent build
Here's a summary of the logs for your most recent Android build:
Build Summary
- Build ID: 60e2fdf1-fc7a-4b08-89c3-fe53bb2ea311
- Status: ✅ SUCCESS
Build Environment
- Machine: AMD, 4 vCPUs, 16 GB RAM
- Image: ubuntu-22.04-jdk-17-ndk-r26b
- Node.js: 20.19.2
- Java: 17
- Bun: 1.2.4
- NDK: 26.1.10909125
Build Phases
| Phase | Result |
|----------------------------|-----------------------|
| QUEUE | ✅ success |
| SPIN_UP_BUILDER | ✅ success |
| RUN_GRADLEW | ✅ success (14m 55s) |
| UPLOAD_APPLICATION_ARCHIVE | ✅ success |
| SAVE_CACHE | ✅ success |
Output
- APK Size: 81.1 MB
- Location: app-release.apk
- Gradle Tasks: 862 executed, 1 up-to-date (863 total)
Cache Stats
- Cache Hit Rate: 25% (216/864 hits)
- Cache Size: 0.04 GB / 5.00 GB
To use these tools, you'll need:
Learn more in the MCP documentation.
JAN 26, 2026
By Mustafa Abban and Stanisław Chmiela
EAS supports build caching, which can speed up subsequent builds by up to 30% on both Android and iOS builds. Build caching is available to all users at no additional cost, whether you're on a free or paid plan.
Builds on EAS now support saving and restoring compiler caches with ccache. ccache is a compiler cache that speeds up recompilation by caching the results of C/C++ compilation. The saved cache will store shared output between builds such as .o files, compilation results for native libraries used by React Native, Hermes, or other native modules, and more.
From initial results on successful cache hits, we've seen up to 30% build speed increases on both Android and iOS builds and plan to improve it further.
The following environment variables control caching behavior:
EAS_USE_CACHE: Enables saving and restoring cache on build jobs. By setting to 1, it will enable both saving and restoring the cache during a build job. By setting to 0, it will disable both saving and restoring the cacheEAS_RESTORE_CACHE: Controls restoring the cache at the beginning of a build. Set to 1 to enable or 0 to disable.EAS_SAVE_CACHE: Controls whether to save the build cache at the end of a build. Set to 1 to enable or 0 to disable.Prerequisites
Steps
EAS_USE_CACHE with a value of 1. Then select every environment, typically: production, preview, and development.The cache key uses lock files to create a unique key based on your dependencies. When dependencies change, a new cache will be created while still allowing fallback to previous caches using a key prefix.
You'll also see both save and restore-cache steps appear in your build job, along with performance stats on the hit rate of the cache.
Setting the environment variables will automatically add the cache steps to your builds. You can also add this to your custom builds and workflows by setting the restore step before the build step and respective save step after.
Workflows
Use functions eas/restore_build_cache and eas/save_build_cache to apply ccache automatically.
- uses: eas/restore_build_cache
- uses: eas/build
- uses: eas/save_build_cache
Functions eas/restore_cache and eas/save_cache allow for using the service for other cache purposes. Users can define their own key pattern and file path. Here is an example of using them for ccache, equivalent to the functions above.
- uses: eas/restore_cache
with:
key: android-ccache-${{ hashFiles('package-lock.json') }}
restore_keys: android
path: /home/expo/.cache/ccache
- uses: eas/build
- uses: eas/save_cache
with:
key: android-ccache-${{ hashFiles('package-lock.json') }}
path: /home/expo/.cache/ccache
Custom build
build:
name: Build with ccache
steps:
- eas/checkout
- eas/restore_build_cache
- eas/build
- eas/save_build_cache
Access restrictions provide cache isolation and security by creating logical boundaries between different Git branches or users. It is important for security of yours and your users to understand and leverage them when building your app.
When a build is run from GitHub, caches get scoped to the branch the build is running from. A build can restore caches created in:
main or master)If a build doesn't restore a user-scoped cache, it will automatically fallback to restoring caches published from GitHub builds triggered on the default branch. This allows builds to benefit from caches created by trusted sources even when no user-scoped cache exists yet.
When a build is triggered from eas-cli, caches are scoped to the user running the build. These user-scoped caches allow for isolation so that modifications to the build and its cache are not unintentionally shared during development or between users.
When a single user-actor is shared between multiple people (such as when using access tokens or triggering builds from GitHub Actions), user-scoped cache rules still apply. This means that builds operating under that shared account will no longer have isolated caches and run the risk of sharing unintended artifacts. We recommend avoiding this by having designated jobs to only save clean caches, while the development builds only restore.
You can configure specific jobs to publish clean, new caches by disabling cache restoration and only saving the cache by leveraging the provided environment variables. These examples go over a few approaches to do so.
Disable restoring cache for production build profile
{
"build": {
"production": {
"env": {
"EAS_RESTORE_CACHE": "0",
"EAS_SAVE_CACHE": "1"
}
},
"preview": {
"env": {
"EAS_USE_CACHE": "1"
}
}
}
}Only save cache from designated jobs
To ensure only trusted sources publish cache, you can configure workflows to only save cache from specific jobs on the main branch:
jobs:
build_production:
type: build
if: ${{ github.ref_name == 'main' }}
env:
EAS_RESTORE_CACHE: '0'
EAS_SAVE_CACHE: '1'
params:
platform: android
profile: production
Learn more about the usage and details of build cache in the documentation.
We'd love to hear how build caches work for you. If you experience issues, please send an email to workflows@expo.io.
Learn about the changes, how to try it out, and how to give feedback.
DEC 15, 2025
Workflows insights aggregates data from all of your workflow runs in the insights tab on the Expo dashboard. You can monitor key metrics like success rates, active runs, and failure counts, while observing trends over time to understand how your workflows are performing.
Workflows insights collects and visualizes data about how your workflows are performing. This includes:
The graphs on the dashboard show runs over time and their statuses. This view allows you to spot patterns over time, like if a change introduced a regression or a bug fix solved a job's error. Below the graph, there's a table, which you can filter and search. It shows data about specific workflows and their runs, so that you can zero-in on specific workflows.
Workflows insights are valuable when you have a team all using shared CI/CD workflows to build, test, and release your app. For example, if you have end-to-end tests as a part of your release process, this dashboard can help you easily identify when a test job started erroring, which is a vital clue when debugging which change introduced an issue.
This dashboard is also helpful when you want to analyze CI/CD usage across your organization. You might spot that a vital workflow is taking longer than you'd like, which could lead to an effort to optimize that workflow to run faster. Workflows insights turns anecdotal data into quantitative data that helps you and your team make decisions.
Workflows insights is available to organizations on the Production and Enterprise plans. You can access insights by going to your project's insights tab.
Once there, you can customize the timeframe from 1 hour to 90 days of data. You can also export your data directly if you'd like to find insights of your own.
Workflows insights makes it easier to maintain reliable workflows at scale, giving you the visibility you need to keep your CI/CD pipelines healthy.
December 10, 2025 | By Stanisław Chmiela
The Slack job sends a message during a workflow run to your Slack workspace. Since this is an API call to Slack's servers, the Slack job is configured to skip spinning up a VM and instead send the API call immediately when this job runs. This means your Slack messages will be sent nearly instantaneously.
To send a message to a Slack channel, add a job with type: slack to your workflow:
name: Send message
jobs:
send_slack_message:
name: Send Slack message
type: slack
params:
webhook_url: {{ env.SLACK_WEBHOOK_URL }}
message: "Hello Slack! 🎉"The webhook URL can be obtained from your Slack workspace's app settings.
You can send a message to a channel conditionally when a build fails:
name: Build Notification
jobs:
build_ios:
name: Build iOS
type: build
params:
platform: ios
profile: production
notify_build:
name: Notify Build Status
needs: [build_ios]
type: slack
params:
webhook_url: {{ env.SLACK_WEBHOOK_URL }}
message: 'Build completed for app ${{ after.build_ios.outputs.app_identifier }} (version ${{ after.build_ios.outputs.app_version }})'You can also compose rich Slack messages. This is great for if your team coordinates testing or releases from a shared Slack channel that gets various types of messages:
name: Rich Build Notification
jobs:
build_android:
name: Build Android
type: build
params:
platform: android
profile: production
notify_build:
name: Notify Build Status
needs: [build_android]
type: slack
params:
webhook_url: {{ env.SLACK_WEBHOOK_URL }}
payload:
blocks:
- type: header
text:
type: plain_text
text: 'Build Completed'
- type: section
fields:
- type: mrkdwn
text: "*App:*\n${{ needs.build_android.outputs.app_identifier }}"
- type: mrkdwn
text: "*Version:*\n${{ needs.build_android.outputs.app_version }}"
- type: section
fields:
- type: mrkdwn
text: "*Build ID:*\n${{ needs.build_android.outputs.build_id }}"
- type: mrkdwn
text: "*Platform:*\n${{ needs.build_android.outputs.platform }}"
- type: section
text:
type: mrkdwn
text: 'Distribution: ${{ needs.build_android.outputs.distribution }}'Learn more about the Slack job type in the pre-packaged jobs documentation.
Date: DEC 5, 2025
Authors: Phil Pluckthun, Vojtech Novak
Here's what you need to know when it comes to if your Expo app is affected by recent security vulnerabilities in React Server Components and how to upgrade it to stay protected.
UPDATED: on January 26, new DoS mitigations were published. The mitigation instructions are the same as for the previous security patches, and we have again restricted our peer dependency ranges in:
expo-router@55.0.0-preview.5 and jest-expo@55.0.6 for SDK55expo-router@6.0.23 and jest-expo@54.0.17 for SDK 54expo-router@5.1.11 and jest-expo@53.0.14 for SDK 53UPDATED December 11 and December 12, 2025: Three new vulnerabilities (CVE-2025-55184, CVE-2025-55183, and CVE-2025-67779) were disclosed on December 11 affecting React Server Components. We have released additional patches to address these issues:
expo-router@6.0.19 and jest-expo@54.0.16 for SDK 54expo-router@5.1.10 and jest-expo@53.0.13 for SDK 53expo-router@7.0.0-canary-20251211-7da85ea and jest-expo@55.0.0-canary-20251211-7da85ea for canaryLearn more in the react.dev blogpost.
Follow the updated mitigation steps below, which now include newer react-server-dom-webpack versions to address the total of four vulnerabilities.
Previously, on December 3, an unauthenticated remote code execution vulnerability in React Server Components was disclosed as CVE-2025-55182. You may learn more about the vulnerability in this react.dev blogpost.
First, you only need to take action if you're using experimental RSC or Server Functions support. If you use Expo only for client-side Android, iOS, and web, then you are not affected. API routes are not affected.
Expo projects can be vulnerable through a dependency on react-server-dom-webpack 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1. Projects that do not use RSC typically won't even have a dependency on the vulnerable package.
To mitigate the vulnerabilities in your project's dependencies, you need to use a version of react-server-dom-webpack according to the list below:
react-server-dom-webpack@19.1.4 for SDK 54 (with react 19.1.x)react-server-dom-webpack@19.0.3 for SDK 53 (with react 19.0.x)react-server-dom-webpack@19.2.3 for canary (with react 19.2.x)You can install the appropriate version manually to mitigate the issue. If you're using npm: Due to peer dependencies errors, you may have to add react-server-dom-webpack to your package.json:overrides.
We have published patches for Expo SDK 53, 54 and canary that restrict our peer dependency ranges to only allow the patched react-server-dom-webpack versions mentioned above. Earlier versions of Expo are not affected.
These patches were published as listed below:
Additionally, we have updated our version recommendations in the expo CLI. Running expo install --check will recommend updates to react-server-dom-webpack, if you directly depend on an affected version. The React team has deprecated the affected versions, which means your package manager should additionally flag these versions, if they're still installed in your project.
After upgrading, verify that your project depends on the expected version of react-server-dom-webpack using npm explain react-server-dom-webpack / yarn why react-server-dom-webpack and similar, depending on your package manager.
Keep in mind that specific versions of react-native require specific versions of react, to prevent a runtime version mismatch. Always follow the react (and react-dom) version recommendations from expo install --check to prevent mismatches.
If you're using a monorepo and must update react, SDK 54 allows you to keep your Expo app on the correct react version by enabling expo.experiments.autolinkingModuleResolution: true in your app.json. This helps if other web apps or projects must be updated to a newer version of react while keeping your React Native / Expo app on an older version.
The react package itself does not contain RSC functionality and is hence not affected by these vulnerabilities.
expo-router and jest-expo according to the table above.react-native require specific versions of react.react for an Expo app and other web projects.November 24, 2025
By Byron Karlen
Organizations on Production and Enterprise plans can now require members to enable two-factor authentication (2FA). For organizations with SSO enabled, this requirement only applies to non-SSO users.
2FA adds an essential layer of security to your organization by ensuring that compromised passwords alone cannot grant unauthorized access to your projects, credentials, and builds. By requiring 2FA at the organization level, you enforce consistent security standards across your team.
Organization owners and admins can enable this requirement from the account's settings page.
November 21, 2025
By default, all projects have three environment variable environments: development, preview, and production. This setup works well for most hobby and small projects, but we've heard from larger teams and those with more complex workflows that they need additional flexibility. We're excited to announce that we've just shipped the ability to configure custom environments! This feature is available on all Production and Enterprise plans.
When creating an environment variable, click on the + icon next to Environments, and enter a custom environment name for the variable. Once this variable has been created, subsequent variables will have the new environment - in this case test - listed as available environment.
To delete a custom environment, delete all environment variables assigned to it.
Custom environments support was added in eas-cli@16.23.0. In practice this means that the --environment flag now accepts any string as opposed to only the default development, preview and production.
Now you may pass in test as the environment field in eas.json or workflows files which will ensure the build will pull variables from the new environment.
If you have a use-case that exceeds these limits, please get in touch!
Date: October 14, 2025
We're deprecating the GitHub build triggers feature to focus our efforts on delivering the best mobile CI/CD experience through EAS Workflows.
EAS Workflows gives you everything GitHub build triggers offered and much more. You can still trigger builds automatically from GitHub, but now with the flexibility and power to automate your entire mobile development workflow—from running tests and checks to custom deployment pipelines and beyond.
Get started: Learn more about EAS Workflows
Published: SEP 30, 2025
Scheduling workflows allows you to automate routine tasks like building and submitting your app on a regular cadence. This eliminates the need to manually trigger builds and submissions, so that you can do things like have your biweekly production builds already submitted to the app stores by the time you arrive at work.
Use the on.schedule.cron trigger in your workflow configuration with unix-cron syntax:
name: Example cron job trigger workflow
on:
push:
branches: ["main"]
schedule:
- cron: "0 9 1-7,15-21 * 1" # Runs every two weeks on Monday at 9 AM GMT
jobs:
# ... Your workflow jobs here
See the workflow examples for pre-made configurations for core app development use cases.
Scheduled workflows have several important characteristics to keep in mind:
mainYou can use crontab guru to generate and validate cron expressions. Here are some useful patterns:
0 0 * * * - Daily at midnight GMT0 9 * * 1 - Every Monday at 9 AM GMT0 0 1,15 * * - Twice monthly on the 1st and 15th at midnight GMT0 6 * * 1-5 - Weekdays at 6 AM GMTScheduling your deployment workflows means your builds and submissions can be processed automatically during off hours. When you arrive at work, your latest app version is already built and submitted, ready for you to release through the app store consoles. Schedules remove some of the toil around repeated tasks, like releasing to the app stores, or running nightly end-to-end tests.
Learn more about the scheduled job syntax in the documentation.
September 18, 2025
The TestFlight job allows you to distribute iOS builds directly to TestFlight internal and external testing groups. Unlike the standard iOS submit job, the TestFlight job provides advanced control over TestFlight features including test group management, changelog distribution, and Beta App Review submission.
To distribute a build to TestFlight groups, add a job with type: testflight to your workflow:
name: Distribute to TestFlight
jobs:
testflight_distribution:
name: Distribute to TestFlight
type: testflight
params:
build_id: ${{ needs.build_ios.outputs.build_id }}
internal_groups: ['QA Team']
external_groups: ['Public Beta']
changelog: "Bug fixes and performance improvements"The TestFlight job requires an iOS build created with distribution: store. You'll need to have your Apple Developer account configured for TestFlight submissions.
One useful pattern we've found is distributing development builds through TestFlight. This approach eliminates the need to manage ad hoc provisioning profiles across your team's iOS devices, which simplifies your team's process for distributing development builds.
You can distribute to both internal and external TestFlight groups with a detailed changelog:
name: Full TestFlight Distribution
jobs:
build_ios:
name: Build iOS
type: build
params:
platform: ios
profile: production
testflight:
name: Distribute to TestFlight
needs: [build_ios]
type: testflight
params:
build_id: ${{ needs.build_ios.outputs.build_id }}
internal_groups: ['QA Team', 'Internal Testers']
external_groups: ['Public Beta', 'Partner Testing']
changelog: |
What's new in this release:
- Performance improvements
- Bug fixes for login flow
- Updated user interface
submit_beta_review: trueFor external groups, the job automatically submits your build for Beta App Review unless you explicitly set submit_beta_review: false. This ensures your app can be distributed automatically to external testers once Apple's review is complete.
You can also upload builds with just a changelog. This way, the build will only get added to internal groups with "auto-distribute" enabled:
testflight:
name: Upload with Changelog
type: testflight
params:
build_id: ${{ needs.build_ios.outputs.build_id }}
changelog: "Latest development build with bug fixes"Learn more about the TestFlight job type in our pre-packaged jobs documentation.
SEP 12, 2025
The GitHub comment job posts reports of your workflow's completed builds and updates to GitHub pull requests. It makes it easy for your reviewers and testers to see what your changes will look like once they're deployed.
To post build and update reports to a GitHub pull request, add a job with type: github-comment to your workflow:
name: PR Auto Comment
on:
pull_request: {}
jobs:
# build_ios, build_android, and publish_update jobs
comment_on_pr:
name: Post Results to PR
after: [build_ios, build_android, publish_update]
type: github-commentThe job above will auto-detect the build and update IDs in your workflow and include them in a GitHub comment.
The job operates in two modes: auto-with-overrides mode (default) and payload mode for fully custom comments.
By default, the job automatically discovers all completed builds and updates from your workflow. You can customize which builds and updates to include:
name: Custom Build Report
jobs:
# build_ios, build_android, and publish_update jobs
custom_comment:
name: Post Custom Report
after: [build_ios, build_android, publish_update]
type: github-comment
params:
message: "🎉 Preview builds are ready! Please test these changes before approving the PR."
build_ids:
- ${{ after.build_ios.outputs.build_id }}
- ${{ after.build_android.outputs.build_id }}
update_group_ids:
- ${{ after.publish_update.outputs.first_update_group_id }}For complete control over comment content, use payload mode with markdown:
name: Custom Comment
jobs:
custom_payload:
name: Post Custom Comment
type: github-comment
params:
payload: |
## 🚀 Deployment Complete
Your custom comment!The GitHub comment job is flexible, so that it can fit your team's needs. You can combine the control flow properties of jobs, like needs and after, to post specific messages about job statuses:
name: Conditional PR Comment
on:
pull_request: {}
jobs:
build_android:
name: Build Android
type: build
params:
platform: android
profile: preview
comment_success:
name: Post Success Comment
needs: [build_android]
if: ${{ needs.build_android.status == 'success' }}
type: github-comment
params:
message: '✅ Android build succeeded! Ready for testing.'
build_ids:
- ${{ needs.build_android.outputs.build_id }}
comment_failure:
name: Post Failure Comment
after: [build_android]
if: ${{ after.build_android.status == 'failure' }}
type: github-comment
params:
payload: |
❌ **Android build failed**
Please check the [workflow logs](https://expo.dev/accounts/[account]/projects/[project]/workflows) for details.Learn more about the GitHub Comment job type in our prepackaged jobs documentation.
Learn about the changes and how to upgrade
Date: AUG 27, 2025
Author: Stanisław Chmiela
We've added support for Xcode 26 beta on our macOS build infrastructure, allowing you to build and test your apps with the latest iOS 26 features before the public release later this fall.
To use Xcode 26 beta to create your builds, specify the following image in your eas.json:
{
"build": {
"preview": {
"ios": {
"image": "macos-sequoia-15.5-xcode-26.0"
}
}
}
}For Workflows, specify the image in your job configuration:
jobs:
build:
type: build
image: macos-sequoia-15.5-xcode-26.0
params:
platform: iosAs new beta images roll out, we'll continue to update our xcode image under this image name, so you'll always have the latest.
Using this beta image allows you to test your app against the latest iOS 26 SDK and identify any compatibility issues before the public release later this fall. For a complete list of supported build images, see our infrastructure documentation.
Learn about the changes, how to try it out, and how to give feedback.
JUL 23, 2025
Welcome to another expo.dev changelog! Here's what's new across the website this month:
New landing page → expo.dev/eas/hosting
We have a new landing page for EAS Hosting. Learn more about how you can take your project even further with web deployments here: expo.dev/eas/hosting
New resource hub → expo.dev/learn
We now have a central place to explore docs, guides, and tutorials that help you level up.
Improved log annotations
Warnings, errors, and info annotations are now visually distinct — making debugging faster and clearer.
Light mode
You can now disable dark mode in build and submission logs.
App Store Connect links
iOS submission jobs now link directly to App Store Connect on success.
Related links in update jobs
Update jobs now include quick links to related entities for faster navigation.
You can now compare fingerprints directly from the list page using the new "Compare" button.
Change invite roles
Admins can now adjust the role of a pending invite without canceling it.
Custom display names
Set a personalized display name for your organization in account settings.
JUN 12, 2025
By Gabriel Donadel
React Native 0.80 is supported in a canary release of the Expo SDK, instructions available in this post. Expo SDK 54 will be released in late summer and will likely support React Native 0.81.
Expo SDK 53 currently supports React Native 0.79 (default), released April 8, 2025.
React Native 0.80 support is available in a canary release of the Expo SDK, to allow early adopters to use it right away. This is not intended to be a stable release, but if you are particularly adventurous and have a good motivation to use it today, you certainly can (provided that other non-Expo libraries you depend on are also compatible). You can read more about Expo SDK policy for tracking React Native releases in our docs.
Canary releases represent a snapshot of the state of the
mainbranch at the time they are published. Canary package versions include-canaryin the name, along with the date and commit hash, such as54.0.0-canary-20250611-f0afe80.
npx create-expo-app my-app --template blank@canarynpx expo install expo@canary --fixExpo SDK 54 will be released late summer, and it is intended to support React Native 0.81. Keep an eye out for a beta release in late August or September.