Expo SDK 50: What You Need to Know

Expo SDK 50 has been released, which includes React Native 0.73. This announcement comes after extensive beta testing, for which the developers express their gratitude to all those who participated.

This new release promises to provide developers with a more robust and efficient platform for building mobile applications. The inclusion of React Native 0.73 means that developers will have access to the latest tools and features, allowing for greater flexibility and creativity in their projects.

Introducing Expo Dev Tools Plugins

Expo Dev Tools Plugins API offers a platform for app developers and library authors to build browser-based plugins that interact with their app or library. The API comes with a few plugins for popular tools such as Apollo Client, TanStack Query, TinyBase, React Native Async Storage, and React Navigation. These plugins can be found in the expo/dev-plugins repository. The API has been validated and demonstrated to work effectively. The Expo team is grateful for the feedback received since the proof of concept release in August. Learn more about the Expo Dev Tools Plugins API and its potential benefits.

video from expo.dev website

New and Improved SQLite and Camera APIs

Expo has recently released new and improved versions of their SQLite and Camera APIs. The updated SQLite API, called expo-sqlite/next, is a complete rewrite of the previous library, aimed at modernizing the API and bringing it closer to parity with mature equivalents for web and Node.js. The API includes both synchronous and asynchronous methods, and adds support for prepared statements, update callbacks, and the Blob data type, among other features.

One of the major improvements to the SQLite API is the updated SQLite version, which is now 3.42.0 on both platforms. This allows for support of SQLite extensions, such as CR-SQLite. Additionally, Expo has built a Knex dialect for expo-sqlite/next, which is ideal for those who prefer using query builders.

The updated Camera API, called expo-camera/next, is designed to make accessing the device camera simple and reliable. This API has been brought up to date with native platform best practices and is expected to fit most use cases like a glove. For more advanced use cases, such as frame processors, Expo recommends using the react-native-vision-camera library.

Overall, these updates to the SQLite and Camera APIs are important building blocks for mobile app development. As patterns like local-first application architecture continue to grow, Expo believes that SQLite will become increasingly essential. They plan to continue investing in this library accordingly.

To learn more about these new APIs, visit the Expo documentation.

Introducing @expo/fingerprint

@expo/fingerprint is a CLI or API tool designed to help React Native developers determine if their app JavaScript bundle is compatible with a particular build of their app. This tool generates a unique fingerprint that represents the native characteristics of a project. If that fingerprint changes, then the developer knows that the JavaScript app that targeted the older fingerprint may be incompatible.

To use @expo/fingerprint, simply run npx @expo/fingerprint path/to/your/project in the command line. More information about @expo/fingerprint can be found in the README and the expo-github-actions README. First class integration into EAS services is expected to be available in the future.

Expo Router v3

Expo Router v3 is the latest major release of the universal file-based routing system, offering advanced web support and improved stability. This version includes bugfixes, better documentation, testing, and types. Notably, Expo Router v3 now features experimental support for building universal server endpoints with API Routes. For more information, refer to “Expo Router v3: API Routes, bundle splitting, speed improvements, and more”.

EAS Build

EAS Build is continuously improving with the addition of new features and upgrades. Since the last SDK release, several highlights have been added to enhance the user experience.

One significant improvement is that Xcode 15.2 is now the default for macOS workers, providing users with the latest version of Xcode. Similarly, JDK 17 and Ubuntu 20 are now the default for Linux workers, ensuring that users have access to the latest Java Development Kit and Ubuntu operating system.

Another significant change is that Node 18 is now the default version for EAS Build. This version tracks the current maintenance LTS, and on November 27th, 2023, the default version changed from Node 16 to Node 18.

EAS Build also provides improved warnings and errors through “Build annotations.” These annotations help users understand why they are seeing specific warnings and errors during their build and provide guidance on how to resolve them.

To make iOS builds faster, EAS Build now pre-warms the CocoaPods cache. This feature speeds up all iOS builds, without requiring any changes on the user's end.

EAS Build also released Expo Orbit v1, which makes it faster and easier to install and run builds from EAS on macOS.

In addition to these significant changes, EAS CLI now supports Bun, and .nvmrc files can be used to set the Node version for builds, unless explicitly specified in the build profile. The eas build:run command now accepts the --profile flag to filter builds, and the eas build:delete command has been added to support certain automation workflows.

EAS Build also continues to improve the fully customizable builds preview, which is expected to be made generally available in the coming months.

EAS Update

The Expo Application Services (EAS) have recently undergone some updates to improve the user experience and functionality. These updates include a new JavaScript API, new dashboard UI features, rollbacks, and rollouts.

The new useUpdates() hook has been added to the expo-updates package to make it easier to track state and interact with the updates API. This API provides easy access to information about the state of updates in a project. Users can refer to the return type, the useUpdates() docs, and the expo/UpdatesAPIDemo repository for more information.

The dashboard UI features have also been updated to allow users to create new channels, remove them, republish updates, and remove them. These updates are designed to improve the overall user experience and make it easier to manage projects.

Rollbacks are now possible, allowing production apps to roll back to their embedded update, which is the JavaScript app generated at build time. This feature is useful in cases where a regression is accidentally deployed as the first update to a new build and users want to revert to the embedded working state instead of trying to deploy an update fix on top.

Finally, rollouts are now available, allowing users to gradually roll out updates to a percentage of their users. This feature minimizes the impact of introducing a bug to the production environment accidentally.

Overall, these updates to the EAS provide users with improved functionality and make it easier to manage projects and updates.

Basic Expo Modules support for tvOS and macOS

Developers can now use the Expo Modules API to create native modules for tvOS and macOS platforms. The use_expo_modules! method that autolinks Expo modules can be utilized on tvOS and macOS targets in the Podfile. This method installs only the modules that declare support for the target platform in their podspec.

For tvOS, SDK 50 supports several packages including expo-application, expo-av, expo-constants, expo-device, expo-file-system, expo-font, expo-image, expo-keep-awake, expo-localization, expo-splash-screen, expo-updates, and @expo/cli. Developers can learn more about building Expo apps for TV in the “Build Expo apps for TV” guide. The Expo team is also interested in receiving feedback on which packages developers are most interested in seeing supported in the future.

For macOS, SDK 50 currently supports expo-constants, expo-file-system, and expo-keep-awake (no-op). The Expo team plans to adapt more packages after the SDK release and add support for @expo/cli so that developers can use npx expo start to run their development server. Developers can also provide feedback on which packages they are most interested in seeing supported in the future.

Developers can refer to the PR that installs Expo modules in Expo Orbit and the PR that migrates one of its native modules to Expo Modules API for examples. Documentation for these platforms will be available soon.

First-class Expo support in Sentry

Sentry is committed to providing first-class support for Expo developers. With the deprecation of sentry-expo and the merge into @sentry/[email protected], developers can now enjoy a better and more up-to-date experience with Sentry in their Expo projects.

One of the major goals of this integration was to improve the integration between Sentry and EAS Update. With just a simple command, eas update --branch <branch> && npx sentry-expo-upload-sourcemaps dist, developers can now easily publish an update and upload the corresponding sourcemaps.

To migrate from sentry-expo to @sentry/react-native, developers can refer to the migration guide provided by Sentry. Additionally, the “Use Sentry” guide on the Expo documentation provides detailed instructions on how to integrate Sentry into Expo projects.

Sentry's documentation is also a great resource for developers looking to learn more about how to use Sentry in their projects. With Sentry's first-class support for Expo, developers can rest assured that their projects are in good hands.

Other Highlights

The latest version of React Native, version 0.73, and React version 18.2.0, which remains unchanged from SDK 49, come with several improvements. The React Native CHANGELOG, Release Notes, and React CHANGELOG provide a complete account of these improvements.

The expo-font config plugin now natively supports adding fonts to an app. This feature is useful for loading fonts at runtime with Font.loadAsync or useFonts to avoid rebuilding the app binary. Since fonts in an app typically do not change often, embedding the font into the native project with a config plugin helps to clean up some of the async loading code from the app startup when it is time to do a build.

The expo-secure-store receives a few new improvements, including synchronous getItem and setItem functions. The behavior across Android and iOS has been unified as much as possible, resulting in the functions now behaving the same, except for different types of exceptions that may result from different native implementations. This introduces a small breaking change, as expo-secure-store will now always return null when fetching a value that does not exist in a keychain. Previously, Android would throw an exception, and iOS would return null. More information about other changes can be found in the changelog.

The expo-dev-client now defaults to loading the most recently opened project when a development build is booted up. If the development server is not available, it falls back to the launch screen. This change is in response to feedback that this is typically what people want when they boot a development build. However, if this is not the preference, the behavior can be changed with the config plugin: "launchModeExperimental": "launcher”.

The npx expo run command has been added. Expo CLI will now prompt the user to select a target platform if it is not explicitly named in the command. This is a small quality of life improvement that aligns the npx expo run UX with that of eas build:run. Alternatives to run:android and run:ios include npx expo run android and npx expo run ios.

The npx expo install --fix now upgrades the expo package to the latest patch version. Developers often keep up to date with Expo SDK patch versions released through an SDK cycle by running npx expo install --fix, with the exception of the expo package, which was not automatically updated with this command. It is encouraged that developers stay up to date with the latest patches, and so, after the initial upgrade to SDK 50, the --fix flag will update all of the Expo SDK packages, including the expo package.

A native project update tool is now available. For developers building projects on top of the React Native Community CLI template, the React Native Upgrade Helper is a great tool. However, there are some differences in native projects that use this template as compared to projects that use Expo Modules. To make upgrading bare native projects with Expo Modules easier, a similar tool to the community upgrade helper has been built, and it is now part of the documentation.

Web bundle splitting with Metro is now enabled by default. Bundle splitting with Metro is a new feature, and more information is coming soon. For now, check out the related async routes documentation.

Improved error messages and code removal are now available. Expo CLI now provides full stack traces for component-based errors, tree shakes all unused platform-specific code, and transforms faster when bundling for Hermes. Static website exports are now over 2x faster!

The URL and URLSearchParams standards are now built-in. Previously, it was necessary to polyfill the web standard URL API in order to use many cross-platform libraries available on npm. Developers tend to assume that the URL API is available. URL is an important enough primitive that it deserves to be built into the Expo core runtime. The expo package now ships with its own implementation of URL.

Improved isolated modules support is now available. Developers can now use pnpm or npm --install-mode=isolated for local development builds. For other scenarios, a few remaining blocking issues are being worked through and an update is expected soon.

A preview of the experimental React Native JS debugger UI is now available. The debugging experience in React Native has been unified, and the infrastructure that powers this new debugger UI is the same foundation as the JS debugger built into Expo CLI. The approaches are slightly different, and more information will be provided in the future.

@expo/webpack-config is now deprecated in favor of Expo CLI's Metro web. This means that Webpack support will continue to work in SDK 50, but it will not be actively developed, and it will be removed in a future release.

Notable Breaking Changes

As of Expo SDK 50, there are several notable breaking changes that developers should be aware of. These changes include updates to the Android SDK, iOS minimum deployment target, and required Node version for Expo CLI and React Native. Additionally, classic updates are no longer supported, and the @expo/vector-icons library has been updated to use [email protected].

One significant change is the Android SDK 34, AGP 8, and Java 17 requirement for building projects locally. Developers will need to install JDK 17 to meet this requirement. The minimum supported version for Android has also been bumped to Android 6 (API 23).

For iOS, the minimum deployment target has been bumped to 13.4. This change may affect some projects, so developers should be aware of this requirement.

Expo CLI and React Native now require Node 18+ to run. Additionally, the default Node version on EAS Build was bumped to Node 18 on November 27th.

Classic updates are no longer supported in Expo SDK 50. Instead, developers are recommended to use EAS Update. This change was announced in February 2023.

The @expo/vector-icons library has been updated to use [email protected]. This update adds support for FontAwesome6 and changes to Ionicons and MaterialIcons. Notably, the ios- and md- prefixed icon names in Ionicons have been removed. Developers using TypeScript will be warned about any icon names that have changed when updating. Other developers should verify that their icons are correct.

Most expo-updates JavaScript APIs are no longer available in Expo Go or development builds using expo-dev-client. These APIs are designed to be used in production builds, and Expo Go and expo-dev-client control how updates are loaded in development builds.

Finally, React Native 0.73 changed from Java to Kotlin for Android Main* classes. If developers depend on any config plugins that use dangerous modifications to change these files, they may need to be updated for SDK 50 support. The ProgressBarAndroid and ProgressViewIOS components from React Native have also been removed in 0.73, after a long period of deprecation.

Developers using the Expo Router v3 should refer to the Breaking Changes section of the Expo Router v3 post for any changes that may affect their projects.

🧹 Expo Go: Dropped SDK 47 and 48

Expo Go has recently dropped support for SDK versions 47 and 48. This decision was made to reduce the number of versions that need to be supported in Expo Go. While these SDK versions will no longer work within the latest version of Expo Go, they will continue to work as expected in other environments. Users can still install older versions of Expo Go for Android devices/emulators or iOS simulators.

A single SDK version per release of the Expo Go app: looking ahead to SDK 51

Expo Go has traditionally supported multiple SDK versions in a single installation of the app. However, the team has announced that they will be moving towards including a single version of the Expo SDK in Expo Go. This change is expected to have little impact on most developers using Expo tools, as Expo CLI will continue to install the appropriate version of Expo Go for the SDK that the project uses to any connected Android device/emulator or iOS simulator.

This decision was made to simplify the release process, as supporting multiple SDK versions in a single installation of the app is a tedious and difficult task. The team believes that this change will encourage developers to adopt development builds for a flexible and powerful development environment suitable for real-world applications at scale.

Expo Go will continue to be a great sandbox for developers to quickly get started and experiment with ideas. However, the team encourages developers to use development builds for more complex projects.

Developers are encouraged to share their thoughts and concerns about this upcoming change by emailing [email protected].

Known Issues

• Snack support is not yet available for SDK 50, but it will be released soon.
• In Expo Go for iOS, source maps aren't working correctly, and the JavaScript debugger doesn't connect. These issues are not present in development builds.
• If you find any issues, you can report a regression to the appropriate team.

Upgrading your app

Upgrading an app to Expo SDK 50 from 49 involves a few key steps. First, it's important to update to the latest version of EAS CLI, if it is being used. Next, the new version of the Expo package must be installed using the following command: npm install expo@^50.0.0.

All dependencies must then be upgraded to match SDK 50. If there are any resolutions/overrides in the package.json file, it's important to verify that they are still needed. For example, any metro and metro-resolver overrides that were added for expo-router in a previous SDK release should be removed.

It's also important to check for any possible known issues and refer to the “Deprecations, renamings, and removals” section above for breaking changes that are most likely to impact the app. The changelog should be checked for all other breaking changes as well.

If the app uses Expo Router, it's important to refer to the breaking changes in v3 and update the app accordingly. If Continuous Native Generation is not used, npx pod-install should be run if there is an ios directory. Any relevant changes from the Native project upgrade helper should be applied, or prebuild could be adopted for easier upgrades in the future.

If any Expo Modules are maintained, the library build.gradle should be updated for Android to match the changes in the diff. The JVM target version configuration may also now be removed, as explained in this FYI page. For iOS, the platform deployment target field should be updated from '13.0' to '13.4', matching the changes in the diff.

If any config plugins are maintained, it's important to note that MainActivity.java and MainApplication.java were migrated to Kotlin. If any config plugins modify these files, they may need to be updated for SDK 50 support.

If Expo Go is used, the Expo Go app on phones should be updated from app stores. Expo CLI will automatically update the apps in simulators. The iOS simulator build or the APK can also be downloaded from expo.dev/tools.

If development builds are used with expo-dev-client, a new development build should be created after upgrading.

By following these steps, upgrading an app to Expo SDK 50 from 49 can be done smoothly and efficiently.