The Expo SDK 39 Roadmap
After releasing SDK 38 about a week ago and following up on some loose ends, the Expo team is starting to work on SDK 39. Our top priorities for SDK 39 are: support for iOS 14, fixing bugs, the Updates and Splash Screen modules, and internal refactoring. We’ll talk a little bit more about each of these topics, and also cover some other areas of focus for the team overall.
📱 iOS 14
iOS 14 was recently announced at WWDC 2020. The specific release date has not been announced but historically each new major version of iOS has been released mid-September. We are working to make sure that new and existing Expo apps run well on iOS 14 in time for the release.
iOS 14 doesn’t have a lot of breaking changes in it but we need to test that Expo apps work on it. Sometimes internal changes to iOS cause crashes and other launch-blocking issues, such as images not being displayed. This class of general quality assurance is on the SDK 39 roadmap.
Additionally, iOS 14 introduces some privacy-related indicators for the camera, microphone, and clipboard. When an app accesses these features, the OS now displays a visual indicator that they’re being used, like a digital version of the LED in many laptop cameras. We’re going through existing Expo APIs that access sensitive features to make sure they work well with iOS 14.
Finally, we plan to upgrade the builder service to use Xcode 12, the latest version with the iOS 14 SDK. The timing is a bit tight since the new version of Xcode is often released just a few days before the public iOS 14 release. We’ll do our best to upgrade the builders in a timely manner.
🐞 Bug Bash
Another top priority is focusing on bugs and issues with our existing libraries. We are allocating some time to fix bugs and streamline our issue tracking to highlight insightful and well-written issues, which are often the ones we prioritize.
Our goal is to sustainably keep the issue tracker healthy. One component of that is to work on reducing the number of issues as a trend and get dissues/dt negative over time.
🆕 Updates and Splash Screen
We recently released two modules, expo-updates and expo-splash-screen that currently work only in the bare workflow. We’re working on integrating these back into the managed workflow (including the app store development clients and standalone apps built with expo build) to increase parity between the bare and managed workflows.
expo-updates was written with reliability and efficiency in mind. In contrast with the current updates library, expo-updates will make sure all of the assets in an update are downloaded before running the update. This means your app behaves as if the assets were embedded and increases parity between embedded updates and over-the-air updates. expo-updates also periodically deletes assets from old updates that were downloaded to the device, automatically keeping disk usage low.
expo-splash-screen has support for dark mode splash screens. If you launch your app while your device is in dark mode, expo-splash-screen will appropriately display the dark mode version of your splash screen. We think this will be a nice quality-of-life improvement.
✨ Internal Refactoring
Another two of our top priorities are mostly internal-facing. The first is to change an internal mechanism for how in-development projects are identified and run in isolation, and involves changing our ID scheme and primary keys across the client and server. If you’ve ever made a similar change before, you know this is more complicated than at first glance and there be dragons. This work is a prerequisite to other account-related features we’d like to build.
The second is to periodically run our release-related CI jobs before the SDK release. We’ve found that when it’s time to release a new SDK, our release-related jobs often don’t work for small reasons after months of changes to the code. We’ve also moved all of the Expo repository’s CI jobs to GitHub Actions. SDK 39 will be the first release we do using GitHub Actions. By dry running our release-related jobs on a regular basis, we expect to find issues far more quickly and make the release go more smoothly.
💻 Other Investments
If time permits, we’ll look at upgrading some dependencies, like React Native to 0.63.x and React Native Web to 0.13.x. There’s often more than meets the eye to significant dependency upgrades since they touch so much surface area; for example, React Native 0.63 upgrades one of its own dependencies (Folly), which means we also need to test the new version of Folly with older versions of React Native back to 0.61.
Additionally, most of the Expo team’s focus will continue to be on our next-generation services. We’re looking forward to sharing small announcements as new features and services are ready.
We’re generally investing a lot more in streamlining the workflow for more customized apps. We’ve heard and seen that many of the top Expo developers have custom needs that require custom native code. Our goal is to decrease how much developers rely on the Expo team to add new modules. It is very empowering when you are your own bottleneck. The bare workflow achieves a lot of this today and we’d like to go further in this direction.
🗓 SDK 39 Release Date
We’re targeting sometime in September to release SDK 39. We don’t yet have an exact date and are also waiting to learn the iOS 14 release date so we can coordinate SDK 39 to come out on time.
In general, we’ve been releasing new SDKs roughly once a quarter. This has been working well so we plan to keep this approximate cadence for SDKs in the future.
