
I’ve read Where does xcode take application’s Identifier from? , XCode bundle identifier formatting from {PRODUCT_NAME} , and loads more but… I’m trying to get push notifications going and getting the dreaded
I’m fairly certain I’ve followed all the steps correctly, including:
The only think I can’t quite get my head around is the Bundle Identifier The push certificate is for
The Bundle Indentifier in PwCNewUK-Info.plist is for
If I manually change it to
I get a UDID mismatch error as the app is seen as PwCNewsUK When I’ve Googled this there seems to be some confusion over the matter, but it seems they have to match? QUESTION: What should the Bundle Indentifer be to match the push certificate of QUESTION: Do I need to add a “aps-environment” entitlement to the provisioning profile, and if so where and how? (See http://www.airplaysdk.com/node/3174 amongst others) Loving iPhone development but sheesh it can be a headbanger at times! |
|||||||||||||
|
I found this question when I was moving from a development environment to a production one on an application that I am working on. This process involved the creation of a new profile, a new app ID, etc. I created the app ID and a profile, but the Team Agent had to configure the push notifications. I ran into the problem of “no valid ‘aps-environment’ entitlement string found for application” when I tried to resume testing with the new profile (after the app had been configured for push notifications). I then remembered reading a little caveat in the documentation: “You have to modify the profile in some way (for example, toggle an option) for the portal to generate a new provisioning profile. If the profile isn’t so “dirtied”, you’re given the profile without the push entitlements.” Source: Local and Push Notification Programming Guide For me, “dirtying” the provisioning profile and reinstalling it was all that was needed to fix the issue. Per the documentation, this was required because the provisioning profile was created before the app was configured for push notifications. This may or may not help anyone, but this probably explains (and eliminates) the need to manually add anything to the provisioning profile. |
|||||||||||||||||
|

I ran into the same “no valid ‘aps-environment’ entitlement string found for application” problem, but the above solutions did not work for me. I could not find very good documentation about this error or even just the key “aps-environment”. After some tinkering around, here is what solved the problem for me: Open your development provisioning certificate, “Appname.mobileprovision” with a text editor, look for the key “Entitlements” then add all of the values found here to your Entitlements file referenced by your Code Signing Entitlements setting. Here is an example of what keys/values you’ll find inside:
After adding all of these values to my Entitlements file my app builds successfully and I can finally get back to working on Push Notifications. I’m not sure if these values are supposed to be automatically added to your entitlements file by XCode, but they certainly weren’t being generated for me in my project. |
|||||||||
|
Essentially the answer is the same vague one everyone else says
Repeat these steps calmly until it works, took me about five goes of various combinations. I also switched from Development to Ad-hoc which apparently isn’t necessary but did guarantee a new mobileprovision file. |
|||||||||
|
Setup: Mac OS X 10.8 + Xcode 4.4 My Simple Solution:
Some hints on that issue: After activating Push Notifications for my app I suddenly couldn’t create ad hoc files anymore. I ran across errors in my Console log on my iPhone while trying to install my app such as those:
There is some technical note which recommends using As far as I knew so far, my apps signed with an adhoc provisioning profile always have an
After using codesign I realized that the actual binary in
I assume this is the cause for the error message we are all experiencing. (although this error can have some different roots as well as other posts on stackoverflow suggest)
My guess is that there is some bug in Xcode which keeps the settings in your plist from being updated in you schemes which then causes your app to be signed with the wrong provisioning profile in the end. So by deleting the xcuserdata folder you delete all schemes. Therefore Xcode will recreate them next time with the proper settings and you are happy again. |
|||||||||
|