Default buildType for internal distribution on Android makes no sense

The documentation specifically mentions that when you choose internal distribution on Android, you need to make sure the build produces an APK.

For me, that leads to the point of ‘sane defaults’: if you pick ‘internal’, then there is not a single scenario in which ‘app-bundle’ is a sane default for buildType if not specified.

1 Like

For me, that leads to the point of ‘sane defaults’:

I would argue that we already have sane defaults, (distribution: store, gradleCommand: bundleRelease), you are suggesting that default of one field should depend on value for other field, which is not that simple

  • it’s harder to document because there is no one default value
  • it’s not that obvious, maybe it would be better if default distribution was internal when buildType is apk
  • supporting sth like that for specific options is ok, but if we would want to generate sane defaults for any supported config it would become quickly unmaintainable

if you pick ‘internal’, then there is not a single scenario in which ‘app-bundle’ is a sane default for buildType if not specified.

There are, example scenario: Developer want’s to make sure that app uploaded to store is the same as the one used during testing, so they always build app bundles and for testing purposes they use apk generated from that app-bundle

I don’t agree with this approach in general but in this specific case we might want to change those defaults based on distribution. We’ll need to discuss it more internally.

2 Likes

Generating an apk from a signed aab locally with bundletool, that would also require having the keystore locally (and the bundletool), which would make you download the credentials from EAS first (in a team) before doing that, so that’s a bit of a far fetched scenario in my opinion.

  • it’s harder to document because there is no one default value
  • it’s not that obvious, maybe it would be better if default distribution was internal when buildType is apk

Those are valid points. Maybe you could leave your defaults in place, but add some kind of validation step, saying ‘internal distribution is not compatible with default buildType app-bundle’ or if you specify buildType, but not distribution, it should also warn you that buildType apk is incompatible with the default buildType (store). There’s many tools (including for example git) that warn you when you provide it with incompatible options, and the docs can stay simple with a single set of (compatible) defaults.

I really don’t think there are that many options that are actually this dependent on each other, so that would also be an argument for simple validation versus multiple sets of defaults.

In general, all I’m offering you is a fresh perspective. I’m going through this process as an experienced RN developer, that does a lot of build and deployment management (and automation), and who tries to apply EAS tooling to that process for the first time. So if I run into something that seems counter-intuitive to me, then I’m bringing it up for discussion.

I appreciate your feedback.

2 Likes