Is there a way to know which `expo-X` packages require a new dev-client to be build?

Our team is experimenting with the new dev-client and there are lots of exciting aspects to it.

One area that is causing some internal confusion is knowing when exactly a new dev-client is needed.

For example:

  • installing expo-location on build-v1 caused opaque “undefined x” errors. But when we created a new dev-client (build-v2), these went away and the software worked as expected.
  • installing expo-application on this same build-v2 presented no problems.
  • installing expo-cellular on this same build-v2 caused opaque undefined errors. We are doing a new build now and presumably that will fix things

So, questions:

  1. How do we know when a new dev-client is needed for any expo-x package? Is this documented somewhere? Is there a command we can run or a predictable error that gets printed?
  2. Is there a way to speed up the generation of the dev-clients? It takes about 7m for Android and 12 for iOS. If this needs to be done every time an expo-X package is added, this could add up.

In general, we recommend that every change to package.json or app.json should lead to a new build, as potential changes could have happened to the native code.

If you want to zoom in on dependencies, you could check if a dependency includes an ios and/or android folder (which is the case for the majority of them). If such a folder is present, the dependency contains native code, and the client needs to be rebuilt.

There’s no way really to speed up the generation, but we find that dependencies are mostly undergoing changes in the initial stages of development. Once you move over to the Javascript development, it won’t be a daily thing to add native dependencies usually…

Thanks for your answer. I fully understand from a technical perspective why this is needed (since it allows the EAS build system to avoid including the bazillion native code/permissions that added bloat and suspicious advertising SDKs to the old Expo Go client.)

As feedback from teams using the system such as ourselves, my engineers have been expressing a lot of frustration over needing to re-build so often and needing to redistribute development clients to all involved. (This is necessary because our credentials are stored on a secure corporate EAS/expo account that we do not want e.g. freelancers to have access to). Some ideas we have to improve things:

  • We’ll try is adding all potentially native packages up-front at the start of the development process in order to minimize rebuilds. A bit of speccing could help us out a lot here.
  • We’ll try paralleling to get multiple ones at the same time

Some questions I have for the EAS team:

  1. Is there a way you can speed up builds (in particular subsequent builds)? My (perhaps out-of-date) understanding is that running gradle (etc.) the first time is really slow on a project, but is fast on subsequent runs. But EAS Build seems to take a constant time for both. Is there a potential optimization to be made here?

  2. Can you think of a flow (maybe with Test-Flight, Google Internal Testing, some other magic), where the dev-clients can get automatically updated on our developer’s devices (and ideally simulators too) where a new dev-client version is created? That would solve most of the pain.

Re 1: I know that our team is constantly looking into ways to reduce build times, so I hope we can continue to improve on that.

Re 2: There’s an issue preventing development clients from being submitted to TestFlight at the moment (due to some internal APIs being used in a part of RN that we use), this is being investigated currently. What I’ve seen organizations do, is leverage the webhook feature of EAS to publish a download link or QR code to the build to a Slack channel for example, or anywhere convenient. You do not need to be a member of the Expo organization to be able to download these, just scan the code and the dev client installs.

One thing I’ve thought of doing is basically installing all the dependencies you expect to use up front (without referencing them in the JavaScript code yet) and building a dev client. Then you should be able to avoid building new dev clients until you find there’s another dependency you didn’t realise you’d need.

EDIT: I see you thought of this too :slight_smile:

If you have a number of similar apps you could also build one dev client with a superset of dependencies and use that for all of them.