Missing Push Capability on iOS - EAS Built App

[tomosdevans]

Problem Statement - Our iOS integration with OneSignal is not functional due to a Missing Push Capability error in OneSignal.

Environment Details

• Expo SDK 44
• EAS managed workflow build

Steps Taken to Resolve / Root Cause Analysis

1. iOS setup has been completed as per the discussion in https://github.com/OneSignal/onesignal-expo-plugin/discussions -
2. Ensured the provisioning profiles created as part of the above were regenerated / up-to-date (even tried recreating them, inc. distribution cert).
3. Experimented with all plugin props (mode, devTeam, iPhoneDeploymentTarget).
4. Experimented with EXPO_NO_CAPABILITY_SYNC as per https://docs.expo.dev/build-reference/ios-capabilities/
5. Experimented with adding the aps-environment entitlement as per https://docs.expo.dev/versions/v44.0.0/config/app/#entitlements

None of these yielded a positive result.

In combination with the above, I also experimented with stripping the app right back to a boilerplate Expo app and gradually building the functionality of our app back up from scratch. Certain configurations of the source code would work through this process, but results were inconsistent:

• The totally stripped back app succeeded reliably.
• Our full app failed reliably.
• Intermediate states were inconsistent - successive builds (of the exact same source configuration) would yield different results; some would fail, some would succeed.

Looking at the Xcode logs for source configurations that had inconsistent results, the logs are quite different. A key difference I observed in the logs is that a working run would include in the aps-environment in the entitlements (see below). This feels significant to the presence or absence of the "Missing Push Capability" error, but I'm unable to determine what causes it to be present or not, and why different eas build runs (with identical input and parameters) would have different results.

{
    "application-identifier" = "XYZ";
    "aps-environment" = production;
    "com.apple.developer.team-identifier" = ABC;
    "com.apple.security.application-groups" = (
        "DEF"
    );

[rgomezp]

Howdy,
Are you using Expo managed credentials or local?

[tomosdevans]

Hey @rgomezp - I'm using local credentials. I followed the instructions outlined in https://github.com/OneSignal/onesignal-expo-plugin/discussions. Note: that this does work for me with a boilerplate Expo project, but begins to fail (inconsistently) the more of our application-specific code is layered on top.

[rgomezp]

@tomosdevans ,
We've wrote up an even more detailed guide here. Can you please give it a read and let us know if you're still having issues or have anything to add.

[JustinRohweller]

Hey guys,
Wanted to say I'm experiencing a similar/same issue.
I followed the guide here: https://github.com/OneSignal/onesignal-expo-plugin/discussions/63#discussioncomment-2418630

Also just had a look at this guide, I did do those exact steps yesterday:
https://github.com/OneSignal/onesignal-expo-plugin/blob/main/IOS_CREDENTIALS_EAS.md

On my first correct configuration, the build went through, and correctly had entitlements.
I also had a successful push notification to said build.

All builds after that have succeeded, but without the correct entitlements. Unable to send, have "Missing Push Capability" in Onesignal Dashboard.

I have the xcode logs handy and will put the main difference that I'm seeing.
A comparison shows that several entitlements are missing.

Successful one:

Entitlements:
    
    {
    "application-identifier" = "secrets";
    "aps-environment" = production;
    "beta-reports-active" = 1;
    "com.apple.developer.applesignin" =     (
        Default
    );
    "com.apple.developer.in-app-payments" =     (
        "secrets"
    );
    "com.apple.developer.team-identifier" = secrets;
    "com.apple.security.application-groups" =     (
        "secrets"
    );
    "get-task-allow" = 0;
}

Failed one(s):

Entitlements:
    
    {
    "application-identifier" = "secrets";
    "beta-reports-active" = 1;
    "com.apple.developer.team-identifier" = secrets;
    "get-task-allow" = 0;
    "keychain-access-groups" =     (
        "secrets"
    );
}

So, not only is aps-environment missing but so is the rest of my added entitlements from things like apple-sign-in or stripe-react-native.
These are missing:

"aps-environment" = production;    
    "com.apple.developer.applesignin"
    "com.apple.developer.in-app-payments" 
    "com.apple.security.application-groups" 

Unrelated: having autoIncrement with EAS appears to cause a version mismatch between Onesignals Extension and the app.
So I'm no longer using autoIncrement.

Current (poor) guesses I got are that within node_modules/onesignal-expo-plugin/onesignal/withOneSignalIos.ts, withEntitlementsPlist passed function maybe is supposed to be async.
Or maybe it has something to do with this line:

if (!config.ios) {
        config.ios = {};
      }

within withEntitlementsPlist inside node_modules/@expo/config-plugins/build/plugins/ios-plugins.js

Really not sure.
Hopefully this info helps get it resolved.

[tomosdevans]

@JustinRohweller - this is really insightful - thanks. This describes the issue that I'm seeing extremely well. I have followed the steps of the setup guide(s) exactly and have been able to get the integration to work. However, it only functions when I remove large chunks of our application code; with our full / current codebase, it fails 100% of the time. As I remove more and more chunks of our application code, I can reach a "tipping point" where it works again.

The symptom is exactly as you describe: "Missing Push Capability" in the OneSignal dashboard.

Other key observations:

• Successful builds have the aps-environment entitlement present in the logs and build artifact; in the failure case this is missing.
• I am using EAS build, with a managed workflow.
• EAS server and local builds behave the same.
• Early indications suggest that if I expo eject then, so far, the integration has worked 100% of the time (over a small number of builds).

[tomosdevans]

@tomosdevans , We've wrote up an even more detailed guide here. Can you please give it a read and let us know if you're still having issues or have anything to add.

Hi @rgomezp - I've read through the guide - it looks really comprehensive and helpful - thanks so much for taking the time to prepare that. It doesn't solve my problem unfortunately though, see #67 (comment).

Let me know if you need any more info; would really love to crack this!

[JustinRohweller]

@tomosdevans Thanks for the kind words, and for making the issue.
I can't troubleshoot it more at the moment but wanted to say I just had a build I believe was successful, by deleting ios/android folders, running

expo prebuild --clean

And then running

eas build --profile=testing --platform=ios --non-interactive

Probably want profile to be something else for you but there's a possibility this is the solution.

[JustinRohweller]

Specifically I think that the --non-interactive flag is good.
Like maybe saying "no" to EAS for push notifications is where it messes with the entitlements.
Will test more tomorrow.
Thanks

[tomosdevans]

Thanks for the speedy response @JustinRohweller. And, just to clarify that, when I say "failed build", I mean that the build succeeded, but that the entitlement was missing and therefore prevented successful integration with OneSignal.

I don't know how useful the next comments will be, but:

• I haven't tried running prebuild --clean but have tried a clean ejection, with I think is broadly similar (in this context). The EAS build was then successful, and integrated with OneSignal, but obviously leaves me with a bare workflow rather than a managed workflow, which has a bunch of trade-offs.
• Our CI build uses --non-interactive so this flag has been present for many of the failed builds (except where I've been trying to diagnose by running from a development machine). So, I'm not sure that the --non-interactive flag on its own will solve matters.

Thanks again for the help - genuinely appreciated.

[rgomezp]

For local builds the plugin config code is triggered via expo run or expo prebuild. It seems likely that the same is true for cloud builds. If you are not seeing the aps-environment entitlement, maybe tried prebuilding locally first. I was unsure how the cloud build process works when it comes to plugin use but given the observed behavior by y'all, I suspect prebuilding is a requirement.

Btw expo prebuild --clean deletes the android and ios dirs for you and rebuilds them.

[tomosdevans]

Thanks @rgomezp - that's helpful to know. We're using the EAS build service, which does a prebuild as one of its steps. Also, in this case, I guess the --clean flag would be redundant, as there are no /android or /ios folders in my solution.

Given that the cloud build does the prebuild, what benefit would there be to running that locally first?

[rgomezp]

Honestly, I'm not sure. I would expect it to work since EAS is prebuilding as well but given the behavior y'all described, the prebuild step in cloud build might not be running the plugin config code (either by design or upstream bug). This is uncharted territory so we may need to just try it and find out.

But my comment above is only a hypothesis based on the behavior you're describing.

[tomosdevans]

OK - understood. This is an obscure issue, so appreciate that there's some experimentation involved.

FWIW - I think the prebuild step is running the plugin config code in my project, as I can get it to work, but only if I rip out big chunks of the project's codebase.

Can you help me understand the specific instructions that you think would be worthwhile trying?

1. Running expo prebuild on my local machine, and then running eas build on the same machine to see what the result is?
2. Running expo prebuild on my local machine, committing the result and then running the CI / server build?
3. Something else?

[JustinRohweller]

My understanding is that after the prebuild + build you can just delete android/ios folders and run it as if it was still managed.

It does seem like the local prebuild acts differently than the EAS cloud one.
Worth noting that if you run prebuild and then EAS build it does not run prebuild in the cloud. IE. if you run it locally first, the cloud build notices and doesn't run it again.

[tomosdevans]

Thanks @JustinRohweller. Again, in case it's useful, both the local and server builds are producing builds with the missing push capability, so if there is a difference in behaviour between local prebuild and cloud prebuild then I don't know that it is significant in this instance.

I guess I'm still not quite sure what the guidance is here, as it relates to the prebuild, and what changes I should consider making to my setup.

Feels like there are two possibilities here:

• Successful and unsuccessful builds produce different prebuilds.
• Something is going wrong in the XCode build.

I'm inclined to think it's the latter, given that ejecting out to the bare workflow seems to solve the problem. I can diff the outputs, but I don't know if there's something specific I should be looking for?

Any suggestions on where to go next with this would be really welcome!

[JustinRohweller]

Ok, so I just saw your other comment. I think it'd make sense to try exact same as I did and see if it works for you. Sounds like 1) from your other comment

[tomosdevans]

Thanks so much for the support @JustinRohweller. So, if I've understood correctly, the suggestions is that I do...

1. eas prebuild --clean
2. eas build [etc]

And then see if that yields a different result.

Hope I've understood that correctly, and I'll report back with the result.

[JustinRohweller]

Yes, exactly. I'll be trying it more tomorrow as well.

[rikoriswandha]

I was having the same problem yesterday but so far I managed to make it works (3 consecutive builds)

What I did was making sure the "Push Notification" capabilities on my Apple Developer Account -> Identifiers -> Main App isn't configured (doesn't automatically linked to Apple Push Notification Certificate. I think expo automatically link it for me). After that I recreate Provisioning Profile for the Main App and replace the old one.

[russriser]

I don't have a solution, but just want to say that this is a duplicate of #64

I've reverted to old commits and found, similar to tomosdevans, that old builds work, new builds don't, and in between is inconsistent.

I was able to run a build 3 times in a row and get a different result on the 3rd try with no changes.

[JustinRohweller]

So, just an update on my end:
For me if I run expo prebuild --clean WITHOUT deleting the ios/android folders first, build fails to store the entitlements correctly.

However, I have had a 100% successful entitlements build rate every time I have done:

1. delete ios/android folders
2. commit
3. expo prebuild --clean
4. commit
5. eas build --profile=testing --platform=ios --non-interactive

Might just be my setup is different, but wanted to just put it out there that it's been working consistently for me now.
I have expo-image-picker, @stripe/stripe-react-native, onesignal-expo-plugin, and sentry-expo as plugins.
And my eas.json piece is:

"testing": {
      "android": {
        "autoIncrement": "versionCode"
      },
      "ios": {
        "credentialsSource": "local"
      },
      "releaseChannel": "testing"
    }

Hopefully this helps someone.
Thanks

[tomosdevans]

Hey @JustinRohweller - this is super helpful. I wanted to reply once I had a few more test runs under my belt, but I wanted to confirm that if I do this:

1. Delete android and ios folders.
2. Run expo prebuild --clean.
3. Run eas build --platform ios --profile testing --clear-cache.

Then it works successfully for me. Note, I didn't need the --non-interactive-flag.

In case it's useful too, I've removed all plugins except onesignal-expo-plugin.

So far, I have only tested once, but will look to try a couple more runs. Thanks again for sharing your useful info.

[russriser]

Unfortunately, prebuild did not solve the problem for me.

I found this github issue: expo/eas-cli#793

And I made this post in the expo forums to get extra opinions: https://forums.expo.dev/t/ios-entitlements-overwritten/62670

[tomosdevans]

Thanks so much for the support @JustinRohweller. So, if I've understood correctly, the suggestions is that I do...

1. eas prebuild --clean
2. eas build [etc]

And then see if that yields a different result.

Hope I've understood that correctly, and I'll report back with the result.

@JustinRohweller @russriser - having tried this a few more times, it doesn't actually work for me, unfortunately. I'm getting the same error. I'm assuming any successes have just been good fortune.

If there's any advice on other things to try then I'd be really appreciative.

[russriser]

@tomosdevans I think ejecting might solve the problem. I learned awhile ago that the bare workflow is built to handle multiple targets, while the managed is not yet.

I'll try ejecting once I have access to a mac later, but you may want to give it a try.

Here's my old forum post where an Expo dev explained the situation: https://forums.expo.dev/t/automatic-signing-disbled-in-ios-builds/61930

[russriser]

Ejection didn't seem to work for me.

@tomosdevans I noticed you made a post a couple days ago where you seemed to say the issue was only with the managed workflow. Were you able to get things to work consistently with the bare workflow?

[tomosdevans]

@tomosdevans I think ejecting might solve the problem. I learned awhile ago that the bare workflow is built to handle multiple targets, while the managed is not yet.

I'll try ejecting once I have access to a mac later, but you may want to give it a try.

Here's my old forum post where an Expo dev explained the situation: https://forums.expo.dev/t/automatic-signing-disbled-in-ios-builds/61930

Hey @russriser . So sorry for the slow reply. I briefly tried ejecting, but ran into some (unrelated) difficulties with it, and decided to abandon that path as it wasn't really where I wanted to end up.

Thanks for sharing the forum post - I think this helps explain the need to manage signing credentials locally, and why the eas credentials can't automatically cater for the credentials of the extension, but I can't quite link it to the issue of entitlements going missing in the process - if this is something that you've been able to grasp, I'd love to learn more.

[tomosdevans]

@rgomezp - yes, I'm sorry it's a disappointment. The hard work that you've put into creating the guide however has been super useful for understanding the moving parts at play here, so I'm really thankful for that.

Technically, you mean the build was successful but you see the error in the OneSignal dashboard, correct?

Yes, the build succeeded, the app runs, but I get "Missing Push Capability" in OneSignal.

And you are sure you are using the latest SDK version?

I'm 100% certain. I used 1.0.1:

"onesignal-expo-plugin": "1.0.1",

And did you check them after? Perhaps EAS is still changing them and the issue is with the capability sync.

I'm not sure exactly what to check, but the capabilities appear to still be in place in the Developer Portal, both for the identifiers, and the provisioning profiles (main + extension). The entitlements files appear correct too.

Thanks again for all the efforts - much appreciated.

[wkozyra95]

The last few builds that @tomosdevans did were all

• bare workflow
• using credentials.json
• the entitlements files appear correct too.

If we assume that this is true, then I don't see how eas could cause the issue, because in a flow like that we do not touch anything about the project, just taking credentials as they are and running Fastlane build, without any capability sync with apple.

The other possibility is that some of those claims are not exactly true, I confirmed that 3 builds linked on the expo forum were all bare projects, I don't have any reason to believe that using local credentials is incorrect, so the only last statement might be wrong.

So to sum up, it's either issue with the plugin, or claim that "the entitlements files appear correct too." is not correct. To verify which is it, the simplest way is to stop running expo prebuild` after getting a successful build, after that builds should not be random, and if they are then it's not eas build issue.

I don't want to spend too much time on finding a workaround and just focus on proper support for target-specific entitlements. Even if entitlements is not the issue, you should have at least a reproducible way of verifying what is not working

[tomosdevans]

@wkozyra95 - thanks again for the guidance on how to home in on where the problem might be - really useful. Totally agree that we need to find a consistent way of reproducing failure - this is the outcome that I have been unable to achieve, despite having run 200 (?) builds in the process. I would welcome more support here.

To follow up on the assumptions you outlined:

• bare workflow - yep, thanks for confirming
• using credentials.json - yes, I'm 100% confident that these are working correctly as they are identical in the working and non-working scenario
• the entitlements files appear correct too - I don't know these intimately, but can confirm that the entitlement files are identical in working and non-working scenarios too.

To pursue your suggestion...

I continued to follow the process of prebuild > build until I hit upon a working state (no "Missing Push Capability" reported from OneSignal). I then repeated the build step only, leaving the result of the prebuild intact (per the suggestion). I was then able to produce 7 subsequent working builds. I'm not planning on running any more, but I'm pretty confident that this repetition would continue.

So, I think you're correct in your suspicion that the randomness is introduced by the expo prebuild step. I'm afraid I'm not clear on whether this is a problem with the expo prebuild process, or one of the processes it kicks off amongst the dependencies, or if the answer is simply to complete the target-specific entitlements fix, though I hope that allows you to make a more informed judgement.

My preference would be to avoid deviating from the managed workflow, but this isn't a red line.

@rgomezp - I hope this is useful. Please do let me know if there's more support I can provide. Obviously, I'm keen to crack this problem, but I'm not sure what course of action to take next or what confidence to hold for a quick resolution. If you could help me on these then I'd be really grateful.

[rgomezp]

@tomosdevans ,
Have you ran a git diff on the entire project between the working and non-working versions? Maybe something else is changing.

If you continue seeing the issue, please reach out to our support channel on OneSignal.com so we can set up a call and see if we can fix this together.

[rgomezp]

@tomosdevans ,
Just wanted to highlight wkozyra95's PR

[tomosdevans]

@tomosdevans , Have you ran a git diff on the entire project between the working and non-working versions? Maybe something else is changing.

If you continue seeing the issue, please reach out to our support channel on OneSignal.com so we can set up a call and see if we can fix this together.

Hey @rgomezp - thanks for being attentive on this. To answer your question around git diff - when I run my tests, I'm essentially doing so on the same checkout, just reverting any changes, and deleting the ios folder in between test runs. The resulting state of the tracked files of the project appears to be identical in the working and non-working scenarios. My suspicion is that the prebuild step is potentially generating different stuff in the ios folder in the working and non-working scenario(s), but I've not been able to identify any illegitimate differences amongst the legitimate differences. I alluded this this in one of the posts from a while back:

#67 (comment)

I'm happy to dig into this if it would be helpful.

[tomosdevans]

@tomosdevans , Just wanted to highlight wkozyra95's PR

This looks like a really positive development. It sounds like the confidence will be higher when the CLIs are rolled out and the EAS servers updated. I'm more than happy to get stuck in to help with the testing, if that would be useful - just let me know what I can do.

[rgomezp]

@tomosdevans ,
Regarding the git diff, I recommend do the following:

1. Create a temp branch
2. Remove ios from .gitignore (track)
3. Run a git diff in working and non-working scenarios on the native changes

Yes! That would be great. I left a comment that you should be able to copy into your package.json for testing.

[tomosdevans]

Hi @rgomezp. Thanks for the extra pointer. In the interests of time, would it make more sense for me to do some testing on @wkozyra95's fix, rather than pursue the git diff?

[rgomezp]

@tomosdevans ,
1.0.2 has been released with the mentioned changes.

Please upvote this comment if 1.0.2 worked for you.

[russriser]

@wkozyra95 @rgomezp @tomosdevans

SUCCESS!

You're all rockstars and I love you.

[tomosdevans]

@rgomezp @wkozyra95 - just to let you know that I have run 6 successful builds on my test project using 1.0.2 and EAS 0.52.0, using remote credentials. All of them have been successful i.e. haven't reported the "Missing Push Capability" error. For now, this is sufficient confidence for me to believe that this will work when I apply it to our main project.

This is amazing news, and testament to your hard work and tenacity. Thank you 👏👏

In case it's useful (or is reported by others), I had a few missteps in getting to this point whereby the eas build (in interactive mode) wasn't seemingly generating the provisioning profiles - this was resulting in failed EAS builds. I had to run eas credentials and rebuild the credentials fully in order to get everything to work. Hopefully, anybody picking up the latest configuration from scratch shouldn't be affected by this, I guess.

Thanks again - truly appreciated.

[NashAtFramework]

I don't think this issue needs to be reopened but one thing I've discovered is that it appears that the content / order of plugins seems to have an effect on the capability being added.

"plugins": [
      "sentry-expo",
      [
        "expo-image-picker",
        {
          "photosPermission": "This lets you share photos from your library with other Framework members"
        }
      ],
      "@react-native-firebase/app",
      "@react-native-firebase/perf",
     [
        "onesignal-expo-plugin",
        {
          "mode": "development",
          "devTeam": "XXXXXX"
        }
      ]
    ],

didn't add the capability - Where as swapping this around to be the first plugin (below) seems to consistently add the push notification permission into the xcworkspace file

   "plugins": [
      [
        "onesignal-expo-plugin",
        {
          "mode": "development",
          "devTeam": "XXXXXX"
        }
      ],
      "sentry-expo",
      [
        "expo-image-picker",
        {
          "photosPermission": "This lets you share photos from your library with other Framework members"
        }
      ],
      "@react-native-firebase/app",
      "@react-native-firebase/perf"
    ],

Can anyone else confirm this behaviour?

[jurica-penjgusic]

For me, it worked for new projects, for existing one and internal distribution is always Missing Push Capability.
@tomosdevans How did you manage to setup all new credentials?
I have tried like eas credentials, but no luck.

[tomosdevans]

Hey @jurica-penjgusic. For full disclosure, @NashAtFramework and I are team-mates! We needed to run eas credentials from the local machine explicitly in order to build up the required credentials. We then ran into the "Missing Push Capability" error again, but after much diagnosis, noticed that it was caused by the ordering of the plugins in the app.json.

This is an existing project, with an internal distribution. We haven't yet completed the production / store distribution, so I can't comment yet on how successful that was.

[jurica-penjgusic]

I can confirm that moving expo plugin to first place in array adds wanted entitements.
Thank you @tomosdevans and @NashAtFramework

[jurica-penjgusic]

I don't think this issue needs to be reopened but one thing I've discovered is that it appears that the content / order of plugins seems to have an effect on the capability being added.

"plugins": [
      "sentry-expo",
      [
        "expo-image-picker",
        {
          "photosPermission": "This lets you share photos from your library with other Framework members"
        }
      ],
      "@react-native-firebase/app",
      "@react-native-firebase/perf",
     [
        "onesignal-expo-plugin",
        {
          "mode": "development",
          "devTeam": "XXXXXX"
        }
      ]
    ],

didn't add the capability - Where as swapping this around to be the first plugin (below) seems to consistently add the push notification permission into the xcworkspace file

   "plugins": [
      [
        "onesignal-expo-plugin",
        {
          "mode": "development",
          "devTeam": "XXXXXX"
        }
      ],
      "sentry-expo",
      [
        "expo-image-picker",
        {
          "photosPermission": "This lets you share photos from your library with other Framework members"
        }
      ],
      "@react-native-firebase/app",
      "@react-native-firebase/perf"
    ],

Can anyone else confirm this behaviour?

This should be documented, because it's really hard to find out right solution.

[izakfilmalter]

Ya this sent me for a loop for several hours. Please update the readme with this info for future devs.

[AdamDiament]

Hi @rgomezp I don't know if it's just something I am doing wrong but I think I still have this issue: with v 1.0.2

If I build and run locally with eas run:ios --device, then I can receive push notifications on that build
However if I build on eas with eas build --platform ios, and upload that build to testflight, with the exact same code - on the one signal portal in the users tab I see the message "missing push capability" next to the user.

• Managed workflow
• Plugin v 1.0.2
• Plugins in app.json ordered correctly with one-signal first
• Expo v46
• EAS managed credentials

If I go in to my certificates and identifiers on my apple developer portal, I see that the main app identifier has push capability, but the one-signal notification service extension identifier does not. The app groups section looks correct though. Is this expected, or is this the problem? I tried manually checking the push capability checkbox, but then obviously that invalidates the prov. profiles. Then rebuilding on eas regenerates the profiles, and unchecks the box on the service notification identifier. Feeling stuck! Thanks for any help you can give.

[gyl89]

I can confirm that placing the plugin in first position solves the issue for me

[parniekovvakoms]

guide here

page not found

[bayramn]

@tomosdevans , We've wrote up an even more detailed guide here. Can you please give it a read and let us know if you're still having issues or have anything to add.

@tomosdevans the link is not working, but thanks, it lead me for to read your docs and I found it this one here. It was very helpful and I resolved the issues in Expo Managed FLow.

It was from app.json plugins that was messing with Notifications aps-environment plugins of onesignal library. According to onesignal-expo-plugin docs, if you have extra plugins that modify capabilities in your app.json on top of Notifications capabilities, then expo randomly selects one capability and doesn't setup the Notifications capability.

In my case I had a expo-screen-orientation plugin capability and after removing it, the issue got resolved. expo/expo#19720 (comment)

[fjpardo]

Hi @AdamDiament are you still failing to build with the Push Notifications aps-enviornment entitlement? I am pretty much running into the same problem as you.

[rgomezp]

@AdamDiament

has push capability, but the one-signal notification service extension identifier does not. The app groups section looks correct though. Is this expected, or is this the problem?

The aps-environment entitlement is only added to the main target and not the NSE. The NSE should only have app groups in its entitlement file.

When you go through the build step in the eas cli, are you going down the 'yes' path when prompted to add Expo notification support? If so, this might be the cause of your issue.

@bayramn
I'm glad to hear you were able to resolve. Thank you for clarifying that the doc was moved.

GUIDE

@fjpardo , see my response to @AdamDiament above.