Forem: Expo

Introducing EAS Hosting: Simplified deployment for modern React apps

Expo Team — Tue, 14 Jan 2025 15:40:31 +0000

From weather apps, and commerce websites, to AI-powered chat apps, most modern applications today need reliable servers. That's why today we're introducing EAS Hosting for instantly deploying and scaling universal API routes, React websites, and more!

The Challenge of Universal App Deployment

Many massive companies such as Netflix, Meta, and Apple use server-driven UI in their native apps. But building a server-driven application is extremely challenging and simply out of reach for most developers. Our goal with Expo Router has been to solve this problem and enable anyone to build and scale world-class server-driven apps for Android, iOS, and web using the same codebase.

To this end, we've introduced API Routes that can be used to create server endpoints for your app, secure environment variables, and static generation for web pages, all building toward universal React Server Components. While all these features work great on a local dev server, deployment has become more challenging.

There are many full-stack problems to consider when building a modern application. We've historically recommended deploying Expo websites and universal API routes to traditional hosting services that are focused only on websites. But hosting services for websites traditionally don’t integrate with the problems native apps face.

New versions of your servers may need to be deployed while new versions of your native app are being published to app stores.
Different versions of your native app may need to have their requests routed to different versions of your server.
Observability of servers for critical metrics, such as feature adoption by platform, becomes more important for Expo native apps.

With EAS Hosting, in conjunction with EAS Workflows, we’re providing an end-to-end deployment solution that just works across all platforms, and stays working as you scale.

How to Get Started with EAS Hosting

First, ensure you’re using the latest version of EAS CLI:

npm i -g eas-cli

Then simply bundle your app with Expo CLI, deploy your website and server code worldwide with a single EAS command, and get a preview URL immediately:

npx expo export -p web
eas deploy

That's it! Your website and API routes are now live with a beautiful .expo.app URL that you can share with anyone. (For an example Expo web deployment, visit: https://bacon.expo.app)

Add environment variables to your .env file, and these will securely reside on the server-side for use in API routes and React Server Functions, keeping them out of your client code.

By visiting the EAS dashboard, you can monitor your deployments and see helpful telemetry. Server errors are automatically aggregated and can be linked to for triaging!

Here's a comprehensive video demonstration of EAS Hosting that covers deployment, assigning aliases, using API routes, looking up request logs, managing environment variables, and automating deployments with Workflows:

Fingerprint your native runtime with @expo/fingerprint

Expo Team — Tue, 06 Feb 2024 23:47:00 +0000

At Expo, we’re always looking to find systematic solutions to problems that developers encounter when building apps with React Native. There’s a set of time-consuming questions related to the native project runtime that comes up again and again, and up until now, there hasn’t been a good systematic approach to answering them.

The questions go something like this:

Does a pull request include native code changes and need to initiate a new build for testing?
Is my update compatible with the runtime in my production app? Or will it crash the app?
Does a project require a development build, or can I experiment with it in Expo Go?

While these issues may seem quite different initially, on closer examination they all come down to one key problem: "Given a project, can we deterministically generate a hash, identity, or fingerprint that represents its unique native characteristics?"

Meet @expo/fingerprint

Now, by running npx @expo/fingerprint@latest /path/to/yourProject, you can get a full picture of your project's native setup. @expo/fingerprint also comes with an API, so you can integrate this tool programmatically into your own projects.

We think this is a massive milestone for the whole React Native ecosystem and it's already unlocking some super interesting use cases that are not immediately obvious. Krzysztof Magiera is using it to make startup of his RN IDE plugin for vscode much faster.

Here’s an example of what the fingerprint looks like:

{
  "sources": [
    {
      "type": "file",
      "filePath": "app.json",
      "reasons": ["expoConfig"],
      "hash": "378083de0c6e6bb6caf8fb72df658b0b26fb29ef"
    },
    {
      "type": "file",
      "filePath": "eas.json",
      "reasons": ["easBuild"],
      "hash": "f723802b6ea916d1a6c4767b2299cc81ddb22eb4"
    },
    {
      "type": "dir",
      "filePath": "node_modules/expo",
      "reasons": ["expoAutolinkingIos", "expoAutolinkingAndroid", "bareRncliAutolinking"],
      "hash": "1faee4057fa943300905750b51c3b0cbf05f4b0d"
    }
  ],
  "hash": "bf8a3b08935f056270b1688333b02f1ef5fa25bf"
}

Developers can represent the entire native state of their project with a single, succinct hash value, which is immensely valuable for easily detecting native changes. But there are several other important considerations that we accounted for in order to maximize the usefulness in various use cases:

Speed: we’ve tried to make this tool as fast as possible so you can run it often, and we’ll continue to push on that to make it even faster.
Precision: we should only consider aspects of the project that are actually relevant (it can’t just be a hash of the entire project and all of the .DS_Store and .swp files or the value would not be useful).
Support for diffing: You should be able to compare fingerprints to determine what’s different between them.
Customizability: The API exposes some options that you can use to customize for your workflows — most notably, you can either add extra files to hashing or exclude files. We also read the .fingerprintignore file from your project root, which works similarly to .gitignore.

Try out @expo/fingerprint 🪄

@expo/fingerprint fully supports projects made with Expo CLI and also works with any bare React Native apps, whether they use Expo tools or not. Follow these steps to see it in action:

Generate a fingerprint JSON file: run npx @expo/fingerprint@latest /path/to/yourProject > fingerprint.json
Change your native runtime: one easy way to do this is to install an npm package with native dependencies, for example: npx expo install expo-camera or npm install react-native-vision-camera.
Diff the fingerprint: run npx @expo/fingerprint@latest /path/to/yourProject fingerprint.json. Notice that it will identify what changed, for example if you installed expo-camera, you will see something like this:

[
  {
    "type": "dir",
    "filePath": "../../node_modules/expo-camera/android",
    "reasons": [
      "expoAutolinkingAndroid"
    ],
    "hash": "7682b28ed4ef8356faa5d9ad5b71e76e53198375"
  },
  {
    "type": "dir",
    "filePath": "../../node_modules/expo-camera/ios",
    "reasons": [
      "expoAutolinkingIos"
    ],
    "hash": "a80c2b1abb73157b772a8d0a351920465894bb0d"
  },
    // the rest is redacted for brevity
]

You can use this API programmatically with the Fingerprint.diffFingerprintChangesAsync(fingerprint, projectRoot) function.

What’s next: collect feedback and refine workflows

We think @expo/fingerprint is really going to help with automating decisions like when you can safely send out updates and analyzing your team's pull-requests to rebuild the native app only when it’s really needed.

Even though this is the first time we’re publicly talking about @expo/fingerprint, we’ve already had some early adopters who have opened PRs / issues to help make the tool better accommodate their projects.

We also know that the tool’s built-in opinions might not be perfect for every project. We want help from the community to test this tool thoroughly, and one way that we’ve made it very easy to do so is with our GitHub Actions integration, which is available now! (Blog post on github actions coming soon.)

Using @expo/fingerprint with EAS

In the future, we plan to build first-class integration for @expo/fingerprint into EAS services. You can use @expo/fingerprint in your EAS projects today by generating your fingerprint with the CLI and populating your runtimeVersion field with it, then comparing that value with the value generated at the time when you would like to do an update or build. If you use GitHub Actions to kick off your builds and updates, then may also want to use the GitHub Actions integration!

Expo SDK 50 Release 🚀

Expo Team — Thu, 18 Jan 2024 23:38:27 +0000

Today we’re announcing the release of Expo SDK 50.

SDK 50 is a very chunky and ambitious release that includes React Native 0.73. Thank you to all the contributors and to everyone who helped with beta testing.

Learn more in the full article on the Expo Changelog.

And please join our live stream on January 31st at 10:30am PT for a walkthrough of what’s new.

Introducing EAS

Expo Team — Wed, 10 Nov 2021 22:23:13 +0000

EAS stands for Expo Application Services, the fastest way to get your Expo app from development to the app stores.

Over the last few months, we've been previewing two new services: EAS Build and EAS Submit, the first services available from Expo Application Services (EAS).

Today, we're happy to announce that EAS is moving out of preview and into general availability!

What is EAS?

Expo is our open-source project: it will always be both open source and free - forever!

Expo Application Services (EAS) are our hosted cloud services built for both Expo and React Native. With EAS Build and Submit, we make it faster and easier for you to get your app from development into the app stores.

To learn more about EAS, head over to expo.dev/eas or check out our docs.

EAS Build and Submit

EAS Build takes everything good about the classic Expo build service (expo build:[android|ios]) and leaves all of its limitations behind. EAS Build raises the ceiling on what's possible with Expo managed workflow apps by adding support for custom native code and for building "Development clients" in the cloud. The service works great with both managed and bare Expo apps, or any React Native app you throw at it. You can also run it locally or on your own infrastructure.

You can build your app with EAS Build and automatically submit to app stores with EAS Submit in minutes or less, thanks to automatically managed app signing credentials, automatic submissions, and defaults that just work for most Expo and React Native apps.

Internal distribution makes it easy to share test builds with colleagues and friends using ad hoc provisioning or enterprise provisioning on iOS and APK side-loading on Android.

Everything works great for your entire team out of the box and can be integrated into your existing CI/CD workflows.

New EAS plans

With our EAS General Availability release, we are introducing three new plans: Free, Production, and Enterprise.

All our EAS services are now available under the Free plan, which is a great option for pre-revenue startups and proofs-of-concept, as well as hobby and student projects.

The Production plan is for any commercial app in production generating more than $1,500 per month in revenue, or any team using EAS in a serious way. With the Production plan, you get priority for your builds, additional build concurrencies, and access to add-ons as well as to the Expo Professionals forum. The Production plan is $99/month.

The Enterprise plan is for teams that want to work closely with Expo on their apps. Enterprise plans include more of everything in the Production plan and gives access to add-on features like SLAs and dedicated support.

Folks currently on the EAS Priority plan will be able to stay on that plan until they're ready to switch!

Enterprise support add-on

We often get requests for additional levels of support and are happy to announce our Enterprise Support plan that's now available as an add-on to our Enterprise plan.

With Enterprise Support you'll get direct access to the Expo team for questions and troubleshooting via a dedicated Slack channel. To learn more, check out our Enterprise Support page.

Get started with EAS - free!

All Expo accounts get access to the free EAS plan, so everyone can now try out EAS Build and Submit.

To learn more, look at creating your first build.

Thank you!

We want to extend a huge thank you to all the developers who participated in the preview and provided feedback for EAS Build and Submit. That feedback was a tremendous resource whether it was helping to track down a tricky bug, uncovering new use cases, or suggesting new improvements and functionality.

In total, developers participating in the EAS preview period built over 100,000 successful builds of their apps - with over 80,000 app store submissions! Hats off to all our preview developers!

Of course, just because we're out of the preview period, that doesn't mean we're done! We'll continue to add great new features and services - so please stay tuned and keep that feedback coming in!

Expo SDK 41

Expo Team — Fri, 23 Apr 2021 23:02:17 +0000

Today we're announcing the release of Expo SDK 41. SDK 41 includes React Native 0.63, the same version as in SDK 40. Thank you to everyone that [helped with beta testing[(https://blog.expo.io/expo-sdk-41-beta-is-now-available-958edcd78991). (Curious why we didn't include the recently released React Native 0.64? Learn more.)

⚡️ Highlights

Android apps now target Android R (11 / SDK 30). This comes with some significant changes for location permissions, media library (related to StorageAccessFramework), and constants. Please note that these changes also impact SDK <= 40 projects in Expo Go, but they will not impact SDK <= 40 standalone apps. Refer to expo.fyi/android-r for more information.
The recommended version of react-native-reanimated has been updated to v2. If you would like to use v2 features in your app, you need to add the Reanimated v2 Babel plugin. You can continue to use v1 features (eg: those used by React Navigation v5) without adding the new Babel plugin. Please note that if you use the new features from v2, you will not be able to use remote JS debugging in your app! If you use v2 APIs, JS debugging is only possible using Flipper and Hermes, which are not yet fully supported in the managed workflow. (We plan to investigate integrating Hermes during the next SDK cycle, but we don't currently expect to have it ready for SDK 42.)
lottie-react-native has been updated to the latest version (3.5.0). Your existing animations should continue to work as before, but if you encounter any issues please file an issue and share the animation file.
The new version of react-native-screens (v3) "enables screens" by default. If you encounter any related issues, you can report the issue and opt out with enableScreens(false). Be sure to update to the latest v4 patch release of React Navigation if you use v4.
Improvements were made across the SDK to ensure compatibility with EAS Build. A big part of this SDK has been making the necessary underlying changes to support EAS Build for managed projects. You can now use EAS Build with Expo managed apps to reduce the size of your standalone apps by up to 10x! Learn more about the latest EAS Build updates.
The expo package is now 93% smaller in production and better than ever. We've simplified the experience so the .expo extension is no longer needed (and so we removed it), and neither is the --target bare|managed flag - updates will run in either context provided the native runtime is compatible. We've improved consistency across the managed and bare workflow, removed legacy code, and improved tree-shaking on the package using @expo/metro-config.
To see the full list of new features and fixes, refer to the changelog!

🏡 Expo Go

We changed sign in to use expo-web-browser so we can leverage our existing web auth flow with two-factor-authentication.
You can now see teams and organizations that you are a part of in the Profile tab, and their associated projects show up in your recent projects below.

Notice the "Accounts & Organizations" section and the shared "Recent Projects" list below it.

🌐 Expo CLI

Integrated Developer Tools: Open the developer menu, inspect elements, and monitor performance all from the CLI. Just run expo start then press "m" to toggle the dev menu, and "shift+M" to toggle the performance monitor or element inspector across native apps.

It was either a heavily compressed but still 7mb gif or a YouTube video, so we went for the YouTube video.

Force Reloading: Shaking your devices every few minutes can get exhausting! Now you can reload connected phones, tablets, simulators, and browsers all by pressing "r" in the Terminal UI. This works across iOS, Android, web, and on physical devices.

Automatic TypeScript setup: Setting up TypeScript can be a pain, so we've completely automated it! Just create a blank tsconfig.json and run expo start, we'll take care of the rest! Learn more: "TypeScript" in the Expo docs.

Vastly better errors: No one likes errors - that's why in SDK 41 we've refined them to be as concise, and useful as possible! We only surface the most relevant stack traces and point to exactly where the error or warning is. We've also improved source maps, and muted generated code traces.

Debug your config: The new expo config command enables you to view the evaluated results of app.config.js or app.json. You can use expo config --type public to see the app manifest used in expo publish.
Better interactions with Apple Store Connect from your terminal: Faster, smarter authentication, better error handling, and - for the first time ever - get full insight into complex issues right from the console. Where other tools 401, Expo CLI gives you links to resolve issues in seconds. Need to update your payment or accept a contract? Resolve in a couple clicks, and get back to developing incredible (or at least "good") apps!

A terminal window showing information about a rejected request from App Store Connect due to an expired Developer Program membership.

The --config is flag deprecated. We suggest using app.config.js instead. The --config flag will continue to be supported for existing use cases for the foreseeable future, but it will not be supported in some situations in bare workflow projects, and it will also not be supported on EAS Build. Learn more: Migrating away from --config in Expo CLI.
The --target flag is deprecated for SDK 41+. This was used to provide slightly different behavior when in a managed or bare app environment, but it ended up being tricky to use because updates published with the bare target could not run in Expo Go, and updates published with the managed target could not run in a bare app. We now do any necessary adjustments to accommodate the environment at runtime, so an update bundle will work in either context, provided that the native runtime is compatible with the update.
Versioned Metro Config: Rather than adding @expo/metro-config to your package.json, you can now import it through the expo package with the vendored expo/metro-config import. This ensures that your project is always using a compatible version of the package. Learn More: Customizing Metro.
Introducing Config Plugins (beta): Config plugins are an important step towards making it possible for library authors to make their native modules part of the Expo ecosystem. This system is in beta, with a more stable release planned for SDK 42. Learn more: Config Plugins.

🏗 Deprecations, renamings, and removals

Deprecated globals have been removed from the expo package.As a result, expo-linear-gradient, expo-linking, expo-location, expo-permissions, and expo-sqlite are no longer automatically installed in every project by default as dependencies of expo. If you were depending on global.expo.LinearGradient or similar, please install the respective package and import the API from there instead, eg: import { LinearGradient } from 'expo-linear-gradient';. Refer to expo.fyi/deprecated-globals for more information.
Files with the .expo.* extension (eg: MyComponent.expo.js) are no longer recognized as source files. If your project source code or dependencies include any files with the .expo.* extension, expo-cli will let you know when you upgrade. Refer to expo.fyi/expo-extension-migration for more information.

We thought the .expo file extension was neat but it ended up not being necessary or particularly useful, and simplicity wins over neat things.

expo-permissions has been deprecated in favor of module-specific permissions methods. You should migrate from using Permissions.askAsync and Permissions.getAsync to the permissions methods exported by modules that require the permissions. For example: you should replace calls to Permissions.askAsync(Permissions.CAMERA) with Camera.requestPermissionsAsync(). There shouldn't be two ways to do an identical thing in a single SDK, and so we picked our preferred approach and are consolidating around it.
@react-native-community/async-storage is now @react-native-async-storage/async-storage. AsyncStorage is next in the packages that are gradually migrating out of the @react-native-community scope on npm (more context on why this is happening available here). We will take care of switching the packages in your dependencies in package.json when you run expo upgrade, but after that you will need to either manually update your imports in your source code, or run npx expo-codemod sdk41-async-storage [your-source-directory] to update it automatically. Along with this superficial change in package names comes a fix for an issue that occurs when ejecting your project; more information in this issue and these pull requests.
@expo/metro-config is now vendored by the expo package. If your metro.config.js uses @expo/metro-config, you should switch over to importing it from the expo package instead. Remove @expo/metro-config from your package.json dependencies and change your import in metro.config.js from @expo/metro-config to expo/metro-config. Learn more: Customizing Metro.
Legacy Notifications API has been removed.The legacy Notifications library (imported from the expo package) has been deprecated since SDK 38, and is now fully removed in SDK 41. If you're still relying on this package, you should upgrade to expo-notifications, which has plenty of improvements and additional features. Learn more: How to migrate from Expo's LegacyNotifications to the new expo-notifications library.
👋 iOS 10 support has been dropped - Expo SDK 41 supports iOS 11+. More information on this from our SDK 40 release notes:iOS 10 is the last version of iOS that still supports 32-bit simulator builds (x86), and to keep Expo npm packages smaller, we plan to publish only 64-bit pre-build binaries for simulators (x64 and arm64). This has been past due - the last time we dropped an iOS version was over two years ago, when we dropped support for iOS 9 in September 2018. Apple no longer reports usage statistics for iOS 10 directly, but you can get a rough idea from reading the App Store - iOS and iPadOS usage table - 6% of all devices use iOS 11 or lower at the time of writing.
🟢 Node 10 support will be dropped soon from Expo CLI. It's not that we have anything against the number 10, but Node 10 is about to be replaced by Node 12 as the Maintenance LTS release.
🧹 Dropped SDK 37; will drop SDK 38 next release. We routinely drop SDK versions that have low usage in order to reduce the number of versions we need to support. This release sees the end of life for SDK 37. As usual, your standalone apps built with SDK 37 will continue to work; however, SDK 37 projects will no longer work within the latest version of Expo Go. If you want to re-run expo build, then you'll need to upgrade from SDK 37, preferably to SDK 41 so you won't need to update again for a while (and also because each Expo version is better than the last!). Our next release is planned for June/July 2021 and, at that time, we'll be dropping support for SDK 38. If your project is running on SDK 38, consider upgrading to a newer version in the coming months.

➡️ Upgrading your app

Managed workflow

Here's how to upgrade your app to Expo SDK 41 from 40:

Update to the latest version of Expo CLI: npm i -g expo-cli. expo-cli@4.4.1 or greater is required.
Run expo upgrade in your project directory.
If you are using react-navigation v4, please be sure to update to the latest v4 patch release. This is required due to changes in the version of react-native-screens included in SDK 41.
Refer to the "Deprecations, renamings, and removals" section above for breaking changes that are most likely to impact your app.
Make sure to check the changelog for all other breaking changes!
Update the Expo app on your phones from the App Store / Google Play. expo-cliwill automatically update your apps in simulators if you delete the existing apps, or you can runexpo client:install:iosandexpo client:install:android`.
If you built a standalone app previously, remember that you'll need to create a new build in order to update the SDK version. Run expo build:ios and/or expo build:android when you are ready to do a new build for submission to stores.

Bare workflow

The Bare workflow lets you operate independently of the Expo SDK cycle, updating RN versions and versions of individual Expo packages however and whenever you want. However, if you do stick roughly to Expo SDK versions, these steps will help you to upgrade to Expo SDK 41 from 40:

Install the latest version of CocoaPods - 1.10.0 or greater is required.
Update to the latest version of Expo CLI: npm i -g expo-cli. expo-cli@4.4.1 or greater is required.
Run expo upgrade in your project directory.
Update to platform :ios, '11.0' in your Podfile.
Update compileSdkVersion and targetSdkVersion to 30 in android/build.gradle.
If you are using react-navigation v4, please be sure to update to the latest v4 patch release. This is required due to changes in the version of react-native-screens included in SDK 41.
Rebuild your native projects with npm run ios and npm run android.
Make sure to check the changelog for other breaking changes!

Expo SDK 41 beta is now available

Expo Team — Tue, 30 Mar 2021 18:23:38 +0000

Learn about the changes, how to try it out, and how to give feedback

The beta period will last approximately two weeks, and it is an opportunity for developers to ensure that the new release does not introduce any regressions for their particular system and app configurations.

SDK 41 beta includes React Native 0.63, the same version as SDK 39 and 40. The full release notes won’t be available until the final release, but you can browse the changes in the expo/expo CHANGELOG to learn more about the scope of the release and any breaking changes.

Notable changes to be aware of

@react-native-community/async-storage is now @react-native-async-storage/async-storage. You must change to the new package in SDK 41.
Files with the .expo extension (eg: MyComponent.expo.js) are no longer recognized as source files. If your project source code or dependencies include any files with the .expo. extension, expo-cli will let you know when you upgrade. Refer to expo.fyi/expo-extension-migration for more information.
iOS 10 support has been dropped — Expo SDK 41 supports iOS 11+. One of the reasons for dropping iOS 10 was to reduce the size of prebuilt binaries for Expo packages.
Node 10 support will be dropped soon from Expo CLI - it's not that we have anything against the number 10, but Node 10 is about to be replaced by Node 12 as the Maintenance LTS release.
Deprecated globals have been removed from the expo package. expo-linear-gradient, expo-linking, expo-location, expo-permissions, and expo-sqlite are no longer automatically installed in every project. If you were depending on global.expo.LinearGradient or similar, please the respective package and import the API from there instead, eg: import { LinearGradient } from 'expo-linear-gradient';
expo-permissions has been deprecated in favor of module-specific permissions methods, eg: Permissions.askAsync(Permissions.CAMERA) ➡️ Camera.requestPermissionsAsync().
Android apps now target Android R (11 / SDK 30). This comes with some significant changes for location permissions, media library (related to StorageAccessFramework), and constants. Please note that these changes also impact SDK <= 40 projects in Expo Go, but they will not impact SDK <= 40 standalone apps. Refer to expo.fyi/android-r for more information.
The recommended version of react-native-reanimated has been updated to v2. If you would like to use v2 features in your app, you need to add the Babel plugin. You can continue to use v1 features (eg: those used by React Navigation v5) without adding the Babel plugin. Please note that if you use the new features from v2, you will not be able to use remote JS debugging in your app! This is only possible in v2 using Flipper, which is not yet fully supported in the managed workflow.
The new version of react-native-screens (v3) “enables screens” by default. If you encounter any related issues, you can report the issue and opt out with enableScreens(false).
lottie-react-native has been updated to the latest version! Your existing animations should continue to work as before, but if you encounter any issues please file an issue and share the animation file.

Known regressions

Outstanding

Bitcode has been disabled on SDK 41 standalone apps for iOS, pending facebook/facebook-ios-sdk#1698.

Resolved

Textures in expo-gl on Android are not currently working in published SDK 41 projects in Expo Go or standalone apps. Related pull request.
lottie-react-native crashes on iOS. Related pull request.

How to try out the beta release

You will be able to opt in to using the SDK 41 beta by setting the EXPO_BETA environment variable to 1 (or some truthy value).

On macOS and Linux, you can set this per command with EXPO_BETA=1 expo <command>. On Windows, you can do the same with cross-env: npx cross-env EXPO_BETA=1 expo <command>. Below we have listed in the commands in their more concise form.

Install the latest version of expo-cli:

npm i -g expo-cli (SDK 41 requires expo-cli@4.3.2 or greater)

Initialize a new project with SDK 41 beta:

EXPO_BETA=1 expo init

Upgrade an existing project:

EXPO_BETA=1 expo upgrade

Install the latest Expo Go for iOS to your simulator:

EXPO_BETA=1 expo client:install:ios outside of an Expo project or inside of an SDK 41 project

Install the latest Expo Go for iOS to your physical device:

Use this TestFlight open beta link and follow the instructions.

Install the latest Expo Go for Android:

EXPO_BETA=1 expo client:install:android outside of an Expo project or inside of an SDK 41 project.

Running other CLI commands

Other commands will work as expected without the EXPO_BETA environment variable, including build:{android,ios}.

Read the documentation by selecting it from the version selector in the API reference section:

https://docs.expo.io/versions/v41.0.0

What to test

Try ejecting your app and running it: expo eject. Did it work without any changes? Perfect! No? Please report it on the SDK 41 Beta Eject Issues Issue.
Media library and permissions changes made for Android R may impact your app. We'd appreciate your feedback on how they work for your app.
Did we miss updating the documentation somewhere? Let us know.

How to report issues

Create an issue on https://github.com/expo/expo/issues and be sure to fill out the template.
Figuring out the underlying causes of issues is super helpful.
Let us know that you are using the SDK 41 beta so we can prioritize the issue.

Thank you for helping us with testing the release, we look forward to shipping it soon! 🚀

Expo Application Services (EAS): Build and Submit

Expo Team — Tue, 15 Dec 2020 19:31:09 +0000

Today we're excited to announce the public preview of two brand new services: EAS Build and Submit. These are the first services available from Expo Application Services (EAS), our new cloud services.

EAS Build

Feature Preview

EAS Build is a new service that takes everything good about the Expo build service (expo build:[ios|android]) and makes it available to all React Native apps. You can set your app up to build for distribution in minutes or even less, thanks to automatically managed app signing credentials and defaults that just work for most Expo and React Native apps.

In this screenshot, we go from a brand new project to release build running on EAS Build in 30 seconds.

We've also added support for "internal distribution" - a feature that makes it easy for you to share test builds with colleagues and friends without going through an app store, by using ad hoc provisioning on iOS and standard APK side-loading on Android. Generating and updating the ad hoc provisioning profile can be handled entirely for you by EAS Build.

Easily share builds with your team using “internal distribution”.

EAS Build currently works best with bare React Native apps. If you use the Expo managed workflow and end up needing to move to the bare workflow, you can transition seamlessly to EAS Build - just run eas build instead of expo build after ejecting.

Coming later in 2021: full support for Expo managed workflow

With EAS Build, you can include libraries with native code that aren't part of the Expo standard library. For many of you, the Expo managed workflow is nearly a perfect fit - except for that one piece of functionality you absolutely have to have in your app, but that isn't part of the Expo standard library (whether that's IAP support, WebRTC, Bluetooth, or something more esoteric).

EAS Build will let you use any compatible library from GitHub or npm or that you write yourself, even if it has native code in it.

EAS Build also lets you build smaller, stripped-down binaries that include only the code your application needs, which means a smaller install size for your users.

There's already early support for Expo managed apps in EAS Build in the preview, but it's not quite ready for production yet. There's also a big missing piece: how do you get a new version of your Expo development client app that includes your bespoke native runtime? We're working on this, and we'll have answers for you in the coming months.

These are some of the most common requests we hear from Expo developers today, so we're extremely excited to be close to getting a solution into your hands.

EAS Submit

Feature Preview

When you want to put your app into the App Store and Play Store, you can use a single command from your terminal or from CI to submit it.

When you run eas submit, your app binary will be uploaded to EAS and then submitted to the respective app store from there. This means fewer dependencies to install on your machine, and that you can submit your apps from your Windows, Linux, or macOS computer to any app store.

We guide you through your first submission and try to make your nth submission as easy as possible by catching common mistakes and giving you guidance on how to resolve them. For example, if you're missing a privacy policy, we have an FYI for that.

Expo Application Services (EAS)

Expo is the open source project, and Expo Application Services offers hosted cloud services built for both Expo and React Native.

You won't need EAS to use Expo, which will always be open source and free. You can choose a different CI/CD service or use your own hardware.

Likewise, you'll be able to take advantage of EAS with any React Native project, whether or not it uses Expo's open source tools. EAS is designed for developers who specifically want their builds, updates and/or other parts of their app operations, development and collaboration workflows streamlined by a cloud service designed purposefully for and deeply integrated with React Native and Expo.

How does EAS relate to the Expo services that I'm already using for builds, updates, and notifications?

We don't want to disrupt anyone who is counting on Expo services to make software, and so we'll continue to operate the existing build, update, and notification services indefinitely. So, if you're happy with the way you're using those services now, you don't need to do anything differently and you can continue using them.

To reduce confusion with EAS versions of the services, we're going to start calling the existing free services the "Classic" Expo services. So, "Classic" Build, Updates, and Notifications.

That said, EAS is where most of our investment and effort on the services side will go in the future, so you should expect to see each EAS service keep getting better, more powerful, and easier to use as time goes on. Keep an eye out for the EAS Update preview, launching in early 2021.

How much will EAS services cost to use?

We'll always maintain a free tier that can meet the needs of individual and hobbyist developers building small apps. We'll announce further pricing details closer to the date when EAS services graduate from preview in 2021.

If I'm already an Expo Developer Services subscriber, how does this affect me?

If you're currently paying for Expo Developer Services, we've automatically updated your plan to EAS Priority Plan. EAS Priority will have the same price point and feature set as your old Developer Services plan, plus preview access to EAS Build and Submit. You don't need to do anything: you'll be moved over automatically.

How can I try EAS Build and Submit right now?

The previews of EAS Build and Submit are available to developers subscribed to the EAS Priority Plan. If you're not yet a subscriber, you can try it out for free for a month. If you want to try the preview services out but don't have access to a credit card, please reach out to us on Twitter and we can help you out.

Once you're signed up, you can find everything that you need to know in the Feature Preview documentation. If you'd like to watch a quick video walkthrough of EAS Build and Submit, check out this YouTube video:

Expo SDK 40 is now available

Expo Team — Wed, 09 Dec 2020 21:01:16 +0000

Today we’re announcing our fourth and final SDK release of 2020, Expo SDK 40. SDK 40 includes React Native 0.63, mostly the same version as SDK 39 but with some additional bugfixes cherry-picked on top 🍒. Thank you to everyone that helped with beta testing!

⚡️ Highlights

Updated icons and types for @expo/vector-icons

@expo/vector-icons has been updated to track the latest icon sets from react-native-vector-icons@7.1.0 (the previously tracked version was 6.6.0). Updated icon sets:

MaterialCommunityIcons to 5.3.45,
MaterialIcons to 4.0.0, FontAwesome 5 to 5.13.0, and
Feather to 4.28.0.

If you use the updated icon sets, please check your app to ensure that every icon that you use is still included.

The update also improves the TypeScript types to add support for autocompletion and validation of the name prop on all icon families.

Reanimated 2 release candidate available

Now with more bugfixes and improvements, the react-native-reanimated v2 release candidate is available in SDK 40! It’s also easier to install: just yarn add react-native-reanimated@2.0.0-rc.0 and add the Babel plugin, and you're good to go. Learn more in the documentation.

Background location is now an opt-in permission on Android

Most users do not use this permission and it raises red flags during Play Store submission, so we’ve decided to make this permission opt-in rather than opt-out (it’s easier to fall into the pit of success).

If you use background location features on Android, you’ll need to add "ACCESS_BACKGROUND_LOCATION" to the list of permissions in android.permissions in your app configuration file (app.json or app.config.js), if you haven't done so already. More context is available in this pull request.

@expo/dev-server is used in all apps SDK 40 and onward

Expo CLI previously started a Metro dev server for transforming, bundling, and serving your app via @react-native-community/cli . We've now decoupled the configuration required to start a Metro server for React Native from React Native CLI and are able to start Metro directly using its public JavaScript API. This has a number of benefits:

🚀 Publishing is faster! An early adopter reported a 33% improvement, and we’ve seen similar results.
🐛 No more ENOSPC errors with expo publish on CI.
🔧 File extensions (sourceExts) can now be customized in metro.config.js rather than packagerOpts.sourceExts in app.config.js or app.json
😬 Running expo publish inside of a project with a running development server no longer kills the Metro process for the development server.
A number of other issues were resolved.

If you run into any issues in SDK 40 and suspect this change may be related, you can revert back to using the old process by setting the environment variable EXPO_USE_DEV_SERVER=0.

Expo client & standalone apps are now built with Xcode 12

We switched over expo build for SDK 37+ projects to be built with Xcode 12, and with SDK 40 the Expo client app is now built with Xcode 12 too. This resolves a confusing inconsistency in between the client and standalone apps around the DateTimePicker UI.

Constants.manifest is now available in Bare workflow apps

On our quest to continue eliminating any inconsistencies between the Managed and Bare workflow, Constants.manifest is now available in Bare workflow apps initialized with expo init or through expo eject. To add it to an an existing project, update to the latest version of expo-constants and follow these instructions.

Direct control over entitlements in standalone apps

You can now use the ios.entitlements key to customize your app entitlements as needed. For example, you can add the WiFi Info entitlement so that your standalone apps can access WiFi Network SSIDs.

Improvements to expo-notifications

This release fixes two long-standing bugs in expo-notifications: push tokens will no longer remain the same when restoring a device from a backup, and listening for notification responses is much more consistent with the new useLastNotificationResponse hook! There are plenty of other bug fixes, as well as brand new features (like scheduling weekly notifications), but as always make sure to look through the breaking changes just in case they affect you. Thank you for all the high-quality bug reports that allow us to continually improve libraries like expo-notifications!

🍏 Apple App Store privacy update

As of December 8, 2020, new app submissions and updates are required to provide information about their privacy practices in App Store Connect. See App privacy details on the App Store for more information.

For guidance, please refer to the Deploying to App Stores guide.

🌐 Expo CLI

Expo CLI is now 10% smaller and installs ~12 seconds faster! We upstreamed improvements to our dependency on create-react-app, reducing it by ~63%.
You can now sync your Bare projects with your Expo config by re-running expo eject — we'll move to rename this command in upcoming versions.
Improved support for Simulators, Emulators, and unauthorized Android devices:

🍩 Snack improvements

As of December, Snack has a new home 🏡 at the expo/snack monorepo. The monorepo will make it easier for developers to find documentation, contribute, and report bugs. This’ll be your place to go when you want to integrate Snack examples in your documentation. It currently contains the documentation and the snack-sdk package, and other packages such as the website and "snackager" (the Snack packager) will be moved there as well.

A new major version of the snack-sdk (v3) has been released to developers! It's faster, easier to use, comes with shiny new documentation and lots of tests. We've already battle-tested it on the snack.expo.io website and snack-sdk@3 is now available on the new expo/snack monorepo. It supports SDK 40 and has smart dependency management (similar to expo install) to help with selecting compatible package versions.

🏡 Visit the new expo/snack monorepo.

A note about missing dependencies on Snack

As of SDK 40, Snack requires that all used dependencies are added to package.json. This allows us to load a leaner runtime and provide faster and more accurate code completion. Any dependencies that are missing will be visible in the Problems Panel and can be added or updated using the provided action. Some of these missing dependencies already showed a warning in SDK 39, but will now result in an error as of SDK 40.

🏗 Deprecations, renamings, and removals

LegacyNotifications has been removed in favor of expo-notifications

The legacy Notifications library (imported from the expo package) has been deprecated since SDK 38, and will be removed in SDK 41. If you're still relying on this package, you should upgrade to the new expo-notifications library, which has plenty of improvements and shiny new features!

expo-random is now a peer dependency of expo-auth-session

Starting with SDK 40, when you install expo-auth-session you will also need to install expo-random.

If you use the latest version of expo-cli, expo upgrade will handle installing expo-random for you if your project includes expo-auth-session in its dependencies.

`AppLoading` has been extracted from the expo package

If you use this component, you should run expo install expo-app-loading and import AppLoading from its own package: import AppLoading from 'expo-app-loading';. This is part of an ongoing effort to make the expo package as lightweight as possible.

@react-native-community/picker is now @react-native-picker/picker

In September, the policy for the React Native Community organization was changed to focus on tooling and discussions to support the React Native ecosystem, and it is no longer is a host for libraries maintained by various React Native users (learn more here). As a result, libraries that were once part of the React Native Community are now rebranding under their own namespaces. This is the first of those renames that has impacted the Expo SDK, but we expect there to be more in the future.

You can transition to the new package name by uninstalling @react-native-community/picker, then running expo install @react-native-picker/picker and updating all of your imports accordingly in your app code.

Clipboard and CheckBox continue life in the Expo SDK

As React Native continues to remove APIs in order to focus on its core functionality, Clipboard and CheckBox have been deprecated and slated for removal in the upcoming React Native 0.64 release. You can switch over to expo-clipboard and expo-checkbox today in preparation for their removal. These APIs are almost identical, but there are some slight differences in order to have them fit in with the rest of the Expo SDK, so please refer to the expo-clipboard and expo-checkbox documentation when switching.

Global APIs set by the expo package are now deprecated

Expo has historically exported several APIs on the global __expo and Expo objects in order to make it easier for libraries to interoperate between Expo's Managed environments and Bare React Native projects. This isn't necessary anymore, and we've deprecated these globals and slated them for removal in SDK 41. Learn more on expo.fyi.

👋 Dropping iOS 10 support in the near future

iOS 10 is the last version of iOS that still supports 32-bit simulator builds (x86), and to keep Expo npm packages smaller, we plan to publish only 64-bit pre-build binaries for simulators (x64 and arm64). This has been past due — the last time we dropped an iOS version was over two years ago, when we dropped support for iOS 9 in September 2018. Apple no longer reports usage statistics for iOS 10 directly, but you can get a rough idea from reading the App Store — iOS and iPadOS usage table — 6% of all devices use iOS 11 or lower at the time of writing.

🧹 Dropped SDK 36; will drop SDK 37 next release

We routinely drop SDK versions that have low usage in order to reduce the number of versions we need to support. This release sees the end of life for SDK 36. As usual, your standalone apps built with SDK 36 will continue to work; however, SDK 36 projects will no longer work within the latest version of the Expo client. If you want to re-run expo build, then you’ll need to upgrade from SDK 36, preferably to SDK 40 so you won’t need to update again for a while (and also because each Expo version is better than the last!).

Our next release is planned for March 2021 and, at that time, we’ll be dropping support for SDK 37. If your project is running on SDK 37, consider upgrading to a newer version in the coming months.

➡️ Upgrading your app

Managed workflow

Here’s how to upgrade your app to Expo SDK 40 from 39:

Run expo upgrade in your project directory (requires the latest version of expo-cli, you can update with npm i -g expo-cli).
If you use metro.config.js in your project, please ensure that you use @expo/metro-config instead of the metro-config package for getDefaultConfig. Learn more.
If you are still using react-navigation v4 along with react-native-screens, please refer to this comment to handle upgrade warnings.
Refer to the “Deprecations, renamings, and removals” section above for breaking changes that are most likely to impact your app.
Make sure to check the changelog for all other breaking changes!
Update the Expo app on your phones from the App Store / Google Play. expo-cli will automatically update your apps in simulators if you delete the existing apps, or you can run expo client:install:ios and expo client:install:android.
If you built a standalone app previously, remember that you’ll need to create a new build in order to update the SDK version. Run expo build:ios and/or expo build:android when you are ready to do a new build for submission to stores.

Bare workflow

Install the latest version of CocoaPods — 1.10.0 or greater is required.
Run expo upgrade in your project directory (requires the latest version of expo-cli; you can update with npm i -g expo-cli).
No additional upgrade steps are required to use react-native 0.63.4 from 0.63.3. (See the React Native upgrade helper for more detail.)
Rebuild your native projects with yarn ios and yarn android.
Make sure to check the changelog for other breaking changes!

Expo SDK 40 beta is now available

Expo Team — Tue, 01 Dec 2020 00:53:33 +0000

Learn about the changes, how to try it out, and how to give feedback.

As promised, our first-ever beta SDK release is now available! The beta period will last approximately one week, and it is an opportunity for developers to ensure that the new release does not introduce any regressions for their particular system and app configurations.

SDK 40 beta includes React Native 0.63, the same version as SDK 39. The full release notes won't be available until the final release, but you can browse the changes in the expo/expo CHANGELOG to learn more about the scope of the release and any breaking changes.

A few changes to be aware of

AppLoading has been removed from the expo package. If you use it, you should expo install expo-app-loading and import AppLoading from its own package (possibly before first running your app with SDK 40 if you'd like to head off an error screen). Import it using import AppLoading from 'expo-app-loading'.
If you use React Navigation and react-native-screens, you will want to update to React Navigation v5 or silence the related warning from react-native-screens.
If you use background location features on Android, you will need to manually add "ACCESS_BACKGROUND_LOCATION" to the list of permissions in android.permissions in your app configuration file (app.json or app.config.js) if you haven't done so already. Background location is now an opt-in permission on Android (#10989).
@expo/vector-icons has been updated to track the latest icon sets from react-native-vector-icons@7.1.0 (the previously tracked version was 6.6.0). Updated icon sets: MaterialCommunityIcons to 5.3.45, MaterialIcons to 4.0.0, FontAwesome 5 to 5.13.0, and Feather to 4.28.0.

How to try out the beta release

You will be able to opt in to using the SDK 40 beta by setting the EXPO_BETA environment variable to 1 (or some truthy value).

Install the latest version of expo-cli:
- npm i -g expo-cli (SDK 40 requires expo-cli@4.0.6 or greater)
Initialize a new project with SDK 40 beta:
- EXPO_BETA=1 expo init
Upgrade an existing project:
- EXPO_BETA=1 expo upgrade
Install the latest Expo client app for iOS:
- To your simulator: EXPO_BETA=1 expo client:install:ios outside of an Expo project or inside of an SDK 40 project
- To your physical device: use this TestFlight open beta link.
Install the latest Expo client app for Android:
- EXPO_BETA=1 expo client:install:android outside of an Expo project or inside of an SDK 40 project.
Other commands will work as expected without the EXPO_BETA environment variable, including build:{android,ios}.
Use the beta release on Snack by adding a query parameter:
- http://snack.expo.io/?sdkVersion=40.0.0. Note that the in-browser simulators do not yet support SDK 40.
Read the documentation by selecting it from the version selector in the API reference section (or clicking here).

How to report issues

Create an issue on https://github.com/expo/expo/issues and be sure to fill out the template.
Figuring out the underlying causes of issues is super helpful.
Let us know that you are using the SDK 40 beta so we can prioritize the issue.

Thank you for helping us with testing the release, we look forward to shipping it soon! 🚀

Coming soon: Beta release period for Expo SDK

Expo Team — Mon, 19 Oct 2020 18:59:16 +0000

Beginning with SDK 40, we will be trying out an SDK beta release period for approximately one week before the final release. The beta release is an opportunity for developers to ensure that the new release does not introduce any regressions for their particular system and app configurations.

This is no substitute for rigorous internal testing, but we can only cover so much of the surface area on our own. Expo tools run on an endless variety of configurations: Node and Node package managers, macOS/Windows/Linux, Android/iOS/web across different versions and vendors in emulators and on devices, standalone apps and Expo development clients, managed and bare workflows, third-party libraries and services, and so on.

The process of releasing an SDK update after the initial release is time consuming, laborious, and potentially disruptive to developers already using the SDK for their projects. As a result, if a regression makes it into a final release we may in some cases have to delay shipping a non-critical fix until the following SDK release. If you encounter a regression during the beta release period, you can be confident that the Expo team will be available and focused on investigating, resolving, and shipping fixes during this time.

How will I be able to opt-in to beta releases?

At the time of publishing this article, there is no beta release active — we will announce beta releases on our blog (Medium and dev.to) and Twitter (@expo). Once a beta release is live, participating in the beta will involve the following changes from your typical workflow.

iOS and Android beta development clients

You will be able to access an iOS client build for your device from a TestFlight Public Beta link and you will be able to install the updated client in your simulator by running expo client:install:ios --latest with the EXPO_BETA=1 environment variable set.

The Expo client app for Android will be installable for both devices and emulators with expo client:install:android --latest and EXPO_BETA=1.

Upgrading your project to the beta SDK

Similarly, to upgrade your project you will run expo upgrade with the EXPO_BETA=1 environment variable set. Other expo-cli commands will work as expected without the environment variable or any other flags.

Beta API documentation

You will be able to access the API reference for the beta version from the version selector in the docs.

Where you will be able to find the beta documentation when it is available.

We hope that you will help us to kick the tires on our new releases during the beta release period!

You can read a more detailed description of our full release process in our open source Release Workflow document if you would like to learn more about what goes in to preparing and shipping each SDK release after all of the code has been written.

Expo SDK 39 is now available

jess (she/her) — Mon, 21 Sep 2020 23:07:01 +0000

Today we're announcing our third release of 2020, Expo SDK 39. SDK 39 brings tons of quality-of-life improvements across our entire suite of tools: the Expo development clients, Expo CLI, documentation, and of course our SDK. Read on for more details!

🐛 Known Regressions (Updated 03 Oct 2020)

Significant known regressions that have been brought to our attention have been resolved. Read more here, and thank you for bearing with us!

⚡️ New SDK features

Support for iOS 14, React Native 0.63 and React Native for Web 0.13!

SDK 39 is fully compatible with the newly released iOS 14. Past apps built with SDK 38 also should work well on iOS 14 but we recommend staying up-to-date when you can.
It also includes support for React Native 0.63, letting you take advantage of features like the newly designed LogBox, Pressable component, and support for Native Colors. Read more about React Native 0.63 here.
Finally, SDK 39 jumps from v11 to v13 of web! RNW 13 uses React 16.13.1, which will get rid of a bunch of warnings that developers were seeing on web related to lifecycle methods.

Interactive notifications in `expo-notifications`

We’ve added support for notification categories (otherwise known as interactive notifications) to the new expo-notifications library! Categories allow you to send notifications that your user can interact with without even opening your app, as well as take action based on how they interacted with this notification. Here's an example of this in action on Android and iOS:

With this latest feature, expo-notifications now has all the functionality (and more!) of the legacy Notifications module, so we highly recommend transitioning. (That legacy module is still available in SDK 39, but will be removed in the near future.) To learn more, read through the documentation.

QR code scanning on web

You can now scan QR codes from your web apps using expo-camera.

Google AuthSession

Our universal authentication module, expo-auth-session, now has built-in support for Google sign-in. Setup is much faster with far less code. Learn more here.

import { useAuthRequest } from 'expo-auth-session/providers/google';

const [request, response, promptAsync] = useAuthRequest({
  expoClientId: '...',
  iosClientId: '...',
  androidClientId: '...',
  webClientId: '...',
});

Screen capture listener in `expo-screen-capture`

In SDK 38, we added the expo-screen-capture module, which allows you to prevent screenshots and screen recordings of your app.

Sometimes you don't want to prevent screenshots, but you would like to perform some action when a user screenshots a particular screen (ahem, @Snapchat) — so in SDK 39 we’ve added ScreenCapture.addScreenshotListener to allow developers to do just that.cal

(Thanks to everyone who participates in our feature requests to help us identify desired features like this one! 🙏 )

New Updates & SplashScreen modules in Managed workflow

We've integrated the new expo-updates and expo-splash-screen unimodules into the Managed workflow. If you still import either the Updates or the SplashScreen module from the expo package, you'll need to install the individual unimodules packages when you upgrade to SDK 39.

One change this brings is that your updates app.json configuration is now applied at build-time rather than at runtime. We think this is more intuitive than trying to update configuration for over-the-air updates...over the air. Check out the Updates module documentation for a few other small API changes.

Note that we do not yet support dark mode splash screens in the managed workflow (we're working on it!); for now, you'll need to stick with the bare workflow if you need this feature.

New synchronous method in `expo-random`

We've added a synchronous method, Random.getRandomBytes(), to expo-random. This enables polyfills for crypto.getRandomValues(), such as react-native-get-random-values, to enable usage of packages like uuid in managed apps.

Experimental: `react-native-reanimated` v2 alpha support

The second major version of this library offers a much easier API, along with significantly improved performance characteristics. It requires some extra configuration that you must opt into in order to use; read more in our documentation.

Alternatively, you can skip the manual configuration steps if you want to just create a new app with this configured already:

npx crna --template with-reanimated2

💡 We're still working on support for react-native-reanimated v2 alpha in Snack; this may be available in the coming weeks after this release.

📱 Expo development client apps

Synchronous app loads

All projects now load synchronously in the iOS and Android Expo development clients! Previously, the loading behavior of published projects was based on their updates configuration in app.json; this configuration now applies only to standalone apps. This means that when you're developing or testing your project or showing it to stakeholders, you'll always have the latest version.

Also, we've added an indicator to the loading screen to give you more information about what's happening. (Don't worry, this won't show up in your standalone app!) And if you want to remove it in the Expo client, simply publish your project with "developmentClient": { "silentLaunch": true } in your app.json.

New project details screen

Long-press on projects to see more info about them. Pressing on a project that requires an unsupported SDK version will now open the details screen, rather than attempting to open the project and showing an error.

Password autofill

SDK versions

See what SDK version your projects are using and whether they need an update.

📝 Docs improvements

Our docs recently got a makeover! Most of the changes are subtle but we hope they will make your reading experience easier and more pleasant. They'll also feel more like part of the expo.io website. Be sure to check them out as you're upgrading to SDK 39.

We’ve also added a right sidebar to Guides and API Reference to show the table-of-contents for those pages. If, like us, you find yourself jamming on ⌘/Ctrl+F to dig through reference docs, this’ll help you get a quick sense of the page as a whole, and jump straight to what you need.

🍩 Snack improvements

Snack now checks all TypeScript and JavaScript files for lint errors. You can easily see files that need your attention in the file explorer, or even jump directly to the error from the Problems tab:

🐛 Bug bash

We celebrated SDK 38 by organizing an internal "bug bash" to take an extra-deep dive through the GitHub issues in both the Expo and Expo CLI repositories. Throughout the month of July, we addressed over 420 issues noticed and opened by all of you, and shaved more than 20% off the day-to-day issue counts. We want to thank everyone who opens high-quality issues to help make Expo better for us all.

Some of the most notable changes surfacing from our bug bash come from expo-av. Background audio on iOS is much more reliable, we improved stability and memory usage on both platforms, and addressed plenty of other bugs and edge cases. But there were many fixes across our entire SDK: almost every package was touched at least once! You can see the full list of changes in the changelog.

Android permissions

We also did a full audit of how we handle native Android permissions as part of our bug bash. With the help of your feedback, we updated our permissions documentation to better communicate each module's required and optional permissions. We also added more context around the behavior of permissions on different platforms. If you still have questions, or are unsure about the permissions in your standalone app, don't hesitate to ask in our forums!

🌐 Expo CLI

This version brings TONS of features and quality-of-life improvements across our entire CLI. Here are a few of the fun ones!

Programmatic access

Personal Access Tokens let you run any expo action (other than signing in and out) in CI or scripts without sharing your personal credentials. You can generate distinct tokens for each service, monitor usage, and disable individual tokens in the unfortunate event that your credentials are compromised.

Selecting devices

You can now pick which device or simulator to run your app on.

After running expo start, press:

shift+i to select an iOS simulator
shift+a to select a connected Android device or emulator. You can also run your project on multiple Android devices at the same time.

Apple Keychain support

Now you can skip typing your Apple ID email every time you want to build or upload iOS apps! The Apple ID is suggested from the last email you entered—just press enter to use it again.

MacOS users can also use the native Keychain to autofill the password automatically when building, and uploading iOS apps. This can be disabled with EXPO_NO_KEYCHAIN=true. Learn more here.

Publish stats

When publishing to Expo's hosting service (via expo publish), you can now see the JavaScript bundle sizes for each platform. Smaller bundles means faster startup time. For a full size breakdown, use our bundle visualizer.

New help menu

Running expo --help shows a newly redesigned menu:

Export public-url prompt

Running expo export will now prompt you for a public-url if you didn't already provide one.

Eject improvements

We've been gradually rolling out improvements to eject, and with SDK 39 nearly all of your config in app.json / app.config.js will be applied to the generated native projects when you run eject. Some of the recent improvements include:

iOS and Android app icons and splash screens support.
iOS locales and iPad support.
Android backups.
iOS and Android now have their bundle ID or package name added to the list of URI schemes. This mirrors how expo build works, and makes authentication APIs easier to setup.

The only property that is not yet applied automatically is iCloud entitlements, and you can enable this in Xcode.

⚠️ Service workers on web are now opt-in

Starting in SDK 39, offline support is no longer enabled by default in Expo's Webpack config. You can opt-in to offline support and service workers by customizing the Webpack config; more info here.

🧹 Dropping SDK 35, will drop SDK 36 next release

We routinely drop SDK versions that have low usage in order to reduce the number of versions we need to support. This release sees the end of life for SDK 35. As usual, your standalone apps built with SDK 35 will continue to work; however, SDK 35 projects will no longer work within the latest version of the Expo client. If you want to re-run expo build, then you’ll need to upgrade from SDK 35, preferably to SDK 39 so you won’t need to update again for a while (and also because each Expo version is better than the last!).

Our next release is planned for December and, at that time, we’ll be dropping support for SDK 36. If your project is running on SDK 36, consider upgrading to a newer version in the coming months.

Upgrading your app

Managed workflow

Here’s how to upgrade your app to Expo SDK 39.0.0 from 38.0.0:

Run expo upgrade in your project directory (requires the latest version of expo-cli, you can update with npm i -g expo-cli).
If you import the SplashScreen or Updates modules from the expo package, install and import from the expo-splash-screen / expo-updates packages instead. (See the Updates documentation for additional small API changes.)
Make sure to check the changelog for other breaking changes!
Note that there are two known issues with the iOS and Android development clients for SDK 39; one related to a SplashScreen warning and one related to reloading projects by pressing 'r' twice.
Update the Expo app on your phones from the App Store / Google Play. expo-cli will automatically update your apps in simulators if you delete the existing apps, or you can run expo client:install:ios and expo client:install:android.
If you built a standalone app previously, remember that you'll need to create a new build in order to update the SDK version. Run expo build:ios and/or expo build:android when you are ready to do a new build for submission to stores.

Bare workflow

The Bare workflow lets you operate independently of the Expo SDK cycle, updating RN versions and versions of individual Expo packages however and whenever you want. However, if you’re excited to go ahead and update everything right now:

Run expo upgrade in your project directory (requires the latest version of expo-cli; you can update with npm i -g expo-cli).
Before running your app again, you’ll also need to manually apply changes to your native projects in order to upgrade to RN 0.63.2. (See the React Native upgrade helper for more detail.) Once that’s done, run npx pod-install, then rebuild your native projects with yarn ios and yarn android.
Make sure to check the changelog for other breaking changes!
Warning: if you use any custom Babel configuration (e.g. babel-plugin-module-resolver), you may encounter this bug with React Native 0.62.2. The React Native team is aware of the issue and working on a 0.63.3 release that includes the fix. The workaround we recommend for now is to pull the diff from this pull request into your project using patch-package.

🗣 If you have general questions or comments, please share them in our community forums! We also welcome issue reports (and, of course, PRs) on Github.

Expo SDK 38 is now available

Eric Samelson — Thu, 25 Jun 2020 17:54:15 +0000

Today, we're announcing our summer 2020 release, ☀️😎 Expo SDK 38 🍉☀️ ! SDK 38 continues both our focus on reliability and our investment in developer flexibility, as we work towards supporting fully customizable apps across Expo's entire suite of tools. Additionally, SDK 38 includes support for React Native 0.62, new and revamped templates, and a couple of useful new modules.

SDK 38 is the second of four quarterly SDKs we plan to release this year. Read on for more details about what's included!

⏰ New Notifications API in Managed workflow

Earlier this year, we embarked on a complete rewrite of the Expo Notifications module. We're excited that the revamped API is now more predictable, lets you control your notifications more easily, and is 100% compatible with both the Bare and Managed workflows! Check out the documentation for the new expo-notifications API here.

One change we especially love is how notifications are now handled consistently across platforms. Notification behavior now follows a simple rule of thumb:

If the notification is triggered while the app is in background,

it's presented immediately
the application is not informed of this

If the notification is triggered while the app is in foreground,

the application not only receives immediate information about this, but…
it can also decide at runtime whether to display a heads-up alert or play a sound! (For more information see the Notification Handler documentation.)

Unfortunately, in preparing this module within our 2020 commitment to time-based releases, we weren't able to include support for notification categories. We're working to land it ASAP in expo-notifications, and then it'll be available in the Bare workflow immediately, so sit tight!

Migrating from the legacy Notifications API

The legacy Notifications API (import { Notifications } from 'expo';) remains in SDK 38 for compatibility purposes, but it is deprecated and we expect to remove it in an upcoming release.

On Android, notifications can only be forwarded to one of the two APIs at a time, so you'll need to explicitly opt into the new API for now by setting android.useNextNotificationsApi to true in your app configuration. If the value is undefined or false, push notifications will only be forwarded to the legacy notifications API on Android. On iOS, you can use the new API with no extra configuration.

🦋 Build-time Updates in Bare workflow

With our last release, we introduced expo-updates, a brand-new library that lets you use over-the-air updates in any React Native app. Check out the documentation here.

We recently released an updated version of this library, expo-updates@0.2.x, which simplifies the workflow around updates in Bare workflow apps. Specifically, it introduces build-time updates, which means

release builds will create and embed a new update from the JavaScript source on disk at build-time, rather than embedding your latest published update; and
you no longer need to run expo publish before creating a release build for the first time.

For more detail, including how to upgrade from expo-updates@0.1.x, read this walkthrough.

⚡️ Faster Tooling, Better Performance

We're especially excited about some changes that have been in the works to make your development and bootstrapping experience even snappier!

First, we're bringing back the fastest way to create a React Native app. The new and improved create-react-native-app now has support for web along with iOS and Android, includes OTA updates out of the box, has 25+ templates you can choose from, and zero dependencies! Read more here.

Additionally, if you choose to use the more powerful features of expo-cli instead, you'll notice it's a lot faster to install; we've decreased the overall disk space usage by as much as 2.6x. And if you bootstrap a new SDK 38 project, the footprint of its node_modules will be 13% smaller than a comparable SDK 37 project.

The performance of these packages has been improved, too; we're shipping transpiled JS rather than JSX, and have dropped prop-types in favor of TypeScript, both of which bring faster compilation times.

💡 Revamped tabs template: simpler, dark mode support, TypeScript

We rebuilt the tabs template in TypeScript, removing all the fluff and focusing on the essentials needed to set developers out on a good path building their apps. We also built in dark mode support, because we've found that it's a lot easier if you think about it from the start rather than retrofitting it later on.

iOS is pictured above, but as always the template works just as well on the other platforms Expo supports: Android and Web.

✨ New Features

Authentication
Google Fonts
Screen Capture
Status Bar
Linking
Slider
Picker
Storage

Reimagined Authentication

We’ve completely rewritten expo-auth-session with primitives like Expo WebBrowser and Crypto. This reduces app size and decreases the need for native rebuilds since it can be used with many different providers. We can also update constantly between SDK releases with bug fixes and feature additions! You can check out our guides for 15+ different providers which we update frequently.

Google Fonts

The @expo-google-fonts packages for Expo allow you to easily use any of 991 fonts (and their variants) from fonts.google.com in your Expo app.

These packages and all these fonts work across web, iOS and Android, and are free to use and open source. Read more detail here and in the documentation.

New Screen Capture module

To give developers more power over the security of their apps, we added the expo-screen-capture module, which will allow you to hide your app's content when a user is screen recording or taking screen shots; this is particularly useful if a screen displays sensitive information. For references, examples, and limitations, check out the documentation.

New Status Bar module

We've also created an expo-status-bar module with a few important improvements over React Native's built-in StatusBar API. This new module sets the status bar to translucent by default on Android, and it also supports light and dark mode through the style="auto" and style="inverted" props. We have added expo-status-bar to every project template in expo-cli. Read the documentation and also check out the updated "Configuring the Status Bar" guide.

Improved Linking

The new expo-linking package makes it easier than ever to create deep links that work in both managed and bare workflow projects, and integrates smoothly with React Navigation v5 and our Auth Session APIs.

Third-Party Modules

Modules are extracted from React Native all the time to improve performance. To keep the runtime up to date, we've improved performance and added web support to some of the extracted packages to make them compatible with the Expo ecosystem.

The following packages are now available in the Expo client:

@react-native-community/slider
@react-native-community/picker
@react-native-community/async-storage
@react-native-community/segmented-control

Finally, you can now use @react-native-community/async-storage in Managed workflow apps. This change is backwards-compatible, so you don't need to update to SDK 38 to start using it. This doesn't add any new features or improvements, but it does help you integrate more easily with other libraries that assume you use @react-native-community/async-storage.

These packages are not fully maintained by Expo so test coverage, TypeScript support, and web compatibility may vary. We'll continue to use only the most stable versions of packages.

🛠 API improvements and additions

Background downloads and uploads with `expo-file-system`

Downloading external resources can be a difficult task with a lot of corner cases, such as handling when the application is moved to the background. To help with this, expo-file-system now supports background downloads, which won't be canceled when the user switches between different applications or when your device loses connection to the Internet. We've also added a new method that natively handles file uploads. For more information, check out the documentation.

New `android.softwareKeyboardLayoutMode` app.json key

One tricky part of building forms in mobile apps is that developers need to ensure that the on-screen "software keyboard" doesn't obscure the focused form element. Android lets you pick how you want this to be handled: you can resize the entire window so nothing will be drawn under the keyboard, or you can pan the window so the content is not underneath it. The native property that lets you control this is android:windowSoftInputMode .

In the past, all Expo apps have been configured to use the resize mode, but some developers have found this to be problematic for their apps because UI elements such as tab bars will be pushed up above the keyboard when it is enabled. If you would prefer to use the pan mode, you can now set the layout mode directly with android.softwareKeyboardLayoutMode in your app configuration. Find the key in the "android" section of "Configuration with app.json".

New `android.allowBackup` app.json key

Another security improvement we incorporated into this release is allowing developers to disable Android's Auto Backup feature. For Expo apps built with previous SDKs, your users' app data would be automatically backed up to their Google Drive. This will remain the default in SDK 38 (as it is in Android native apps), but if your app deals with sensitive information then you may want to set this field to false in your app configuration.

React Native 0.62

SDK 38 includes many of the new features and improvements that are part of React Native 0.62, including:

Dark mode support with the Appearance module and the useColorScheme hook (note that these APIs do not support web, so you may want to use react-native-appearance if that's important for your app);
Accessibility improvements, including new props like accessibilityValue and events like onSlidingComplete;
Significant improvements to React DevTools;
an optional new LogBox error and warning experience;

and lots more! Check out the React Native changelog for more details.

Flipper is currently unsupported in the Managed workflow. If you want to use Flipper, you'll need to use the Bare workflow for now (but you can still use all your favorite Expo modules in the Bare workflow!).

Other fixes and improvements

There are lots of other changes included in this release! Check out the full list on our changelog.

🧹 Dropping SDK 34; will drop SDK 35 next release

We routinely drop SDK versions that have low usage in order to reduce the number of versions that we need to support. This release sees the end of life for SDK 34. As usual, your standalone apps built with SDK 34 will continue to work; however, SDK 34 projects will no longer work within the latest version of the Expo client. If you want to re-run expo build, then you’ll need to upgrade from SDK 34, preferably to SDK 38 so you won’t need to update again for a while (and also because each Expo version is better than the last!).

Our next release is planned for September and we will be dropping support for SDK 35 at that time. If your project is running on SDK 35, consider upgrading to a newer version in the coming months.

AR removed

The AR module, which exposes the iOS ARKit library, has been experimental its entire lifetime and is not widely used. Rather than continue to maintain this library, we’ve decided to focus our limited resources elsewhere. Accordingly, the AR module has been removed from all SDK versions in the iOS Expo client version 2.16.0. Read more here.

🌟 ExpoKit → Bare workflow

In December, we shared our plans to spend 2020 making major investments to increasing your flexibility in customizing your apps with native code whenever and however you want. And in March, we announced that the Bare workflow now fully replaces ExpoKit. We’ve reached or exceeded feature parity between the Bare and ExpoKit workflows, and so we deprecated ExpoKit with SDK37, and we no longer support ejecting to ExpoKit in new projects.

As planned, SDK 38 will be the last release of ExpoKit. After SDK 38, your ExpoKit apps in the App Store and Play Store will continue to run indefinitely, but you'll need to migrate to the Bare or Managed workflows in order to get bugfixes and new features in Expo modules.

Read more details, including a guide for migrating ExpoKit projects to the Bare workflow, in this blog post.

⬆️ Upgrading your app

Here’s how to upgrade your app to Expo SDK 38.0.0 from 37.0.0:

Run expo upgrade in your project directory (requires the latest version of expo-cli, you can update with npm i -g expo-cli).
Make sure to check the changelog for other breaking changes!
Update the Expo app on your phones from the App Store / Google Play. expo-cli will automatically update your apps in simulators if you delete the existing apps, or you can run expo client:install:ios and expo client:install:android.
If you built a standalone app previously, remember that you'll need to create a new build in order to update the SDK version. Run expo build:ios and/or expo build:android when you are ready to do a new build for submission to stores.

Note: React Native 0.62 introduced a new warning when using the Animated API for animations. You’ll now need to specify useNativeDriver:true or useNativeDriver:false for all your Animated animations.

Updating ExpoKit to SDK 38

Follow the instructions given in the docs.
Please remember that SDK 38 will be the final update to ExpoKit. To read more, including our recommendations for migrating, see this blog post.

🗣 If you have general questions or comments, please share them in our community forums! We also welcome issue reports (and, of course, PRs) on Github.

Forem: Expo

Introducing EAS Hosting: Simplified deployment for modern React apps

The Challenge of Universal App Deployment

How to Get Started with EAS Hosting

Fingerprint your native runtime with @expo/fingerprint

Meet @expo/fingerprint

Try out @expo/fingerprint 🪄

What’s next: collect feedback and refine workflows

Using @expo/fingerprint with EAS

Expo SDK 50 Release 🚀

Introducing EAS

What is EAS?

EAS Build and Submit

New EAS plans

Enterprise support add-on

Get started with EAS - free!

Thank you!

Expo SDK 41

⚡️ Highlights

🏡 Expo Go

🌐 Expo CLI

🏗 Deprecations, renamings, and removals

➡️ Upgrading your app

Managed workflow

Bare workflow

Expo SDK 41 beta is now available

Notable changes to be aware of

Known regressions

Outstanding

Resolved

How to try out the beta release

What to test

How to report issues

Expo Application Services (EAS): Build and Submit

EAS Build

Feature Preview

Coming later in 2021: full support for Expo managed workflow

EAS Submit

Feature Preview

Expo Application Services (EAS)

How does EAS relate to the Expo services that I'm already using for builds, updates, and notifications?

How much will EAS services cost to use?

If I'm already an Expo Developer Services subscriber, how does this affect me?

How can I try EAS Build and Submit right now?

Expo SDK 40 is now available

⚡️ Highlights

Updated icons and types for @expo/vector-icons

Reanimated 2 release candidate available

Background location is now an opt-in permission on Android

@expo/dev-server is used in all apps SDK 40 and onward

Expo client & standalone apps are now built with Xcode 12

Constants.manifest is now available in Bare workflow apps

Direct control over entitlements in standalone apps

Improvements to expo-notifications

🍏 Apple App Store privacy update

🌐 Expo CLI

🍩 Snack improvements

A note about missing dependencies on Snack

🏗 Deprecations, renamings, and removals

LegacyNotifications has been removed in favor of expo-notifications

expo-random is now a peer dependency of expo-auth-session

AppLoading has been extracted from the expo package

@react-native-community/picker is now @react-native-picker/picker

Clipboard and CheckBox continue life in the Expo SDK

Global APIs set by the expo package are now deprecated

👋 Dropping iOS 10 support in the near future

🧹 Dropped SDK 36; will drop SDK 37 next release

➡️ Upgrading your app

Managed workflow

Bare workflow

Expo SDK 40 beta is now available

A few changes to be aware of

How to try out the beta release

How to report issues

Coming soon: Beta release period for Expo SDK

How will I be able to opt-in to beta releases?

iOS and Android beta development clients

Upgrading your project to the beta SDK

Beta API documentation

Expo SDK 39 is now available

`AppLoading` has been extracted from the expo package

Interactive notifications in `expo-notifications`

Screen capture listener in `expo-screen-capture`

New synchronous method in `expo-random`

Experimental: `react-native-reanimated` v2 alpha support

Background downloads and uploads with `expo-file-system`

New `android.softwareKeyboardLayoutMode` app.json key

New `android.allowBackup` app.json key