Dynamically toggle capabilities before build

[EvanBacon]

Checklist

• I've added an entry to CHANGELOG.md if necessary.

Why

If a capability is defined in the entitlements file but not registered with Apple, the build will fail. This PR aims to reduce the possibility of that happening by checking the native entitlements file and enabling/disabling capabilities.

Fixes expo/expo-cli#3448 for eas build

How

• If the project is specified to run as a bare workflow build, then read the entitlements file directly if one exists.
  • Otherwise if it's a managed project, read the Expo config and use the ios.entitlements object, defaulting to the template object (which always enables push notifications). This needs to be improved further in expo/config to allow reading of evaluated entitlements automatically (can implement in another PR).
• Given a JSON representation of an entitlements object, match against our supported capabilities. Supported capabilities are based on entitlements, and iOS platform support.
• If a capability that we manage is enabled for app, but not defined in the entitlements file, we'll disable it. This allows for users to enable future capabilities without us needing to explicitly support them.
• Basic capabilities (boolean) can be omitted from the request if they already exist on a bundle identifier, this helps to reduce the amount of invocations in simpler projects. If a capability has settings, we'll always update it to ensure the settings are in sync. This can be optimized further in the future but works for now.
• Using debug mode will show more info on how the request is built.
• We surface the user friendly names for enabled and disabled capabilities after syncing.

Example

If the user has associatedDomains defined in their entitlements file, then in their app.json then enable/disable the capability remotely before building. Without this feature the build fails.

❌  error: Provisioning profile "*[expo] com.bacon.yolo22 AppStore 2021-05-04T22:29:48.816Z" doesn't support the Associated Domains capability. (in target 'yolo22' from project 'yolo22')

❌  error: Provisioning profile "*[expo] com.bacon.yolo22 AppStore 2021-05-04T22:29:48.816Z" doesn't include the com.apple.developer.associated-domains entitlement. (in target 'yolo22' from project 'yolo22')

With this feature the build works.

Test Plan

• Wrote unit tests for the request and assembly.

• In a managed project's app.json:

{
  "ios": {
    "entitlements": {
      "com.apple.developer.associated-domains": [
        "applinks:evanbacon.dev",
        "webcredentials:evanbacon.dev"
      ]
    }
  }
}

• Then run eas build -p ios, after capabilities sync, check to see if 889YZVZQDS_ASSOCIATED_DOMAINS is defined (my app's opaque id is 889YZVZQDS).
• After the build completes, submit to the app store, it should finish processing without any warnings.
• Then remove the entitlements and rerun eas build, the syncing step should remove the capability.

This feature doesn't currently support ios.usesAppleSignIn, ios.associatedDomains, etc. because the mods must be statically evaluated for this to work. We can add this functionality in a future PR.

Visually, this is the scope of automatic functionality:

[github-actions]

Size Change: +4.21 kB (0%)

Total Size: 33 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	33 MB	+4.21 kB (0%)

_{compressed-size-action}

[brentvatne]

this looks good to me. one concern i have about continuing to go down this road is that it's not clear how a third party lib using a config plugin to add a feature that depends on a capability would be able to work w/o modifying eas-cli like this. maybe we could add a more generic ios.capabilities key in the future? correction - we already have ios.entitlements

[brentvatne]

i spoke with @EvanBacon about this stuff today and i'm generally on board with changes. there's additional work being on on the expo-cli repo but this can ship independently.

[dsokal]

It generally looks good but please address my comments before merging to make the code easier to follow.

[quinlanj]

lgtm, but please get wojtek/dominik to approve this first before merging !

[flow-danny]

Is this supposed to work with app.config.ts? The sync basically disabled all our capabilities...

[flow-danny]

Now I see EAS "workflow": "managed" still might behave as bare workflow in this case.

[brentvatne]

@flow-danny - sorry can you elaborate on what you experienced? i'd like to understand what happened in your situation

[flow-danny]

We have a regular managed Expo app and tried EAS for the first time. We didn't have any custom entitlements configured, just `usesIcloudStorage` set to true as documented here https://docs.expo.io/versions/latest/sdk/document-picker/ (But in the typescript version if app.json) iCloud entitlements get disabled during the syncing process until after we added these to the entitlements config. I used expo eject and Xcode to figure out the entitlement keys that we needed.

…

On 24 May 2021, 06:54 +0400, Brent Vatne ***@***.***>, wrote: @flow-danny - sorry can you elaborate on what you experienced? i'd like to understand what happened in your situation —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[brentvatne]

if anyone runs into issues with capability syncing, you can disable it with EXPO_NO_CAPABILITY_SYNC=1 eas build (as described here: https://docs.expo.dev/build-reference/ios-capabilities/) and post an issue with some more information