Missing Entitlements from Build / Inconsistent Build Output

  • Management workflow
  • EAS CLI = 0.48.1

Problem Statement - identical build runs result in different output (aps-environment entitlement is present in one build, but absent from another).

Long story short - integration with the OneSignal Expo plugin is failing with a “Missing Push Entitlement” error. After ~60 builds to debug, the conclusions that I can draw are:

  • The provisioning profiles in the Apple Developer Account have been set up correctly (some builds work, so can only conclude that the configuration here is right).
  • Successive runs of eas build can yield different results (given the same input).
  • Results succeed more consistently with less of our application code included (e.g. stripping back to a boilerplate project. Results fail more consistently with more of our application code included - building the app code up from scratch, we reach a tipping point where the inconsistent build output begins (though this tipping point is not definitive).

Analysing the differences between the build outputs of successful and unsuccessful runs, we see the presence of the following entitlement deep in the bundle in successful runs, but it is absent from the failed runs. No changes to the capabilities / provisioning profiles (etc) were made in between these runs:


Further detail on this issue can be seen here:

I don’t know what’s going on, but if you’re getting builds of the exact same source code sometimes working and sometimes failing with different Xcode build logs then maybe there are inconsistencies between different build servers.

I’d try building locally, assuming you have a Mac with an up to date version of macOS and Xcode installed. Basically you just tack --local onto the eas build command. If you do that is it consistent from one build to the next?

I checked your last 2 builds and one of them was managed and the other one was bare, make sure you did not accidentally ejected (if android and ios directories exists and are not gitignored project is bare)

Thanks @wodin that’s really useful advice, and something that I can try, though it’s quite difficult to get it to fail predictably (or often enough) to determine whether I’m actually seeing consistent behaviour, or just being lucky. It might help provide a faster feedback loop on stuff though.

I definitely had very different XCode logs between the successful and failing scenarios.

Thanks @wkozyra. These most recent couple of builds were simply me trying to experiment with whether the bare workflow offered me more levers to try to diagnose the problem. All of my issues occurred with the managed workflow. I can provide two build ids for builds that behaved differently, seemingly with the same input, if that would be helpful?

Sounds like a good idea. I can’t do anything with the build IDs, but wkozyra would be able to, of course.

1 Like

Hello, I’m having the same issue with entitlements being overwritten.

Here are a couple build ids that were run, one after the other, with no changes in between, and with different results:

Entitlements maintained: 22fa9088
Entitlements overwritten: a8d2a914

When running eas build after a prebuild or ejection, I get this warning:

» ios: paths-entitlements: Found multiple *.entitlements file paths, using "ios/OneSignalNotificationServiceExtension/OneSignalNotificationServiceExtension.entitlements". Ignored paths: ["ios/PROJECT/PROJECT.entitlements"]

@tomosframework I don’t think everyone using the onesignal plugin has this issue. So, unless you’ve figured it out already, I think we could benefit by sharing our app.config and package.json files with each other and finding commonalities.

Did you get the “Found multiple *.entitlements file paths” message with both of those builds?

Also, maybe you can run something like the following in an npm hook (e.g. eas-build-pre-install):

"scripts": {
  "eas-build-pre-install": "hostname; ifconfig | awk '$1 == \"inet\" && $2 != \"\" { print $2 }'"

(If you get problems with quoting you could put that in a shell script in your repository and run the script from the npm hook.)

That should give you the hostname and IP address of the build server. Maybe you can find a pattern.

I normally work on a PC, and that warning only happens when I prebuild or eject on a mac. So far I haven’t run a lot of builds from the mac (since its not mine), so I don’t know if the “working” builds would’ve had that warning or not, but its something I can try tomorrow.

Thanks for the npm hook idea! I’ll give it a go.

EDIT: I should include that this github issue The file "[...].entitlements" could not be opened · Issue #793 · expo/eas-cli · GitHub seems relevant, but it seems to have been resolved. I am on the most recent version of eas-cli. Although I haven’t tried a local build yet using eas.

Also, another difference in the XCode logs, besides the listed entitlements, is the presence of this line:


in “working” builds, but not in others.

hmmm… so then it seems to me that in the non-working case Xcode picks up two directories containing entitlements and chooses the “wrong” one.

Kind of. The “multiple entitlements files” warning would make it seem that that’s what is happening. But after the build, the OneSignalNotificationServiceExtension target has the correct entitlements, while the Project target has the overwritten default entitlements.

I tried renaming the app, which reordered the targets alphabetically. After that, the warning says its using the Project entitlements and ignoring the OneSignalNotificationServiceExtension entitlements (opposite as before). But there’s no change in the resulting build. The OneSignal entitlements end up correct, and the Project entitlements are overwritten.

1 Like

@jrconsole - really sorry to be slow - it’s been difficult to find the time to repro this consistently and systematically. I’m happy to look for commonalities, if it would be mutually beneficial for our diagnoses.

@wodin @wkozyra - there’s extra info on this issue in my most recent comment on the related issue in the OneSignal Expo plugin repo. I hope this is useful. I’m happy to provide more information as needed.

Also, FWIW, I see the following warning in the logs:

» ios: paths-entitlements: Found multiple *.entitlements file paths, using "ios/[project]/[project].entitlements". Ignored paths: ["ios/OneSignalNotificationServiceExtension/OneSignalNotificationServiceExtension.entitlements"]

…though, I get this in both the working and non-working scenarios (using eas build:inspect).

I have build ids and Xcode logs for all of the above - let me know how I can share these with you.

I believe it should be safe to add those to your comment on the issue, or here. Only Expo team members and you will be able to access them.

Hi - just following up on this, having there been some activity on the following issue:

I ran three identical tests (all steps below executed each time), and ended up with different results.

  • Install onesignal-expo-plugin (1.0.1)
  • Run expo prebuild --clean
  • Run eas build --profile preview --platform ios --clear-cache
  1. Build 3795ed84-d092-4e42-b603-c9996822c5a8 - build succeeded, capabilities set up correctly.
  2. Build 03b4d622-4499-46ff-ae7b-d1845725d54f - build succeeded, capabilities set up correctly.
  3. Build 9fe7d7aa-76f3-4cd6-beee-dc411d634c2f - build succeeded, “Missing Push Capability” reported in OneSignal.

Note that the following warning was received in all cases:

ios: paths-entitlements: Found multiple *.entitlements file paths, using "ios/[project]/[project].entitlements". Ignored paths: ["ios/OneSignalNotificationServiceExtension/OneSignalNotificationServiceExtension.entitlements"]

If you’re able to glean any more information from the build ids, then that would be really welcome.

@wodin @wkozyra

Since I’m not an Expo Team member I can’t check your build IDs, but hopefully @wkozyra will be able to find something.

We are working on support for different entitlements per target. Currently, the only reliable way is to:

  • eject/prebuild (and commit android and ios directory in the repo)
  • after prebuild you might need to fix manually the content of your entitlements files
  • use credentials.json or managed credentials with EXPO_NO_CAPABILITY_SYNC

The issue comes from the fact that the wrong file can be picked when:

  • prebuild is run on eas builder
  • eas-cli is updating your apple developer settings

Missing Push Capability

This error means that value is missing in apple developer portal, workaround could be here that if you add push notification entitlement to the application and extension (and regenerate profiles) it should work even if wrong entitlements file is picked

Hi @wkozyra . Thanks for the quick reply. I must admit that I’m not wholly convinced that the problem is that the wrong entitlements file is being chosen. Reason being:

  • For both builds that work, and builds that do not work, the extension’s entitlements file is being reported as ignored. If this isn’t the case (and the choice of entitlement file is truly random), then there’s a bug in the warning message.
  • Even when the capabilities are set up correctly in both entitlements files the issue still occurs (randomly).

I’m also not sure that the capabilities are being incorrectly sync’d either, as they look correct / identical before and after a working build and before and after a non-working build.

That being said, I’ve done some more testing, as follows:

  1. Checked that the capabilities are all set up correctly in the Developer Portal.
  2. Regenerated and downloaded the provisioning profiles to use as local credentials.
  3. Run a prebuild before the eas build and checked the capabilities exist as expected in both the main entitlements file and the extension’s entitlements file.
  4. Run an eas build with EXPO_NO_CAPABILITY_SYNC=1.

I have tried this three times and still get random results - 2 working builds and 1 non-working build.

9e6e59ae-8594-484b-80f2-3f29751eead2 - not working
06c611ee-bc05-4e4a-915a-0f71a4623cc4 - working
2cea1474-2d04-425b-b310-a2c5c16e178d - working

I’ve run out of options on this thread, so any further options you can provide would be really welcome.

9e6e59ae-8594-484b-80f2-3f29751eead2 - not working

what do you mean by not working, I see that build succeeded, so it is not the missing capabilities problem.

I’m also not sure that the capabilities are being incorrectly sync’d either

If you are using credentials.json then yes this is not the issue (EXPO_NO_CAPABILITY_SYNC is not necessary).

I’ve run out of options on this thread, so any further options you can provide would be really welcome.

I recommend waiting for support in manged workflow and in the meantime just using it as ejected. After you get the next successful build, do not run prebuild anymore, if results are still random after that then the issue is not related to eas.

The build always succeeds - my problem is that sometimes OneSignal reports “Missing Push Capability”, as you say, suggestive of a problem in the entitlements / capabilities that are built into the app.

Thanks for the clarity on EXPO_NO_CAPABILITY_SYNC.

I recommend waiting for support in manged workflow and in the meantime just using it as ejected.

The OneSignal plugin can work in the managed workflow, I believe, though this doesn’t work for me either.

After you get the next successful build, do not run prebuild anymore

OK - I’m happy to try running several iterations of eas build after a successful prebuild + build, to see if that has a higher success rate.

I really appreciate the help in trying to isolate the problem - this is critical, though the problem must surely reside in either EAS or in the OneSignal extension, and neither is claiming responsibility at the moment. I find it worrying that, with the exact same inputs (source code, configuration, Developer Portal configuration, EAS build parameters etc etc) the process yields different outputs. This surely warrants further investigation?