{"id":"src_Rp_lS4O8RgwNh_yHBA-O7","slug":"expo-changelog","name":"Expo Changelog","type":"feed","url":"https://expo.dev/changelog","orgId":"org_m4ShHtUXoJ67paiOEYqFS","org":{"slug":"expo","name":"Expo"},"isPrimary":false,"metadata":"{\"feedUrl\":\"https://expo.dev/changelog/rss.xml\",\"feedType\":\"unknown\",\"feedDiscoveredAt\":\"2026-04-07T23:42:10.630Z\",\"noFeedFound\":false,\"feedEtag\":\"\\\"q0gyl7ewzlw\\\"\",\"feedContentLength\":\"32\"}","releaseCount":50,"releasesLast30Days":0,"avgReleasesPerWeek":0.5,"latestVersion":null,"latestDate":"2026-03-04T16:30:00.000Z","changelogUrl":null,"hasChangelogFile":false,"lastFetchedAt":"2026-04-19T03:02:03.592Z","trackingSince":"2023-12-19T12:00:00.000Z","releases":[{"id":"rel_a0C-4rERXSzM_givqdnCr","version":null,"title":"Introducing Expo Observe (Private Preview)","summary":"# Introducing Expo Observe (Private Preview)\n\n**MAR 4, 2026**\n\nWe're building **Expo Observe**, a new way to understand how your app performs in the r...","content":"# Introducing Expo Observe (Private Preview)\n\n**MAR 4, 2026**\n\nWe're building **Expo Observe**, a new way to understand how your app performs in the real world.\n\n![Expo Observe Dashboard](https://cdn.sanity.io/images/9r24npb8/production/8d7d1025783ef33f3617a61258a44423363a519f-1600x900.png?auto=format&fit=max&q=75&w=1200)\n\n## The problem\n\nYou 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?\n\nThese 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.\n\nDebugging 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.\n\n## What Expo Observe does\n\nIn this initial Preview release, we've focused on tracking startup metrics for your app:\n\n* **Cold Launch time**: launch time when the app's native code and resources are not in memory\n* **Warm Launch time**: launch time when native libraries, app's state and resources are already cached in memory\n* **Time to Interactive**: when your app is ready for user input\n* **Time to first render**: when content first appears on screen\n* **Bundle load time**: how long it takes to load your JavaScript\n\n![A release marker hovered](https://cdn.sanity.io/images/9r24npb8/production/21247d97b8ef0aec73f8d4d0fbbdc7f6bdf93659-1190x684.png?auto=format&fit=max&q=75&w=800)\n\n## How it works\n\nOnce integrated, Observe collects these metrics from real user sessions and gives you tools to understand them:\n\n* **Track across releases**: compare performance between builds and OTA updates to catch regressions early\n* **Statistical breakdowns**: view median, average, min, max, and percentile values (P90, P99) for each metric\n* **Investigate outliers**: when something looks off, dig into individual sessions to see all events, device info, and metadata for that user\n\n![Example metric details](https://cdn.sanity.io/images/9r24npb8/production/4c2bc706e13b346c09b91bc5dc3165b424962488-1295x772.png?auto=format&fit=max&q=75&w=800)\n\n## What's next\n\nThis 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.\n\nWe're looking for developers to help us test and shape Expo Observe. If you're interested in early access, please join the waitlist.","publishedAt":"2026-03-04T16:30:00.000Z","url":"https://expo.dev/changelog/introducing-expo-observe","media":[]},{"id":"rel_Pn83Gry5KLaiXtRKer6cj","version":null,"title":"Expanded permissions for the Expo GitHub bot","summary":"# Expanded permissions for the Expo GitHub bot\n\n**Date:** March 3, 2026  \n**Author:** Dan Kelly\n\n## Overview\n\nYou may have received (or will soon rece...","content":"# Expanded permissions for the Expo GitHub bot\n\n**Date:** March 3, 2026  \n**Author:** Dan Kelly\n\n## Overview\n\nYou 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.\n\n**Action required:** Click approve when you see the GitHub email.\n\n## Why we're requesting new permissions\n\nExpo 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.\n\nSpecific feature details will be shared as they roll out.\n\n## What the Expo GitHub App does today\n\nThe Expo GitHub App connects GitHub repositories to EAS. When installed and linked to an Expo project, it enables:\n\n* Triggering EAS Workflows from pushes, pull requests, and tags\n* Posting workflow results (like build and update links) as GitHub PR comments\n* Reading your repository contents to run builds and updates on EAS\n\nThese existing features will continue to work regardless of whether you approve the new permissions.\n\n## What happens if you don't approve\n\nNothing 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.\n\nThe only limitation is access to new agentic features as they become available. Permissions can be approved later when ready.\n\n## A note for enterprise teams\n\nOrganizations with strict access policies should know:\n\n* **The new permissions are additive.** They don't change how existing features work or what data they access.\n* **You can leave them off.** Every current integration (EAS Workflows, builds, updates, PR comments) works without the new permissions.\n* **You can approve later.** There's no deadline. Evaluate new features when they ship and approve at that point.\n\nFor questions about specific permission scopes, contact [security@expo.dev](mailto:security@expo.dev) or [Discord](https://chat.expo.dev/).","publishedAt":"2026-03-03T20:00:41.000Z","url":"https://expo.dev/changelog/expanded-permissions-for-the-expo-github-bot","media":[]},{"id":"rel_7qiiZugG5onxf_8XJ3aXq","version":null,"title":"Expo SDK 55","summary":"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 n...","content":"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.","publishedAt":"2026-02-25T20:55:02.000Z","url":"https://expo.dev/changelog/sdk-55","media":[]},{"id":"rel_Vo50ZWgSsjYxi5cGF8hbX","version":null,"title":"MCP tools for EAS Build and Workflows","summary":"# MCP tools for EAS Build and Workflows\n\n**FEB 6, 2026** | By Mustafa Abban\n\nExpo MCP Server now includes tools that allow your AI assistants to inter...","content":"# MCP tools for EAS Build and Workflows\n\n**FEB 6, 2026** | By Mustafa Abban\n\nExpo 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.\n\n## What's New\n\n### Build Management Tools\n\nYou can now ask your AI assistant to:\n\n* **`build_info`** Check build status: \"Get the status of my latest iOS build\"\n* **`build_list`** List builds: \"What are my recent builds\"\n* **`build_logs`** View build logs: \"Show me the logs for the failed build\"\n* **`build_run`** Trigger new builds: \"Run a production build for iOS\"\n* **`build_cancel`** Cancel running builds: \"Cancel the build that is currently in progress\"\n* **`build_submit`** Submit to app stores: \"Submit the latest build to the App Store\"\n\n### Workflow Automation Tools\n\nManage your entire workflow pipeline through conversational prompts:\n\n* **`workflow_create`** Create workflows: \"Create a workflow for building and deploying\"\n* **`workflow_info`** Monitor runs: \"Get the status of the latest workflow run\"\n* **`workflow_list`** List workflows: \"What are my recent workflows\"\n* **`workflow_logs`** View logs: \"Show me the logs for the build job in the workflow\"\n* **`workflow_run`** Trigger runs: \"Run the build-and-deploy workflow\"\n* **`workflow_validate`** Validate configurations: \"Validate my workflow file\"\n* **`workflow_cancel`** Cancel workflows: \"Cancel the running workflow\"\n\n## Examples\n\nRetrieve recent workflow runs and investigate the root cause behind their failures:\n\n```\n> what are my recent workflows\n\nHere are your recent EAS workflows:\n\n| Date         | Workflow             | Status      | Branch | Commit         |\n|--------------|----------------------|-------------|--------|----------------|\n| Feb 4, 2026  | Android Build        | ✅ SUCCESS  | main   | 186dbaa - \"ex\" |\n| Jan 30, 2026 | iOS Build and Submit | ❌ FAILURE  | main   | 186dbaa - \"ex\" |\n| Jan 28, 2026 | iOS Build and Submit | ❌ FAILURE  | main   | 186dbaa - \"ex\" |\n| Jan 28, 2026 | Android Build        | ⚪ CANCELED | main   | 186dbaa - \"ex\" |\n```\n\nExample scenario with interacting with build tools to inspect and rerun a build:\n\n```\n> what are the logs of my recent build\n\nHere's a summary of the logs for your most recent Android build:\n\nBuild Summary\n- Build ID: 60e2fdf1-fc7a-4b08-89c3-fe53bb2ea311\n- Status: ✅ SUCCESS\n\nBuild Environment\n- Machine: AMD, 4 vCPUs, 16 GB RAM\n- Image: ubuntu-22.04-jdk-17-ndk-r26b\n- Node.js: 20.19.2\n- Java: 17\n- Bun: 1.2.4\n- NDK: 26.1.10909125\n\nBuild Phases\n| Phase                      | Result                |\n|----------------------------|-----------------------|\n| QUEUE                      | ✅ success            |\n| SPIN_UP_BUILDER            | ✅ success            |\n| RUN_GRADLEW                | ✅ success (14m 55s)  |\n| UPLOAD_APPLICATION_ARCHIVE | ✅ success            |\n| SAVE_CACHE                 | ✅ success            |\n\nOutput\n- APK Size: 81.1 MB\n- Location: app-release.apk\n- Gradle Tasks: 862 executed, 1 up-to-date (863 total)\n\nCache Stats\n- Cache Hit Rate: 25% (216/864 hits)\n- Cache Size: 0.04 GB / 5.00 GB\n```\n\n## Getting Started\n\nTo use these tools, you'll need:\n\n* An [EAS paid plan](https://expo.dev/pricing)\n* The Expo MCP Server configured in your AI-assisted tool\n* An authenticated connection to your Expo account\n\nLearn more in the [MCP documentation](https://docs.expo.dev/eas/ai/mcp/).","publishedAt":"2026-02-06T17:15:00.000Z","url":"https://expo.dev/changelog/mcp-build-and-workflows","media":[]},{"id":"rel_FIVSHNcP7uaTC2YOBwiU-","version":null,"title":"Compiler cache for builds and Workflows","summary":"# Compiler cache for builds and Workflows\n\nJAN 26, 2026\n\nBy Mustafa Abban and Stanisław Chmiela\n\n## Compiler cache for builds\n\nEAS supports build cach...","content":"# Compiler cache for builds and Workflows\n\nJAN 26, 2026\n\nBy Mustafa Abban and Stanisław Chmiela\n\n## Compiler cache for builds\n\nEAS 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.\n\nBuilds 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.\n\nFrom 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.\n\nThe following environment variables control caching behavior:\n\n* `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 cache\n* `EAS_RESTORE_CACHE`: Controls restoring the cache at the beginning of a build. Set to `1` to enable or `0` to disable.\n* `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.\n\n## Get started\n\n**Prerequisites**\n\n* The remote compiler cache requires projects on SDK 53+ for Android and SDK 54+ for iOS.\n\n**Steps**\n\n1. Navigate to the project's EAS environment variables settings page.\n2. Create a new variable named `EAS_USE_CACHE` with a value of `1`. Then select every environment, typically: production, preview, and development.\n3. Kick off multiple builds. The first one will save the cache and subsequent builds will use that cache during their build process.\n\nThe 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.\n\nYou'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.\n\n## Examples\n\nSetting 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.\n\n**Workflows**\n\nUse functions `eas/restore_build_cache` and `eas/save_build_cache` to apply ccache automatically.\n\n```\n- uses: eas/restore_build_cache\n- uses: eas/build\n- uses: eas/save_build_cache\n```\n\nFunctions `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.\n\n```\n- uses: eas/restore_cache\n  with:\n    key: android-ccache-${{ hashFiles('package-lock.json') }}\n    restore_keys: android\n    path: /home/expo/.cache/ccache\n- uses: eas/build\n- uses: eas/save_cache\n  with:\n    key: android-ccache-${{ hashFiles('package-lock.json') }}\n    path: /home/expo/.cache/ccache\n```\n\n**Custom build**\n\n```\nbuild:\n  name: Build with ccache\n  steps:\n    - eas/checkout\n    - eas/restore_build_cache\n    - eas/build\n    - eas/save_build_cache\n```\n\n## Cache restrictions\n\nAccess 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.\n\n## Caching from GitHub Builds\n\nWhen a build is run from GitHub, caches get scoped to the branch the build is running from. A build can restore caches created in:\n\n* The current branch\n* The default branch (`main` or `master`)\n\nIf 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.\n\n## Caching from CLI\n\nWhen 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.\n\n## Shared user behavior\n\nWhen 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.\n\n## Designated build for cache creation\n\nYou 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.\n\n**Disable restoring cache for production build profile**\n\n```json\n{\n  \"build\": {\n    \"production\": {\n      \"env\": {\n        \"EAS_RESTORE_CACHE\": \"0\",\n        \"EAS_SAVE_CACHE\": \"1\"\n      }\n    },\n    \"preview\": {\n      \"env\": {\n        \"EAS_USE_CACHE\": \"1\"\n      }\n    }\n  }\n}\n```\n\n**Only save cache from designated jobs**\n\nTo ensure only trusted sources publish cache, you can configure workflows to only save cache from specific jobs on the main branch:\n\n```\njobs:\n  build_production:\n    type: build\n    if: ${{ github.ref_name == 'main' }}\n    env:\n      EAS_RESTORE_CACHE: '0'\n      EAS_SAVE_CACHE: '1'\n    params:\n      platform: android\n      profile: production\n```\n\nLearn more about the usage and details of build cache in the [documentation](https://docs.expo.dev/build-reference/caching/#caching-cc-compilation-artifacts-with-ccache).\n\n## Feedback\n\nWe'd love to hear how build caches work for you. If you experience issues, please send an email to [workflows@expo.io](mailto:workflows@expo.io).","publishedAt":"2026-01-26T18:00:00.000Z","url":"https://expo.dev/changelog/compiler-cache-for-builds","media":[]},{"id":"rel_dslBOOrFABgmdo_IW_0Si","version":null,"title":"Expo SDK 55 Beta is now available","summary":"Learn about the changes, how to try it out, and how to give feedback.","content":"Learn about the changes, how to try it out, and how to give feedback.","publishedAt":"2026-01-22T22:00:00.000Z","url":"https://expo.dev/changelog/sdk-55-beta","media":[]},{"id":"rel_O6QtYeBu2YPOSde0G3h08","version":null,"title":"Workflows insights","summary":"# Workflows insights\n\n**DEC 15, 2025**\n\nWorkflows insights aggregates data from all of your workflow runs in the insights tab on the Expo dashboard. Y...","content":"# Workflows insights\n\n**DEC 15, 2025**\n\nWorkflows 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.\n\n## Understanding your workflows\n\nWorkflows insights collects and visualizes data about how your workflows are performing. This includes:\n\n* Success and failure rates of every workflow\n* Number of active workflows\n* Failed run counts\n* Trends over time\n\nThe 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.\n\n## When to use workflows insights\n\nWorkflows 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.\n\nThis 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.\n\n## Getting started\n\nWorkflows insights is available to organizations on the Production and Enterprise plans. You can access insights by going to your project's insights tab.\n\nOnce 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.\n\nWorkflows insights makes it easier to maintain reliable workflows at scale, giving you the visibility you need to keep your CI/CD pipelines healthy.","publishedAt":"2025-12-15T16:30:40.000Z","url":"https://expo.dev/changelog/workflows-insights","media":[]},{"id":"rel_3K3tBwV-3c80vbkmZ33Xi","version":null,"title":"Slack job type for Workflows","summary":"# Slack job type for Workflows\n\n**December 10, 2025** | By Stanisław Chmiela\n\n## Overview\n\nThe Slack job sends a message during a workflow run to your...","content":"# Slack job type for Workflows\n\n**December 10, 2025** | By Stanisław Chmiela\n\n## Overview\n\nThe 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.\n\n## Using the Slack job\n\nTo send a message to a Slack channel, add a job with `type: slack` to your workflow:\n\n```yaml\nname: Send message\n\njobs:\n  send_slack_message:\n    name: Send Slack message\n    type: slack\n    params:\n      webhook_url: {{ env.SLACK_WEBHOOK_URL }}\n      message: \"Hello Slack! 🎉\"\n```\n\nThe webhook URL can be obtained from your Slack workspace's app settings.\n\n## Examples\n\n### Conditional build failure notification\n\nYou can send a message to a channel conditionally when a build fails:\n\n```yaml\nname: Build Notification\n\njobs:\n  build_ios:\n    name: Build iOS\n    type: build\n    params:\n      platform: ios\n      profile: production\n\n  notify_build:\n    name: Notify Build Status\n    needs: [build_ios]\n    type: slack\n    params:\n      webhook_url: {{ env.SLACK_WEBHOOK_URL }}\n      message: 'Build completed for app ${{ after.build_ios.outputs.app_identifier }} (version ${{ after.build_ios.outputs.app_version }})'\n```\n\n### Rich Slack messages\n\nYou 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:\n\n```yaml\nname: Rich Build Notification\n\njobs:\n  build_android:\n    name: Build Android\n    type: build\n    params:\n      platform: android\n      profile: production\n\n  notify_build:\n    name: Notify Build Status\n    needs: [build_android]\n    type: slack\n    params:\n      webhook_url: {{ env.SLACK_WEBHOOK_URL }}\n      payload:\n        blocks:\n          - type: header\n            text:\n              type: plain_text\n              text: 'Build Completed'\n          - type: section\n            fields:\n              - type: mrkdwn\n                text: \"*App:*\\n${{ needs.build_android.outputs.app_identifier }}\"\n              - type: mrkdwn\n                text: \"*Version:*\\n${{ needs.build_android.outputs.app_version }}\"\n          - type: section\n            fields:\n              - type: mrkdwn\n                text: \"*Build ID:*\\n${{ needs.build_android.outputs.build_id }}\"\n              - type: mrkdwn\n                text: \"*Platform:*\\n${{ needs.build_android.outputs.platform }}\"\n          - type: section\n            text:\n              type: mrkdwn\n              text: 'Distribution: ${{ needs.build_android.outputs.distribution }}'\n```\n\nLearn more about the Slack job type in the [pre-packaged jobs documentation](https://docs.expo.dev/eas/workflows/pre-packaged-jobs/#slack).","publishedAt":"2025-12-10T15:15:00.000Z","url":"https://expo.dev/changelog/slack-job-type-for-workflows","media":[]},{"id":"rel_eKgBeO3cvSabgSr_-kwcZ","version":null,"title":"[Updated] Mitigating Multiple Security Vulnerabilities in React Server Components","summary":"# [Updated] Mitigating Multiple Security Vulnerabilities in React Server Components\n\n**Date:** DEC 5, 2025  \n**Authors:** Phil Pluckthun, Vojtech Nova...","content":"# [Updated] Mitigating Multiple Security Vulnerabilities in React Server Components\n\n**Date:** DEC 5, 2025  \n**Authors:** Phil Pluckthun, Vojtech Novak\n\nHere'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.\n\n## Updates\n\n**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:\n\n* `expo-router@55.0.0-preview.5` and `jest-expo@55.0.6` for SDK55\n* `expo-router@6.0.23` and `jest-expo@54.0.17` for SDK 54\n* `expo-router@5.1.11` and `jest-expo@53.0.14` for SDK 53\n\n**UPDATED December 11 and December 12, 2025:** Three new vulnerabilities ([CVE-2025-55184](https://www.cve.org/CVERecord?id=CVE-2025-55184), [CVE-2025-55183](https://www.cve.org/CVERecord?id=CVE-2025-55183), and [CVE-2025-67779](https://www.cve.org/CVERecord?id=CVE-2025-67779)) were disclosed on December 11 affecting React Server Components. We have released additional patches to address these issues:\n\n* `expo-router@6.0.19` and `jest-expo@54.0.16` for SDK 54\n* `expo-router@5.1.10` and `jest-expo@53.0.13` for SDK 53\n* `expo-router@7.0.0-canary-20251211-7da85ea` and `jest-expo@55.0.0-canary-20251211-7da85ea` for canary\n\nLearn more in the [react.dev blogpost](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components).\n\nFollow the updated mitigation steps below, which now include newer `react-server-dom-webpack` versions to address the total of four vulnerabilities.\n\nPreviously, on December 3, an unauthenticated remote code execution vulnerability in React Server Components was disclosed as [CVE-2025-55182](https://www.cve.org/CVERecord?id=CVE-2025-55182). You may learn more about the vulnerability in this [react.dev blogpost](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components).\n\n## Am I affected?\n\n**First, you only need to take action if you're using [experimental RSC or Server Functions](https://docs.expo.dev/guides/server-components/) support**. If you use Expo only for client-side Android, iOS, and web, then you are _not_ affected. API routes are not affected.\n\nExpo 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.\n\n## What to do (if affected)\n\nTo mitigate the vulnerabilities in your project's dependencies, you need to use a version of `react-server-dom-webpack` according to the list below:\n\n* `react-server-dom-webpack@19.1.4` for SDK 54 (with react 19.1.x)\n* `react-server-dom-webpack@19.0.3` for SDK 53 (with react 19.0.x)\n* `react-server-dom-webpack@19.2.3` for canary (with react 19.2.x)\n\nYou 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.\n\nWe 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.\n\nThese patches were published as listed below:\n\n* [commit for sdk-54](https://github.com/expo/expo/commit/f2bef1cd2470ded72fc8fdd5d4e016b7ecaee5fe) released with [jest-expo@54.0.16](https://www.npmjs.com/package/jest-expo/v/54.0.16) and [expo-router@6.0.19](https://www.npmjs.com/package/expo-router/v/6.0.19)\n* [commit for sdk-53](https://github.com/expo/expo/commit/1d9e1eaf1e9184f4dc39ba0b71bb211fe6c42c3e) released with [jest-expo@53.0.13](https://www.npmjs.com/package/jest-expo/v/53.0.13) and [expo-router@5.1.10](https://www.npmjs.com/package/expo-router/v/5.1.10)\n* [commit for canary](https://github.com/expo/expo/commit/acb11f2f02b0321d8daced5cf365317d79c6deec) released with [jest-expo@55.0.0-canary-20251212-acb11f2](https://www.npmjs.com/package/jest-expo/v/55.0.0-canary-20251212-acb11f2) and [expo-router@7.0.0-canary-20251212-acb11f2](https://www.npmjs.com/package/expo-router/v/7.0.0-canary-20251212-acb11f2)\n\nAdditionally, 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.\n\n## Verify the upgrade\n\nAfter 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.\n\n## React & React Native Version Compatibility\n\nKeep 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.\n\n## React versions in a monorepo\n\nIf 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.\n\nThe `react` package itself does not contain RSC functionality and is hence not affected by these vulnerabilities.\n\n## Summary\n\n* Only experimental RSC and Server Functions are affected. Apps that use Expo only for client-side Android, iOS, and web are _not_ affected.\n* You can update just the affected dependency manually or install the releases of `expo-router` and `jest-expo` according to the table above.\n* Specific versions of `react-native` require specific versions of `react`.\n* In a monorepo, you may use a different version of `react` for an Expo app and other web projects.","publishedAt":"2025-12-05T09:30:37.000Z","url":"https://expo.dev/changelog/mitigating-critical-security-vulnerability-in-react-server-components","media":[]},{"id":"rel_mjdCAHNhMj986xKoNGO9T","version":null,"title":"Require Two-Factor Authentication for Organization Members","summary":"# Require Two-Factor Authentication for Organization Members\n\n**November 24, 2025**\n\nBy Byron Karlen\n\nOrganizations on Production and Enterprise plans...","content":"# Require Two-Factor Authentication for Organization Members\n\n**November 24, 2025**\n\nBy Byron Karlen\n\nOrganizations 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.\n\n## Why require 2FA?\n\n2FA 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.\n\n![Team settings page](https://cdn.sanity.io/images/9r24npb8/production/44ad9f1f68187aacc0acd7c46284fead4d2414ff-2964x1512.png?auto=format&fit=max&q=75&w=800)\n\n## How it works\n\n* New members can accept an invitation to your organization only once they have enabled 2FA\n* Members are prevented from disabling 2FA once enabled\n* When 2FA becomes required, existing members without 2FA remain in the organization. They should enable it themselves, or be removed and re-invited to enforce the requirement.\n\nOrganization owners and admins can enable this requirement from the account's settings page.","publishedAt":"2025-11-24T21:15:23.000Z","url":"https://expo.dev/changelog/require-two-factor-authentication-for-organization-members","media":[]},{"id":"rel_m3narOJxEw3lAqWubKdGM","version":null,"title":"Custom environments for EAS Environment Variables","summary":"# Custom environments for EAS Environment Variables\n\n**November 21, 2025**\n\nBy default, all projects have three environment variable environments: **d...","content":"# Custom environments for EAS Environment Variables\n\n**November 21, 2025**\n\nBy 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.\n\n## How it works\n\nWhen 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.\n\nTo delete a custom environment, delete all environment variables assigned to it.\n\n![Example of defining a custom environment](https://cdn.sanity.io/images/9r24npb8/production/2244c6f7bf5800b47652f7f916f9958f08c00b7b-1610x1428.png?auto=format&fit=max&q=75&w=800)\n\n## With the eas-cli\n\nCustom 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**.\n\n![Terminal example listing all the env vars for the test environment](https://cdn.sanity.io/images/9r24npb8/production/618eb8eb54ef9e656841a2ff692e240ba5302315-892x292.png?auto=format&fit=max&q=75&w=800)\n\nNow 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.\n\n![Example of using a test environment in build](https://cdn.sanity.io/images/9r24npb8/production/26b0fced632960b1ecb18d4f2f92493febc56894-820x430.png?auto=format&fit=max&q=75&w=800)\n\n## Limits\n\n* An environment name can contain letters, digits, underscores and hyphens, and be between 3-100 characters\n* Project environment variables are limited to 200 per environment\n* App-wide environment variables are limited to 150 per environment\n* Custom environments are limited to 10 per project\n\nIf you have a use-case that exceeds these limits, please get in touch!","publishedAt":"2025-11-21T15:30:12.000Z","url":"https://expo.dev/changelog/custom-environment-variable-environments","media":[]},{"id":"rel_u1pf5xVCz6EK9r0BStv0b","version":null,"title":"GitHub Build Triggers Deprecated in Favor of EAS Workflows","summary":"# GitHub Build Triggers Deprecated in Favor of EAS Workflows\n\n**Date:** October 14, 2025\n\nWe're deprecating the GitHub build triggers feature to focus...","content":"# GitHub Build Triggers Deprecated in Favor of EAS Workflows\n\n**Date:** October 14, 2025\n\nWe're deprecating the GitHub build triggers feature to focus our efforts on delivering the best mobile CI/CD experience through EAS Workflows.\n\n## What this means:\n\n* Existing projects with GitHub build triggers configured will continue to work\n* New projects will no longer have access to this feature\n\n## Why EAS Workflows?\n\nEAS 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.\n\n**Get started:** Learn more about [EAS Workflows](https://expo.dev/eas/workflows)","publishedAt":"2025-10-14T15:30:37.000Z","url":"https://expo.dev/changelog/github-build-triggers-deprecation","media":[]},{"id":"rel_VCEFZaM_7izqSGeyafO56","version":null,"title":"Scheduled cron jobs for Workflows","summary":"# Scheduled cron jobs for Workflows\n\n**Published:** SEP 30, 2025\n\nScheduling workflows allows you to automate routine tasks like building and submitti...","content":"# Scheduled cron jobs for Workflows\n\n**Published:** SEP 30, 2025\n\nScheduling 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.\n\n## How to schedule workflows\n\nUse the `on.schedule.cron` trigger in your workflow configuration with unix-cron syntax:\n\n```\nname: Example cron job trigger workflow\n\non:\n  push:\n    branches: [\"main\"]\n  schedule:\n    - cron: \"0 9 1-7,15-21 * 1\" # Runs every two weeks on Monday at 9 AM GMT\n\njobs:\n  # ... Your workflow jobs here\n```\n\nSee the [workflow examples](https://docs.expo.dev/eas/workflows/examples/introduction/) for pre-made configurations for core app development use cases.\n\n## Scheduling considerations\n\nScheduled workflows have several important characteristics to keep in mind:\n\n* **Default branch only**: Scheduled workflows run exclusively on the default branch of your repository, typically `main`\n* **GMT timezone**: All scheduled workflows execute in Greenwich Mean Time (GMT)\n* **Multiple schedules**: A single workflow can have multiple cron schedules for different timing requirements\n* **High load delays**: During peak usage times, particularly at the start of each hour, scheduled workflows may experience delays\n* **Idempotent design**: In rare cases, jobs may be skipped or run multiple times, so make sure your workflows handle repeated execution gracefully\n\n## Common scheduling patterns\n\nYou can use [crontab guru](https://crontab.guru) to generate and validate cron expressions. Here are some useful patterns:\n\n* `0 0 * * *` - Daily at midnight GMT\n* `0 9 * * 1` - Every Monday at 9 AM GMT\n* `0 0 1,15 * *` - Twice monthly on the 1st and 15th at midnight GMT\n* `0 6 * * 1-5` - Weekdays at 6 AM GMT\n\n## Wrap up\n\nScheduling 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.\n\nLearn more about the scheduled job syntax in the [documentation](https://docs.expo.dev/eas/workflows/syntax/#onschedulecron).","publishedAt":"2025-09-30T19:45:00.000Z","url":"https://expo.dev/changelog/scheduled-workflows-for-workflows","media":[]},{"id":"rel_zDNSvyAeRZbcxjvLYJX5M","version":null,"title":"TestFlight job type for Workflows","summary":"# TestFlight job type for Workflows\n\n**September 18, 2025**\n\nThe TestFlight job allows you to distribute iOS builds directly to TestFlight internal an...","content":"# TestFlight job type for Workflows\n\n**September 18, 2025**\n\nThe 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.\n\n## Using the TestFlight job\n\nTo distribute a build to TestFlight groups, add a job with `type: testflight` to your workflow:\n\n```yaml\nname: Distribute to TestFlight\n\njobs:\n  testflight_distribution:\n    name: Distribute to TestFlight\n    type: testflight\n    params:\n      build_id: ${{ needs.build_ios.outputs.build_id }}\n      internal_groups: ['QA Team']\n      external_groups: ['Public Beta']\n      changelog: \"Bug fixes and performance improvements\"\n```\n\nThe TestFlight job requires an iOS build created with `distribution: store`. You'll need to have your Apple Developer account configured for TestFlight submissions.\n\n## Development builds with TestFlight\n\nOne useful pattern we've found is distributing [development builds](https://docs.expo.dev/develop/development-builds/introduction/) 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.\n\n## Examples\n\nYou can distribute to both internal and external TestFlight groups with a detailed changelog:\n\n```yaml\nname: Full TestFlight Distribution\n\njobs:\n  build_ios:\n    name: Build iOS\n    type: build\n    params:\n      platform: ios\n      profile: production\n\n  testflight:\n    name: Distribute to TestFlight\n    needs: [build_ios]\n    type: testflight\n    params:\n      build_id: ${{ needs.build_ios.outputs.build_id }}\n      internal_groups: ['QA Team', 'Internal Testers']\n      external_groups: ['Public Beta', 'Partner Testing']\n      changelog: |\n        What's new in this release:\n        - Performance improvements\n        - Bug fixes for login flow\n        - Updated user interface\n      submit_beta_review: true\n```\n\nFor 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.\n\nYou can also upload builds with just a changelog. This way, the build will only get added to internal groups with \"auto-distribute\" enabled:\n\n```yaml\ntestflight:\n  name: Upload with Changelog\n  type: testflight\n  params:\n    build_id: ${{ needs.build_ios.outputs.build_id }}\n    changelog: \"Latest development build with bug fixes\"\n```\n\nLearn more about the TestFlight job type in our [pre-packaged jobs documentation](https://docs.expo.dev/eas/workflows/pre-packaged-jobs/#testflight).","publishedAt":"2025-09-18T03:00:00.000Z","url":"https://expo.dev/changelog/testflight-job-type-for-workflows","media":[]},{"id":"rel_ZHYp45Hatf-kyByFrkgP1","version":null,"title":"GitHub comment job type for Workflows","summary":"# GitHub comment job type for Workflows\n\n**SEP 12, 2025**\n\nThe GitHub comment job posts reports of your workflow's completed builds and updates to Git...","content":"# GitHub comment job type for Workflows\n\n**SEP 12, 2025**\n\nThe 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.\n\n## Using the GitHub Comment job\n\nTo post build and update reports to a GitHub pull request, add a job with `type: github-comment` to your workflow:\n\n```yaml\nname: PR Auto Comment\n\non:\n  pull_request: {}\n\njobs:\n  # build_ios, build_android, and publish_update jobs\n\n  comment_on_pr:\n    name: Post Results to PR\n    after: [build_ios, build_android, publish_update]\n    type: github-comment\n```\n\nThe job above will auto-detect the build and update IDs in your workflow and include them in a GitHub comment.\n\nThe job operates in two modes: auto-with-overrides mode (default) and payload mode for fully custom comments.\n\n## Auto-discovery\n\nBy default, the job automatically discovers all completed builds and updates from your workflow. You can customize which builds and updates to include:\n\n```yaml\nname: Custom Build Report\n\njobs:\n  # build_ios, build_android, and publish_update jobs\n\n  custom_comment:\n    name: Post Custom Report\n    after: [build_ios, build_android, publish_update]\n    type: github-comment\n    params:\n      message: \"🎉 Preview builds are ready! Please test these changes before approving the PR.\"\n      build_ids:\n        - ${{ after.build_ios.outputs.build_id }}\n        - ${{ after.build_android.outputs.build_id }}\n      update_group_ids:\n        - ${{ after.publish_update.outputs.first_update_group_id }}\n```\n\n## Payload mode\n\nFor complete control over comment content, use payload mode with markdown:\n\n```yaml\nname: Custom Comment\n\njobs:\n  custom_payload:\n    name: Post Custom Comment\n    type: github-comment\n    params:\n      payload: |\n        ## 🚀 Deployment Complete\n\n        Your custom comment!\n```\n\n## Additional use cases\n\nThe 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:\n\n```yaml\nname: Conditional PR Comment\n\non:\n  pull_request: {}\n\njobs:\n  build_android:\n    name: Build Android\n    type: build\n    params:\n      platform: android\n      profile: preview\n\n  comment_success:\n    name: Post Success Comment\n    needs: [build_android]\n    if: ${{ needs.build_android.status == 'success' }}\n    type: github-comment\n    params:\n      message: '✅ Android build succeeded! Ready for testing.'\n      build_ids:\n        - ${{ needs.build_android.outputs.build_id }}\n\n  comment_failure:\n    name: Post Failure Comment\n    after: [build_android]\n    if: ${{ after.build_android.status == 'failure' }}\n    type: github-comment\n    params:\n      payload: |\n        ❌ **Android build failed**\n\n        Please check the [workflow logs](https://expo.dev/accounts/[account]/projects/[project]/workflows) for details.\n```\n\nLearn more about the GitHub Comment job type in our [prepackaged jobs documentation](https://docs.expo.dev/eas/workflows/pre-packaged-jobs/#github-comment).","publishedAt":"2025-09-12T13:30:00.000Z","url":"https://expo.dev/changelog/github-comment-job-type-for-workflows","media":[]},{"id":"rel_hyyaqcv8hLnLRjnBghUYa","version":null,"title":"Expo SDK 54","summary":"Learn about the changes and how to upgrade","content":"Learn about the changes and how to upgrade","publishedAt":"2025-09-10T17:15:00.000Z","url":"https://expo.dev/changelog/sdk-54","media":[]},{"id":"rel_1NnxyP6c-1v_PRLxwjOgS","version":null,"title":"Xcode 26 beta support for EAS Build and Workflows","summary":"# Xcode 26 beta support for EAS Build and Workflows\n\n**Date:** AUG 27, 2025\n\n**Author:** Stanisław Chmiela\n\nWe've added support for Xcode 26 beta on o...","content":"# Xcode 26 beta support for EAS Build and Workflows\n\n**Date:** AUG 27, 2025\n\n**Author:** Stanisław Chmiela\n\nWe'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.\n\n## How to use Xcode 26 beta\n\nTo use Xcode 26 beta to create your builds, specify the following image in your **eas.json**:\n\n```json\n{\n  \"build\": {\n    \"preview\": {\n      \"ios\": {\n        \"image\": \"macos-sequoia-15.5-xcode-26.0\"\n      }\n    }\n  }\n}\n```\n\nFor Workflows, specify the image in your job configuration:\n\n```yaml\njobs:\n  build:\n    type: build\n    image: macos-sequoia-15.5-xcode-26.0\n    params:\n      platform: ios\n```\n\nAs new beta images roll out, we'll continue to update our xcode image under this image name, so you'll always have the latest.\n\n## Testing before public release\n\nUsing 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](https://docs.expo.dev/build-reference/infrastructure/#ios-build-server-configurations).","publishedAt":"2025-08-27T13:45:00.000Z","url":"https://expo.dev/changelog/xcode-26-0-beta-support-for-eas-build-and-workflows","media":[]},{"id":"rel_XiTZU0EKaZdTonKSL0Jr1","version":null,"title":"Expo SDK 54 beta is now available","summary":"Learn about the changes, how to try it out, and how to give feedback.","content":"Learn about the changes, how to try it out, and how to give feedback.","publishedAt":"2025-08-19T18:30:00.000Z","url":"https://expo.dev/changelog/sdk-54-beta","media":[]},{"id":"rel_yjP32rsgb870u4r4vuXnH","version":null,"title":"Mid-July website updates: EAS Hosting, Workflows, Organizations, and more","summary":"# Mid-July website updates: EAS Hosting, Workflows, Organizations, and more\n\n**JUL 23, 2025**\n\nWelcome to another **expo.dev** changelog! Here's what'...","content":"# Mid-July website updates: EAS Hosting, Workflows, Organizations, and more\n\n**JUL 23, 2025**\n\nWelcome to another **expo.dev** changelog! Here's what's new across the website this month:\n\n## 🌐 EAS Hosting\n\n**New landing page → [expo.dev/eas/hosting](https://expo.dev/eas/hosting)**\n\nWe 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](http://expo.dev/eas/hosting)\n\n![A screenshot of the EAS Hosting landing page](https://cdn.sanity.io/images/9r24npb8/production/1b2c5da2db7a30baa3a0a089006af3e6c1e9ca1e-2781x1880.png?auto=format&fit=max&q=75&w=800)\n\n## 📚 Learning Resources\n\n**New resource hub → [expo.dev/learn](https://expo.dev/learn)**\n\nWe now have a central place to explore docs, guides, and tutorials that help you level up.\n\n![A screenshot of the new learning resources page](https://cdn.sanity.io/images/9r24npb8/production/1c687815146209664ac733d70c231d332397f7cb-2959x2517.png?auto=format&fit=max&q=75&w=800)\n\n## 📋 Logs\n\n**Improved log annotations**\n\nWarnings, errors, and info annotations are now visually distinct — making debugging faster and clearer.\n\n![Screenshots of the new themed annotations](https://cdn.sanity.io/images/9r24npb8/production/c4726fed58ba2e06a6512c78a3417d31638c8ebd-844x376.png?auto=format&fit=max&q=75&w=800)\n\n**Light mode**\n\nYou can now disable dark mode in build and submission logs.\n\n![Light mode logs screenshot](https://cdn.sanity.io/images/9r24npb8/production/f20066341622834324f48fd1373cb0e9ebf9a4a5-2392x1030.png?auto=format&fit=max&q=75&w=800)\n\n## ⚙️ Workflows\n\n**App Store Connect links**\n\niOS submission jobs now link directly to App Store Connect on success.\n\n![A screenshot of an EAS Submit job with an App Store Connect link button](https://cdn.sanity.io/images/9r24npb8/production/4948ec2665f2ab3405e238ed20e30b75f27dc4e9-1950x408.png?auto=format&fit=max&q=75&w=800)\n\n**Related links in update jobs**\n\nUpdate jobs now include quick links to related entities for faster navigation.\n\n![A screenshot of a workflow run details page with an update job](https://cdn.sanity.io/images/9r24npb8/production/ba501bbed571e222ce51cdcbf7fbb2b4bb3cf576-2074x1236.png?auto=format&fit=max&q=75&w=800)\n\n## 🫆 Fingerprints\n\nYou can now compare fingerprints directly from the list page using the new \"Compare\" button.\n\n![A screenshot of the new fingerprint comparison selector UI](https://cdn.sanity.io/images/9r24npb8/production/13687d8ab451b150b89cf4f0eb06e2ee19f9f69d-1140x854.png?auto=format&fit=max&q=75&w=800)\n\n## 👥 Organizations\n\n**Change invite roles**\n\nAdmins can now adjust the role of a pending invite without canceling it.\n\n![A screenshot of the pending organization invite role change UI](https://cdn.sanity.io/images/9r24npb8/production/26d97b095a4c115adb194dcaf21945cb85b3eb83-1810x992.png?auto=format&fit=max&q=75&w=800)\n\n**Custom display names**\n\nSet a personalized display name for your organization in account settings.\n\n![A screenshot of the account settings page with the new display name option](https://cdn.sanity.io/images/9r24npb8/production/08a055396cb8e809e8a617451089d3efbad4e46c-2516x1160.png?auto=format&fit=max&q=75&w=800)","publishedAt":"2025-07-23T23:00:51.000Z","url":"https://expo.dev/changelog/mid-july-website-updates","media":[]},{"id":"rel_-Sol_mG4JT_2iu0oVHc_Y","version":"0.80","title":"Expo support for React Native 0.80","summary":"# Expo support for React Native 0.80\n\nJUN 12, 2025\n\nBy Gabriel Donadel\n\nReact Native 0.80 is supported in a canary release of the Expo SDK, instructio...","content":"# Expo support for React Native 0.80\n\nJUN 12, 2025\n\nBy Gabriel Donadel\n\nReact 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.\n\n![React Native 0.80](https://cdn.sanity.io/images/9r24npb8/production/4aa3c2be3bce246dd3b7e3b583e859cac1bdbb53-2400x1350.png?auto=format&fit=max&q=75&w=1200)\n\nExpo SDK 53 currently supports React Native 0.79 (default), released April 8, 2025.\n\n## Support is available on the Expo canary channel\n\nReact 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](https://docs.expo.dev/versions/latest/#expo-sdk-policy-for-tracking-react-native).\n\n> Canary releases represent a snapshot of the state of the `main` branch at the time they are published. Canary package versions include `-canary` in the name, along with the date and commit hash, such as `54.0.0-canary-20250611-f0afe80`.\n\n### Getting Started with Canary\n\n* **Create a new project with the canary release**: `npx create-expo-app my-app --template blank@canary`\n* **Install a canary release in an existing project**: `npx expo install expo@canary --fix`\n\n### When using a canary release, be aware that:\n\n* It is not stable and may contain bugs\n* It may have breaking changes\n* It should only be used for testing and evaluation\n* It may not have all features fully implemented\n* It could have compatibility issues with some third-party libraries\n* It will not support Expo Go\n\n## Later Summer 2025: Expo SDK 54\n\nExpo 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.","publishedAt":"2025-06-12T18:15:17.000Z","url":"https://expo.dev/changelog/react-native-80","media":[]}],"pagination":{"page":1,"pageSize":20,"totalPages":3,"totalItems":50},"summaries":{"rolling":null,"monthly":[]}}