I am trying to upload an app to the app store and I am getting this error on the page that has the certs. As far as I can tell I have changed the field so they have matched, but I am missing something.
Any help would be greatly appreciated.
I am trying to upload an app to the app store and I am getting this error on the page that has the certs. As far as I can tell I have changed the field so they have matched, but I am missing something.
Any help would be greatly appreciated.
Please check your application features which required for your application like In app purchase , push notification , Inter App audio , Siri kit etc.
This is the only cause for this type of error.
Make sure that in your App id the above flags should be on.
Most of time it happens when you not configured push notification , In App purchase in you development App ID.
Multiple targets:
...and use iCloud.
Turning iCloud on and off was not an option for us. We already use it in production and rather not mess with it... I got the original question's message and this variation at some point as well:
Profile doesn't match the entitlements file's values for the application-identifier and keychain-access-groups entitlements.
Hinted from other responses here, We made sure that all targets would have a .entitlements
file. If the target had none we created an empty one like so:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict/>
</plist>
...and pointed it's target Code Signing Entitlement
in Build Settings
to the empty .entitlements
file.
Solved!
I'm developping a Flutter app with Flavors that use the --dart-define command. I've been very inspired by this great article.
However I've encountered this 'application-identifier' issue when deploying. I've tried a lot of options. This solution is the one that worked for me. It's very close to @n8tr's comment, but the difference was the 'instead'.
To resume, just set the Product Bundle Identifier to your.id.here$(DEFINEEXAMPLE_APP_SUFFIX)
under Packaging in Build Settings instead of in Info.plist.
I had this issue with a brand new app, in Xcode 12 beta 3 (app submissions started today).
Xcode had "Automatically manage signing" on. However, the Team ID displayed in the "Signing Certificate" didn't match the Team ID displayed in iTunes Connect website. This was the root cause preventing the app from being uploaded.
How I fixed it:
The app you created has an incorrect application-identifier
value, for what the provisioning profile is expecting. The cert for appID com.example.foo
for the team 2ABCDEFG
will be expecting application-identifier: 2ABCDEFG.com.example.foo
, your app declared that its appID was com.example.foo
, but the application-identifier
didn't match, either you are using the wrong team-prefix, or you have the bundleID misconfigured.
In my case, I am using build schemes to allow me to build a prod app and a qa app. com.example.foo
for prod, and com.example.foo.qa
for QA.
I had set my bundleIdentifier in the Info.plist
to $(PRODUCT_BUNDLE_IDENTIFIER)$(BUNDLE_SUFFIX)
, which works great in the simulator and on device for having different apps, however, when the app generates its application-identifer
during the archive phase, it must not be reading the bundleIdentifier generated by the Info.plist.
To remedy the situation, I edited FooProject.xcodeproj/project.pbxproj
(with a text editor) to change my QA buildSettings PRODUCT_BUNDLE_IDENTIFIER
to com.example.foo.qa
You can see Apple's Technical Q&A and this page to see their in depth dive into solving this. Once you run the following on your exported app:
codesign -d --entitlements :- ./Payload/myApp.app
and see what application-identifier
your app was just built with, it should be pretty quick to realize what your are doing wrong.
I didn't find that page in my Google searching, because they don't actually use the phrase from the error message or call the application-identifier by its full name, but instead say App ID.
Also, the solution to this problem isn't to generate a new provisioning profile that has the application-identifier
entitlement, it does have that entitlement, however, the value in the provisioning profile, and your app have to match.
Just have a look, whether the "Sign in with Apple" capability is added along with other capabilities such as "Background Modes" & "Push Notifications"!
In my case, it was there.
So after deleting the "Sign in with Apple" capability, it got removed from the 'project.entitlements' file and the provision profiles got synced immediately.
Removing and creating a new Provision profile from https://developer.apple.com/account/resources/profiles/list and then reinstalling it worked for me
TL;DR: check your App ID and make sure the services are matching what's in your target.
What happened to me was that I let Xcode 10.1 help me create an App ID, and after that, I run into the problem as described here. (I selected whildcard app ID when I created the app in iTunesConnect, so I didn't even realized this was done.) When I opened iOS developer portal, the new app ID has Game Center and In App Purchase enabled automatically.
Since I couldn't enable Game Center in your Target -> Capabilities
, I enabled In App Purchase, and then my app could be signed and uploaded.
In Xcode 11, this could happen when a .entitlement file is not present for your project. The solution would be to add any random capability by clicking on '+ Capability' under 'Signing & Capabilities' (which leads to the creation of an .entitlement file) and then removing the capability. This will let you automatically provision a certificate too.
When we faced the same issue, we tried all the above things but none of it worked.
What worked for us is changing the bundle identifier so that it was not identical to the previous one, for example "com.name.App" to "com.name.App2"; let xcode attempt to fetch/create provisioning profile and then chance it back to the original one.
Got this idea from this thread on Apple's developer forums- https://forums.developer.apple.com/thread/114539
I came across this page recently after trying to create a duplicate target - none of the suggestions were working for me. Further investigation, and some amount of hair pulling, eventually led me to scouring through the build settings for my app to try and figure out what was wrong.
It turned out that my project was still pointing to the entitlements file of the ORIGINAL target, rather than having one of its own. To resolve this, I navigated to the original entitlements file in Finder (e.g. ${SRCROOT}/MyProject/Entitlements/TargetName.entitlements), created a copy within the same folder and then renamed it (e.g NewTargetName.entitlements).
Then, I opened my new entitlements file and changed the application-identifier field to match the ending of my new target's bundle identifier (e.g. ABCDEFGH.US.co.fake-company.superduperapp-newtargetname).
Finally, I updated the 'Code Signing Entitlements' field in the build settings to the path of my entitlements file (for me, this was something along the lines of ${SRCROOT}/MyProject/Entitlements/TargetName.entitlements).
I returned to the Signing & Capabilities tab, and lo, the issue was fixed. Hope someone out there finds this useful.
I ran into the same issue while setting up a Gitlab pipeline that runs exportArchive cmd and uploads to AppStore. I was able to get it to work by changing the DEVELOPMENT_TEAM in Build Settings to the same Team selected in Signing & Certs.
Because previously it was set to blank which was using another DEV TEAM id by default which was incorrect and didn't match and it was complaining about the "application-identifier" = 12331232.com.bannana.apples.peach not matching. Which lead me to setting the correct DEV TEAM and it worked.
Xcode ver: Version 11.3.1
I hope this helps somebody.
I'm not sure why this fixed it, but I went into my Target's Capabilities tab, turned iCloud ON, tried to do an archive build, it failed, I turned iCloud OFF again, tried to do an Archive build and it succeeded, and after that it was able to automatically resolve certificates again.