DEV Community: Expo Team

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! 🚀

EAS Build — February Preview Update

Expo Team — Thu, 18 Feb 2021 22:04:16 +0000

In December, we announced our preview of two new services: EAS Build and Submit — the first services available from Expo Application Services (EAS).

Today, we wanted to share with you some of the updates and improvements we have been working on based on feedback we’ve received from developers just like you.

Multi-target support

If your iOS app makes use of App Extensions like the Share Extension or the new Widget Extension, you’ll need to provide credentials for every target in your Xcode project.

With our first version of multi-target support, you can now specify these targets by opting into locally managed credentials via credentials.json:

Here we have our main application target multitarget and a Share Extension target shareextension.

With this new support, you’ll be able to use EAS Build to build your iOS apps with App Extensions as well as integrate with services that require them.

In the future, we also plan to add support for multi-target projects to our automatically managed credentials. Until then, you can learn more about multi-target projects via credentials.json in our docs.

Improved monorepo support

yarn/npm install now executes in the root of the workspace in yarn and npm workspaces.

Run your EAS CLI commands from the root of the app directory; for example, if your project exists inside of your git repository at apps/my-app, then run eas build from there. Don't forget — each app directory should have its own copy of eas.json and, if you use it, credentials.json.

If you’d like to learn more, you can check out How to Set Up EAS Build with a Monorepo as well as the EAS monorepo example.

Configurable build environments

We are always looking for ways to add more customization options to EAS Build. With this next step, we’ve added additional configuration options that you can set via eas.json:

extends - name of build profile that current profile inherits values from
image - image with build environment. Learn more about it here.
node - version of Node.js
yarn - version of Yarn
ndk - version of Android NDK
env - environment variables that should be set during the build process (should only be used for values that you would commit to your git repository, i.e: not passwords or secrets).

Your build profile in eas.json could look something like this now!

Currently, only one image is supported on each platform at the moment; however, more images will be available in the future.

Learn more about configuring your build with eas.json.

Additional configuration options for iOS builds

Continuing with greater configuration, you can now add autoIncrement and schemeBuildConfiguration to your eas.json file for iOS projects.

autoIncrement allows you to specify if and how EAS CLI increments your application build version; options include false (default), version, and buildNumber.

schemeBuildConfiguration specifies the configuration to use; either Release or Debug. Otherwise, it defaults to the existing configuration in your project.

To learn more about these options and other configuration options, please check out our documentation on Configuration with eas.json.

npm hooks

We’ve added three EAS Build-specific npm hooks that you can use to run custom scripts:

eas-build-pre-install - executes before EAS Build runs yarn install
eas-build-post-install - executes at a slightly different time depending on the platform: for Android, after yarn install has completed; for iOS, after both yarn install and pod install have completed
eas-build-pre-upload-artifacts - this hook is triggered almost at the end of the build process, just before the build worker uploads your build artifacts to cloud storage

If you were using these npm hooks, your package.json might look something like this:

EAS internal distribution — UI refresh

EAS internal distribution lets you share builds of your app with trusted users without any delays and now it has a fresh new look!

Distribute your ad-hoc builds to approved users who can then download and install with their browser. It’s quick and flexible! Learn more by checking out our EAS internal distribution docs.

Canceling builds

Last, but certainly not least, is canceling builds! 😅 We’ve now added the ability to cancel your builds through both EAS CLI with eas build:cancel [BUILD_ID] as well as on Build Details pages:

More on the way

We’re not done yet! We have more improvements planned as we work towards a full release for EAS Build. Lots of exciting stuff — so do stay tuned!

As a reminder, previews of EAS Build and Submit are available to developers subscribed to the EAS Priority Plan, and they won’t be available on a free tier until they graduate from preview. If you’re not yet a Priority 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 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.

DEV Community: Expo Team

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

EAS Build — February Preview Update

Multi-target support

Improved monorepo support

Configurable build environments

Additional configuration options for iOS builds

npm hooks

EAS internal distribution — UI refresh

Canceling builds

More on the way

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

`AppLoading` has been extracted from the expo package