-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing Push Capability on iOS - EAS Built App #67
Comments
Howdy, |
Hey @rgomezp - I'm using |
@tomosdevans , |
Hey guys, Also just had a look at this guide, I did do those exact steps yesterday: On my first correct configuration, the build went through, and correctly had entitlements. 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. Successful one:
Failed one(s):
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.
Unrelated: having autoIncrement with EAS appears to cause a version mismatch between Onesignals Extension and the app. 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.
within withEntitlementsPlist inside node_modules/@expo/config-plugins/build/plugins/ios-plugins.js Really not sure. |
@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:
|
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! |
@tomosdevans Thanks for the kind words, and for making the issue.
And then running
Probably want profile to be something else for you but there's a possibility this is the solution. |
Specifically I think that the --non-interactive flag is good. |
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:
Thanks again for the help - genuinely appreciated. |
For local builds the plugin config code is triggered via Btw |
Thanks @rgomezp - that's helpful to know. We're using the EAS build service, which does a Given that the cloud build does the |
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. |
OK - understood. This is an obscure issue, so appreciate that there's some experimentation involved. FWIW - I think the Can you help me understand the specific instructions that you think would be worthwhile trying?
|
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. |
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:
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! |
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 |
Thanks so much for the support @JustinRohweller. So, if I've understood correctly, the suggestions is that I do...
And then see if that yields a different result. Hope I've understood that correctly, and I'll report back with the result. |
Yes, exactly. I'll be trying it more tomorrow as well. |
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. |
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. |
So, just an update on my end: However, I have had a 100% successful entitlements build rate every time I have done:
Might just be my setup is different, but wanted to just put it out there that it's been working consistently for me now.
Hopefully this helps someone. |
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:
Then it works successfully for me. Note, I didn't need the 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. |
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 |
@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. |
@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 |
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? |
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 |
@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.
Yes, the build succeeded, the app runs, but I get "Missing Push Capability" in OneSignal.
I'm 100% certain. I used 1.0.1:
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. |
The last few builds that @tomosdevans did were all
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 " 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 |
@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:
To pursue your suggestion... I continued to follow the process of So, I think you're correct in your suspicion that the randomness is introduced by the 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. |
@tomosdevans , 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. |
@tomosdevans , |
Hey @rgomezp - thanks for being attentive on this. To answer your question around I'm happy to dig into this if it would be helpful. |
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. |
@tomosdevans ,
Yes! That would be great. I left a comment that you should be able to copy into your package.json for testing. |
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 |
@tomosdevans , Please upvote this comment if 1.0.2 worked for you. |
@wkozyra95 @rgomezp @tomosdevans SUCCESS! You're all rockstars and I love you. |
@rgomezp @wkozyra95 - just to let you know that I have run 6 successful builds on my test project using 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 Thanks again - truly appreciated. |
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.
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
Can anyone else confirm this behaviour? |
For me, it worked for new projects, for existing one and internal distribution is always Missing Push Capability. |
Hey @jurica-penjgusic. For full disclosure, @NashAtFramework and I are team-mates! We needed to run 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. |
I can confirm that moving expo plugin to first place in array adds wanted entitements. |
This should be documented, because it's really hard to find out right solution. |
Ya this sent me for a loop for several hours. Please update the readme with this info for future devs. |
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
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. |
I can confirm that placing the plugin in first position solves the issue for me |
page not found |
@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) |
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. |
The 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 GUIDE@fjpardo , see my response to @AdamDiament above. |
Problem Statement - Our iOS integration with OneSignal is not functional due to a Missing Push Capability error in OneSignal.
Environment Details
Steps Taken to Resolve / Root Cause Analysis
EXPO_NO_CAPABILITY_SYNC
as per https://docs.expo.dev/build-reference/ios-capabilities/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:
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 differenteas build
runs (with identical input and parameters) would have different results.The text was updated successfully, but these errors were encountered: