Support Universal Modules in turtle in order to enable customizable builds

Goals

1. The default exp build behavior should do the same thing it does now, provide all modules. (we might change this later.)
2. For advanced users, there should be a way to customize their build to omit unneeded or unwanted native code. I’m guessing probably a key in app.json.

• Use case 1: Thin builds. The user just wants the smallest ipa/apk possible and does not plan to use more APIs in an over-the-air update, so they know they can omit many of our native modules.
• Use case 2: Omit specific modules. The user just wants to remove one or two specific modules (for example, they don’t want the “Uses Ads” flag to show up on their Google Play listing, so they remove just the ads API. https://github.com/expo/expo/issues/1789 )

1. We should still avoid running on-demand xcodebuild whenever possible in order to save time and resources.

Prerequisites

• Our SDK needs to be (at least partially) modular. We’re shipping the first set of Universal Modules within the Expo runtime in SDK 29. So far, only a small handful of our modules have been converted to universal modules. I don’t think we need to wait for 100% universal modules before proceeding with this turtle project.
• To simplify the dependency picture, we can ship standalone apps with single-SDK support. We should do this before we introduce further complexity. Ticket here: https://github.com/expo/universe/issues/2366

Turtle details

Mostly TBD. We probably need to construct a matrix of build caches (instead of having just a single build per release) on the server. The turtle agent can check to see if it has a cached artifact for the user’s module configuration, and if not, build one. We may also need to stop running the build our CI machines and do it on the turtle machines instead? There is a (probably old, outdated) description of this here: https://github.com/expo/universe/issues/2032

On iOS, optional module dependencies are expressed with cocoapods. I think on Android they are gradle deps. So the agent will probably need to generate the correct Podfile/gradle file in order to assemble a build.

Lastly, certain parts of the native bundle configuration step will change depending on used modules. As one simple example, we only need to configure NSCameraUsageDescription for builds which use the camera. That means we might need a way for each module to express its own “configure step” in JS.

[wkozyra95]

released in sdk33

[dsokal]

I think the time has come. I’ll put my focus on adding support for customizable Turtle builds. I’d like to propose a solution for this problem that I’ve already discussed with @sjchmiela.

First of all, I need to note that things have changed since creating this issue. We have turtle-cli right now and it enables users to build their standalone apps on their own computers / CI services. This is a huge change because users don’t need to depend on our servers stability. Also, they can skip waiting in a queue, because there isn’t any queue when building with turtle-cli.

Implementing this feature is more challenging with iOS builds than with Android builds. What’s the difference? Turtle builds Android standalone apps from sources and it takes ~12 minutes to complete, whereas on iOS we have a prebuilt (on our CI) shell app and then we are only configuring some stuff, creating an archive and signing the app. An iOS build is less time consuming, the average build time is around 3 minutes, but pre-building (aka compiling the sources) shell app takes ~30 minutes. In order to add support for customizable iOS Turtle builds we’d need to skip the process of pre-building the shell app and it would cause significant increase of the app build time. If a user wanted to choose unimodules to include/exclude from the build he would need to wait at least 30 minutes + time for waiting in the queue. It means the iOS builds queue wouldn’t be empty anymore unless we add more VMs (and therefore more physical MacPro machines) and it’s expensive in terms of paying more for the infrastructure.

What’s my idea then? We have turtle-cli and we can leverage this tool for enabling users to build their customized standalone apps. A user would still have a possibility to use Expo servers for building the app, but the app would have all unimodules in it. This is better for us because we wouldn’t need to come up with any complicated infrastructural solution (aka “a matrix of build caches”). What if a user would like to build his customized standalone app on our servers after all? Well, I know that Expo is preparing for taking payments from users, so maybe we can enable customizable iOS Turtle builds in some premium plan. Thanks to that, we wouldn’t need so much more resources to handle both regular and customizable builds and waiting in the queue wouldn’t be so bad (because there wouldn’t be too much long builds). Of course, this doesn’t apply to Android builds, because we don’t have a pre-building phase there. Users would be able to build customized standalone apps on Expo servers without any charges because it doesn’t change anything too much.

What do you guys think about that? @ide @ccheever @jakubste