🛠 Developer Agency

When working on apps, developers look to build the features they envision for the app on a timeline they choose. Achieving these goals is largely up to a developer’s ability and decisions but sometimes a platform or technology can be a bottleneck. In Expo’s case, we see that skilled developers often wish it were easier to write custom native code or contribute back to Expo. We also receive many requests to add more APIs. Some developers also have asked to build their app binaries on dedicated hardware or to host their app JS and assets on their own servers. A common thread across these scenarios is that developers are blocked on Expo in different ways; to address these issues sustainably, we want for skilled developers to have the agency they need to build high-quality apps and for Expo not to be a bottleneck. We have made several ad hoc and systemic changes in this vein and plan to work on several more.

Open-Source-First Development

One of the major structural changes we made was to move development of the Expo client software from a private repo to an open one. In the old model, slices of source code from Expo’s private repo (Universe) were automatically synced to several public repos, similar to how the React Native repo is set up. While this model let us open source the Expo client and let contributors send pull requests, we found it created disparity between the way the Expo team developed in the private repo and the way community contributors developed in the open repo. We were less likely to notice and fix issues with the open repo and extra surface area from the disparate workflows added to our maintenance cost. Our new model structurally minimizes this disparity to encourage more community contributions and easily maintain the open-source workflow.

The main Expo repo is now the source of truth of the Expo client and where both the Expo team and community contributors develop. Making the open GitHub repo the source of truth is a systemically healthier model for Expo compared to syncing from a private repo. As part of this evolution, we made the open Expo repo a monorepo—it now contains the Android and iOS runtimes, many Universal Modules, the JS SDK, test suites, the Expo Babel preset, and more — so the implementation of one idea can be in one coherent commit and PR, even if it spans across multiple platforms and programming languages.

We hope the new model encourages developers to contribute to Expo and feel more able even to fork it if they need to.

The Expo client is developed in the open repo at https://github.com/expo/expo.

One License (MIT)

Along with moving the Expo client’s source of truth to the open repo, we changed Expo’s various licenses (previously a mix of BSD and MIT) to the MIT License across the board. We chose the MIT License for two reasons: it is popular and relatively well-understood, and both React and React Native now use it. In practice, the BSD and MIT licenses are widely accepted and we expect this change not to significantly affect any developers, but hopefully it is simpler to think about just one license for Expo’s code now.

Self-hosted JS

The JS and some assets for Expo apps are typically hosted by Expo and served through our globally distributed CDN. This is convenient, high-performance, and works well for most developers, but some developers have asked for a way to host their code and assets themselves for various reasons.

We added a new command to the Expo CLI called expo export , which exports a set of files you can host from any static web server your app can access. The Expo docs have a guide to Hosting an App on Your Servers and if you find it interesting to learn about the technical choices behind our work, watch Quin Jung’s talk from React Native EU 2018 (22 minutes).

Self-built Standalone Apps

When Expo developers (using the Expo client) are ready to submit their apps to the App Store and Google Play, they use Expo’s standalone app builders to create IPA and APK files with binaries. Like Expo’s hosting service, the standalone-app builders are convenient and work well for most developers. However, the builder service is shared and sometimes there are wait times or builders go down. We are working on addressing these issues but also wish to give developers more agency when it comes to building standalone apps. To this end, we’ve been working to make the Expo standalone-app builder open source.

The builder, called Turtle CLI (standalone Expo apps are also known as “shell apps” 🐢), is a program you can run on your own computer, server, or CI service. It is written in TypeScript and requires Node.js. For Android builds you’ll also need the JDK and for iOS builds you’ll need Xcode. See the guide on Building Standalone Apps on Your CI Service for how to get and run Turtle CLI.

Custom Native Modules

A very popular request for Expo is the ability to write custom native modules. ExpoKit is a native Android and iOS library that lets you still write your app in JS and use Expo APIs while having an Android Studio or Xcode project in which you can write native code. ExpoKit has been a part of Expo for awhile through “detaching” an Expo project but many developers are unaware of it or find it hard to use. From a technical perspective, the pre-built Expo client app from the App Store cannot support custom native modules and ExpoKit or a similar approach is necessary. To address these requests and constraints, we are looking to make ExpoKit a first-class workflow in the future.

With ExpoKit as a first-class workflow, writing custom native modules and native code in general, debugging native and JS code, building binaries on your own CI services, and customizing other parts of your app will be much more streamlined. In addition, we look to make it easier to build custom Expo client apps with custom native modules so you can work on your JS the same way you would with the Expo client app from the App Store while still having your custom native modules.

We believe ExpoKit is the most sustainable solution to broad classes of items in the very long list of requested APIs. The best way for the Expo team to help professionals is to invest in ExpoKit, unblocking developers from writing custom native modules. Additionally, maintaining APIs is expensive for the Expo team, especially as costs accrue in perpetuity. For Expo to succeed, we are looking to invest more in ExpoKit than in new native modules and to create agency and a path forward for skilled professionals to write the native modules they need.