I received this notification from app store team after submit app.(it's updated version)
Dear developer,
We have discovered one or more issues with your recent delivery for "XXX". Your delivery was successful, but you may wish to correct the following issues in your next delivery:
Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['EZQ6M662W5.11211'] and the new version of software being submitted has an application-identifier of ['XLHNTWNU3H.11211']. This will result in a loss of keychain access.
If you would like to update your binary for this app, you can redeliver your binary.
Regards,
The App Store team
any idea?
Apple have an answer for you here: https://developer.apple.com/library/content/qa/qa1726/_index.html
Q: How do I resolve the Potential Loss of Keychain Access warning?
A:
Potential Loss of Keychain Access. The previous version of software has an application-identifier value of 'A1B2C3D4E5.com.company.app' and the new version of software being submitted has an application-identifier of '5E4D3C2B1A.com.company.app'. This will result in a loss of keychain access.
Note: This is a warning, not an error. You have the option of proceeding with the submission regardless of this warning, however this document should be used to determine whether you can safely ignore it.
This warning indicates that the App ID prefix of the pending submission differs from the App ID prefix of the live app in the app store.
Important: The only apps that can ignore this warning without consequences are those that do not use technologies that rely on the App ID prefix, like keychain access, Handoff, and UIPasteboard sharing.
Apps that should expect this warning and proceed with the submission regardless are:
Those that are migrating their App ID prefix from an arbitrary Bundle Seed ID to their more-modern Team ID as documented in Technical Note TN2311 - Managing Multiple App ID Prefixes.
Those that are submitting the first update for a recently acquired app via App Transfer.
Note: Apps receiving this warning due to App Transfer should read TN2311 > A one-time loss in keychain data will occur if you switch your App ID prefix and understand that it's not possible for a transferred app to maintain access to the prior keychain associated with the App ID prefix of the previous owner.
For apps that do utilize technologies that rely on the App ID prefix, this warning should not be ignored. The Potential Loss of Keychain Access warning is an indication that the app was code signed with the wrong provisioning profile.
To resolve the problem:
You must locate or re-create a provisioning profile that uses the correct App ID prefix on the Certs IDs & Profiles website.
Click Edit on the profile to be certain the prefix is correct.
Click Download and save the profile to disk.
Optionally double check the App ID Prefix on the downloaded profile using the Terminal command in: How do I check the entitlements associated with my Provisioning Profile?
Drag the profile onto the Xcode icon on your Dock to install it.
Re-submit the app and code sign it with the newly restored profile that is associated with the right prefix.
"Keychain access" refers to all the functions in the Keychain Services Reference.
Related
When creating a App Group id in the Provisioning Portal (or whatever its called now), it says to "Enter a unique identifier for your App Group, starting with the string 'group'" and seems to enforce that in the entry field. Also, lots of sample code uses app group id strings like "group.com.company.blah".
However, the definitive sections I've seen to linked throughout the documentation,
App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory and Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group, directly contradict this, clearly stating "must begin with your development team ID, followed by a period".
The examples given in those section are like "Z123456789.com.example.app-group" and "DG29478A379Q6483R9214.HolstFirstAppSuite" respectively. (whah, is that last one a super weird team id or what?)
So with this inconsistency, what do I do to get a App Group ID to work? Should I enter in the Provisioning Portal "group.TEAM-ID.com.example.blah"? And should I use this same string in my source code strings, or omit the "group." part to be like the many code examples? Or is the documentation wrong and the team id is never needed?
Context ... I've been trying to update an iOS cocoapod's test app so I can see extension <-> app communication in action. After updating the app ids and group id to one's in my control, and when using a group id similar to the project's original one, like "group.com.mycompany.thingie", I see containerURLForSecurityApplicationGroupIdentifier: do nothing but return nil and nothing else has fixed it.
UPDATE: (added this for clarity seeing how SO informs me that this Q is getting many hits) It turns out this stuff is more forgiving than I originally thought, as the nil result turns out to have been (mostly?) my doing. See the answer & its comment thread. I haven't checked to see if the documentation & examples are any clearer yet.
On https://developer.apple.com inside "Certificates, Identifiers & Profiles" when you go to the "App Groups" section and first generate your App Group, all that is required is the enforced group.com.companyname.appname
As long as com.companyname.appname matches what you have setup as the bundle identifier for your target underneath general, you should be able to then go to "Capabilities" tab, turn on "App Groups" click the refresh symbol and the group you just created in Provisioning Portal should appear there, as "group.com.companyname.appname" you'll have the option to check it off, and then will have an error with entitlements. Clicking "fix issue" should automatically resolve it.
Now if you navigate to you entitlements file you'll notice that "com.apple.security.applications-groups" will have an item and it will be set to the exact same "group.com.companyname.appname" value.
I've tested on devices and have no issues yet. This doesn't account for the inconsistency in documentation, but I can guarantee that this works.
I got bitten by the inconsistency in this between iOS and macOS while submitting the macOS Sierra version of my app.
group.better.fyi works for iOS submissions but results in the following error during macOS submissions (runs perfectly well otherwise, with no warnings or errors):
ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '[group.better.fyi]' for key 'com.apple.security.application-groups' in 'ind.ie.Better-Mac.pkg/Payload/Better.app/Contents/PlugIns/Blocker-Mac.appex/Contents/MacOS/Blocker-Mac' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' ."
Replacing that with $(TeamIdentifierPrefix)better.fyi in the Capabilities tab under App Groups fixed the issue.
This does, of course, create an inconsistency between the iOS and Mac apps.
tl;dr version: https://stackoverflow.com/a/66647419/15809
But if you want to know all the details behind all this, please see below.
iOS
In the portal, all app group IDs created must start with group.; the portal will actually enforce that, so it's not even possible to register a group there without that prefix.
If the app group ID is then set on an app ID in the portal and an iOS provisioning profile is created for that app ID, the app group is embedded into the profile exactly as it has been registered. Take a look at such a profile and you will find the app group ID there.
If an iOS app has app group IDs in its codesign entitlement file, codesign will ensure that the group IDs from the entitlement are also found in the provisioning profile, otherwise it will refuse to sign the app. The provisioning profile thus whitelists the usage of these app groups.
When you configure an app group ID for an app in Xcode at the capabilities section, Xcode will put the ID into the codesign entitlements file for you. The app groups configured there for iOS apps must match exactly the app group IDs registered in the portal.
macOS
For macOS, though, things are entirely different!
If you add an app group ID to an app ID in the portal, this has no effect on macOS provisioning profiles created for that app ID. Have a look yourself; the app group ID is nowhere found in the generated profiles! Thus on macOS, a provisioning profile does not whitelist the usage of any app groups. You can put any app group ID into your entitlement files, this will always sign as codesign doesn't care. Codesign doesn't even care if your app group ID is prefixed by your team ID (or at least it didn't use to in the past, maybe it does as of today).
Unlike on iOS, the uniqueness of app group IDs on macOS is not enforced by the portal, it is enforced by the fact that Apple requires your app group IDs to start with your team ID, so uniqueness across teams is guaranteed and enforcing uniqueness within your own team is your own task.
Actually you don't need to register app group IDs for macOS apps at all in the portal. It's enough to just put your desired app group ID into your Xcode project capabilities and thus into your entitlement file. Many people think they have correctly registered their macOS app group when they register group.TEAM_ID.<whatever> in the portal and some magic makes this group work without group. prefix on the Mac, but that isn't the case. They just registered an iOS group of that name and the reason why TEAM.<whatever> works on the Mac is because that group doesn't require registration in the portal.
Now some readers will say: Wait a minute; if I can just put any app group ID into my entitlement files and it will always sign, who is actually enforcing that it is prefixed with my team ID? The Mac App Store. The Mac App Store won't allow you to publish an app with an app group ID that is not prefixed with the team ID of the publisher. If you try, the upload will fail.
App Groups and Security
You may wonder: Who is enforcing that app groups are prefixed by your team ID for apps distributed outside of the app store? Nobody. But then apps distributed outside of the app store can claim to be a member of any app group, even one from a different developer team, so how would that be secure? It isn't. Apps distributed outside of the app store don't even have to be sandboxed and if they are not sandboxed, they have access to your entire disk, including all app group folders of all apps, so how would that become any less secure by incorrectly claiming to be a member of an app group?
Apps distributed outside the app store may be sandboxed if they wish to restrict themselves for security reasons but even if they opt-in to that, they are free to poke as many holes into their own sandbox as they need or desire since unlike when distributing via the app store, there is no review that will ensure they only poke required and justified holes.
On iOS all apps are always sandboxed and distributed via the App Store, so this question doesn't even arise.
App Groups and Keychain Sharing
What about keychain item sharing? Keychain item sharing via app groups only works on iOS, not on macOS; for exactly that reason! It would be insecure on Mac. On macOS only sharing with keychain access groups works and those are in the provisioning profiles, also in macOS profiles, and for those codesign will always enforce that the profile whitelists them before it signs anything.
Reference from Apple
You'd like to have all of that confirmed directly by Apple? Sure, here is the reference provided by our most famous Apple tech support guru, Quinn:
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022
I've got the following warning while uploading a new version of the application:
WARNING ITMS-9000: "Potential Loss of Keychain Access. The previous version of software has an application-identifier value of ['52T2NMS37N.com.(my-app-id)'] and the new version of software being submitted has an application-identifier of ['FCGA72C62G.com.(my-app-id). This will result in a loss of keychain access. For more information, please consult (url)".
The issue may be because the application was transferred into another account.
The build was uploaded with the warning, but what does it mean?
From Apple's Documentation Archive, on Resolving the Potential Loss of Keychain Access warning
Potential Loss of Keychain Access. The previous version of software has an application-identifier value of 'A1B2C3D4E5.com.company.app' and the new version of software being submitted has an application-identifier of '5E4D3C2B1A.com.company.app'. This will result in a loss of keychain access.
Note: This is a warning, not an error. You have the option of proceeding with the submission regardless of this warning, however this document should be used to determine whether you can safely ignore it.
This warning indicates that the App ID prefix of the pending submission differs from the App ID prefix of the live app in the app store.
Important: The only apps that can safely ignore this warning are those that do not use technologies that rely on the App ID prefix, like keychain access, Handoff, and UIPasteboard sharing.
Note: Apps that are migrating their App ID from an arbitrary Bundle Seed ID to their more-modern Team ID should expect this warning, and proceed with the submission.
For apps that do utilize technologies that rely on the App ID prefix, this warning should not be ignored. The Potential Loss of Keychain Access warning is an indication that the app was code signed with the wrong provisioning profile.
To resolve the problem:
You must locate or re-create a provisioning profile that uses the correct App ID prefix on the Certs IDs & Profiles website.
Click Edit on the profile to be certain the prefix is correct.
Click Download and save the profile to disk.
Optionally double check the App ID Prefix on the downloaded profile using the Terminal command in: How do I check the entitlements associated to my Provisioning Profile?
Drag the profile onto the Xcode icon on your Dock to install it.
Re-submit the app and code sign it with the newly restored profile that is associated to the right prefix.
"Keychain access" refers to all the functions in the Keychain Services Reference.
I think that the prefix is relationship to Apple Id. I migrate my App to other Apple Id and when i re create the App Id, was created a new prefix Id.
This error happened when I tried to submit an update my app. I got this working by setting the Provisioning Profile to a specific one instead of the default 'Automatic' setting which seems to use some default XC one.
If you have transferred your app from once organisation to another :
Note : A one-time loss in keychain data will occur if you switch your App ID prefix
https://developer.apple.com/library/archive/technotes/tn2311/_index.html#//apple_ref/doc/uid/DTS40014135-CH1-A_ONE_TIME_LOSS_IN_KEYCHAIN_DATA_WILL_OCCUR_IF_YOU_SWITCH_YOUR_APP_ID_PREFIX
I had same issue, finally resolved by deleting the provisional profile at ~/Library/MobileDevice/Provisioning Profiles. and then downloading new from developer profile.
Go to the Finder then List item From the “Go” menu navigate down to “Go to Folder”
or Hit Command+Shift+G from the Mac OS X desktop or a Finder window
Search below Path ~/Library/MobileDevice/Provisioning Profiles
Delete the profile which has wrong Bundle ID, if you click on file MacOS X will show details. You can verify the bundle ID.
I had the same warning. In my case I have a wild card application identifier.
So first of all I found this appID '5E4D3C2B1A.com.company.app' and removed it. Then I created new appID, but change teamID to 'A1B2C3D4E5'. As result I got a correct appID like this 'A1B2C3D4E5.com.company.app'.
Then I regenerate all provision profile and everything works well. App didn't have strange behaviour in production.
But, pay attention please, I did it with wild card and I'm not sure if everything will be well with explicit application identifier.
This is a warning not an issue, when i got this error my build was
published to test flight by the way.
Scenario - When you transfer app from one account to another and then publish a build to appstore you get this error
I know how to sign an app with Appstore mobile provision, and how to re-sign an Adhoc-signed IPA with Appstore mobile provision. This is not my question.
My question is, can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore. Why? So that I don't have to store a redundant Appstore-signed IPA along every Adhoc-signed release candidate IPA, and don't have to do the extra step of re-signing that requires a Mac machine.
When using Application Loader, it is able to find all the stupid little errors, like missing icons and launch images, but even when I upload Adhoc-signed IPA through Application Loader, it doesn't complain about non-appstore mobile provision (which is very easy to verify, just like icons).
I have also found out in my testing, that when you take an Appstore-signed IPA (which you are not supposed to be able to install on devices unless distributed through Appstore), it is possible to install it on testing devices, provided the device already has Adhoc provision profile on it (same AppID, same distribution cert).
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
There was a similar question (closed) from almost 3 years ago, but the OP never provided an answer if it had actually worked: Submitted app to appstore with adhoc profile.
I hope someone since then had actually tried with it confirmed results.
There are a few targeted inner questions within your main question, I'll call attention to each part as we go -- as always, I'll be happy to revise or clarify if I miss something. I suppose it is only a closely guarded secret because much of the reasoning for it working come back to cryptographic details as a function of the Public Key Infrastructure system that backs Apple's provisioning -- This stuff gets deep fast so it is considered by some to be [dark] magic. Hopefully this will shine some light on what is going on!
TL;DR Version
Yes you can, but it is technically an unsupported use case that may change at any time. This works because what information iTunes Connect chooses to validate does not include the single differentiating factor between an App Store and AdHoc distribution provisioning profile. Since this is technically not a permitted configuration, I'd advocate for at least having a backup plan since Apple may change iTunes Connect validation policy at any time breaking this submission edge case.
Now for the curious, the here is the rest of the story...
Can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore[?]
As of this specific iteration of iTunesConnect and the Application Loader (4 Sept 2014 / Xcode 5.1.1), yes you can submit an AdHoc signed build and have it accepted through the pipeline. The eagle-eyed reader will note that my 'Yes' comes with a built-in escape hatch -- Because of the data encoded in AdHoc vs App Store provisioning profiles is nearly identical coupled with what parts of these files iTunesConnect is actually using for validation, an AdHoc provisioning profile presents to the delivery pipeline in the same manner as the AppStore version of the same app.
Should the provisioning format change between AdHoc and App Store files to explicitly differentiate the two types of Distribution provisioning profiles or should Apple iTunesConnect engineers change server-side validation rules, it is distinctly possible that this undocumented behavior will stop working. Of course we all know that we are supposed to use the App Store provisioning profile, as per Developer documentation in the App Distribution Guide > Submitting Your App > About Store Provisioning Profiles (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32) [emphasis added]:
A store distribution provisioning profile contains a single App ID that matches one or more of your apps, and a distribution certificate. For iOS apps, you need a store provisioning profile to submit your app.
...but this other avenue works for now. If you do choose to use this avenue, you just need to be aware that it is not the documented behavior and thus would be subject to change at any point in time, likely without advanced notice. Since it is skirting the edges of submission requirements it would probably be good to at least have a backup plan setup for the case of Apple changing provisioning or iTC validation requirements -- Murphy's law would dictate that these validation changes would happen at the most inopportune time.
Stepping off the 'Best Practice' Soapbox and turning to the technical side of things...
Why [does this work]?
As you may or may not know, provisioning profiles are composed of exactly 1 appId, one or more signing certificates, and zero or more test devices.
Related Reading: I've got a longer answer to What are code signing identities? that speaks in more detail to the parts of the codesign process.
In this case the question is 'why do AdHoc profiles work when the documentation says you need to have an App Store profile?'
The guts of a provisioning profile contain a cryptographically signed .plist that includes the information identified above, plus some additional metadata. On an OS X machine you can open Terminal and run:
security cms -D -i path/to/AdHoc.mobileprovision
...and in a separate Terminal window run the App Store profile equivalent:
security cms -D -i path/to/AppStore.mobileprovison
These commands will dump out the plist portion of the provisioning profile to their respective Terminal windows. When you scroll through the contents of both windows you will note that the following sections are identical:
AppIDName
AppliationIdentifierPrefix
DeveloperCertificates
Entitlements
TeamIdentifier
Version
The profile's metadata are different, but those are entirely expected differences that only matter for validating profile validity, or for humans interrogating the profile:
CreationDate
ExpirationDate
Name
TimeToLive
UUID
The salient points to take away are:
The DeveloperCertificates blocks are identical between both profiles.
The AdHoc profile only adds information (ProvisionedDevices) to the structure and format of the App Store profile.
The contents of the DeveloperCertificates array is the DER encoded X.509 iPhone Distribution Certificate -- The exact same as the one in your keychain. Is is important to note that this DER data is only the public portion of your Distribution certificate public-private keypair, and it can only be used by others to authenticate the application's signature came from you -- It can not be used to resign a binary as you.
If you paste the contents of DeveloperCertificates:Array:Data element into an ASN.1 decoder (http://lapo.it/asn1js/) and compare the elements of the output to the information encoded in the Distribution certificate included in the Keychain, you'll find that it is an exact copy of the public Distribution certificate you downloaded from Apple after submitting your Certificate Signing Request though the Certificates, Identifiers, and Profiles tool.
Because both the AdHoc and App Store provisioning profiles use the same public key certificate as their signing identity, they are inherently using the same private key when generating the application's signature. This means that the signature generated when signing with an AdHoc profile is functionally identical to one generated when signing with the App Store profile
When Apple performs a signature validation on iTunes Connect during the submission process, both and AdHoc signed cryptographic signature and an App Store signed cryptographic signature will successfully validate against the Distribution Certificate Apple has on file as both provisioning profiles are backed by the same Distribution Certificate.
So the signatures match, but why doesn't the extra information in AdHoc profiles trip up the submission?
Your original question suggests that you have familiarity with iOS' app install policies. For the benefit of someone stumbling across this answer in the future I'll briefly summarize:
iOS operates on a 'deny-all unless specifically permitted' policy. That is, iOS assumes you are not allowed to install an app unless a specific 'grant' has been allowed. For devices coming from the App Store, the app's signature includes Apple's App Store identity for which iOS has a specific 'grant' privilege. AdHoc installs by default fall under the 'deny' policy and the ProvisionedDevices section of a Development or AdHoc profile are the specific 'grant' privileges. The app will install outside of the App Store if all of the following hold true:
The application's cryptographic signature is valid
The application's embedded provisioning profile's cryptographic signature is still valid (the profile hasn't been tampered with)
The application's embedded provisioning profile's ExpirationDate hasn't passed and the current time isn't before the CreationDate
The embedded profile or a profile installed to the device match the AppId being proposed for installation.
The embedded profile or a profile installed to the device contain an entry in ProvisionedDevices that exactly match the device's UDID.
As we saw above, the app identity and signing information is identical between an App Store profile and and Ad Hoc profile -- the addition of ProvisionedDevices serves only to add these 'grant' privileges for an external (outside of App Store) distribution mechanism. It turns out that iTunes Connect / Application Loader validation is currently only validating that a Distribution profile was used for the app's signature, not that the profile that was used was an App Store profile instead of an AdHoc profile.
This boils down to the fact that the as of Version 1 (ala Version block in the plist) the only differentiating factor between AdHoc and App Store distribution profiles is the presence or absence of the ProvisionedDevices block. It turns out that as of today, this is not a detail that Apple looks for when interrogating the profile that was used, thus the binary passes the automated portions of app verification. They definitely do check that the AppId in the profile matches what the App claims, that the signing identity matches what was used to sign the binary, expiration dates, and any entitlements used match what is found in the automated scan of the app, in addition to the items you highlighted in your original question (version checks between iTunes Connect and the info.plist, iconography presence, iconography sizes, etc.)
Hypothetically, in a subsequent iTunes Connect / Application Loader update, they could start checking for the absence of this key in the embedded.mobileprovision profile that exists within the submitted binary and auto-reject the submission on the grounds that an App Store profile was not used. Similarly, if the provisioning profile format was updated (ex. Version=2) they could add a new element that explicitly calls out the type of profile and auto-reject if it isn't an App Store type. It could perhaps look like this:
<key>ProfileType</key>
<integer>1</integer>
Where the integer value could be 1, 2 or, 3 depending on the type of profile in use, consistent with the formats used in things like Info.plist for identifying supported device families (iPhone-only, iPad-only, or Universal). This would clarify other questions that have been asked about identifying the type of build.
Related Reading:
How to detect that a provisioning profile is for development or distribution, programmatically
Check if app is ad-hoc|dev|app-store build at run time
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
Yes they do! If you look at archived versions of the apps you submitted you'll find that the contents of the app contain embedded.mobileprovision -- if you then go download the same version from the App Store, you'll find that file missing. Apple only uses embedded.mobileprovision to verify the contents of your app during the submission and review process. When the app is 'Processing for App Store' the final package is assembled and the embedded profile is removed.
I just got this warning when submit my app to app store, it is just warning, not error. This app was transferred from another developer account to my account before, so the prefix of the App ID is changed.. I think this should be unavoidable, but since I got this warning, what does it affect my app actually? What Keychain access would be lost?
Have you transferred the app from another developer account to your one? The previous provisioning ID will obviously be different.
UPDATE - For clarification
I have noticed that this answer is getting a lot of views so I will just edit it to include my further explanation from the comments below.
Basically the previous version of your application will NO longer be able to access keychain in order to save secure strings such as passwords (if it contains this functionality). This is because the distribution/provisioning profile it was signed with contains a different ID than the one you are using in your new distribution/provisioning profile because you have transferred your app from a previous account to your new one.
However any NEW versions of your app which are signed with the latest distribution/provisioning profile WILL be able to access keychain as normal in order to save secure data if they need this functionality because they are signed with a distribution/provisioning profile which contains the latest App ID for that app.
The warning informs you that your updated app will not be able to access items previously saved in the keychain. The old version of your app can still access and store items in the keychain, just like the new version. However the two versions cannot share information in the keychain.
In summary, all data saved in the keychain will be lost once a user updates to the new version. All information stored in UIPasteboard will also be lost.
You can see this message if:
The app was transferred to your account and you are updating it for the first time. In this case there is nothing you can do to prevent the warning (and side effects).
Your app was added to iTunes Connect before June 2011 and you recently updated the provisioning profile used by the app. Either your old provisioning profile was using a wildcard (*) App ID and the new one is now using a specific App ID, or the opposite (less likely). In the later case you can switch back and avoid the warning (choose the correct provisioning profile in Xcode). In the other case, chances are your app needs access to services like Game Center, Push Notifications (or anything that a wildcard App ID will not let you use) and you cannot avoid the warning.
If you want more details, the warning is related to the fact that App ID prefixes are attributed by Apple and cannot be changed. Check the "App IDs" section in Apple's "Certificate, Identifiers & Profiles" page (https://developer.apple.com/account/ios/identifiers/bundle/bundleList.action - you need to sign in), press on an ID and look at the "Prefix" field. You can also check Apple's Technical Note 2311 https://developer.apple.com/library/ios/technotes/tn2311/_index.html
Lastly, you might thing you could avoid the warning by changing the Keychain Access Groups (keychain-access-groups) field of your provisioning profile. This will not work as Apple will not let you have different prefixes for the App ID and for the Keychain Access Groups.
As of the stricter security in iOS 8.1.3, this is much more serious than the warning suggests; see https://developer.apple.com/library/ios/technotes/tn2319/_index.html#//apple_ref/doc/uid/DTS40013778-CH1-ERRORMESSAGES-UPGRADE_S_APPLICATION_IDENTIFIER_DOES_NOT_MATCH_THE_INSTALLED_APP. It seems like the mismatch causes a failure to upgrade to the new version. When I try to update via Xcode, it fails with an error to the device console like that in the Tech Note: “Upgrade's application-identifier entitlement string [....] does not match installed application's application-identifier string [....]; rejecting upgrade.” Trying to update via iTunes seems to fail silently.
I hope that the answer is simply “this error is simply an indication that Xcode has chosen the wrong provisioning profile,” verified as in https://developer.apple.com/library/ios/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG65. But I last submitted my app many Xcode versions ago, and finding the right one may be a challenge.
Note the phrasing “Xcode has chosen the wrong provisioning profile”; to make sure that it chose the profile you thought you chose, click on the arrow next to the chosen profile’s truncated name in the archive verification dialog. To double-check this, submit to the App Store with a known error (I inadvertently used a missing icon), so that you see whether the warning appears.
I have an app I tried to submit to the app store. Like many others I'm getting the following e-mail from the app store approval process. The answer to the other questions seems to be, uncheck iCloud from the App ID, but my app uses iCloud and I wouldn't want to lose that functionality. Has this been solved yet?
I did double check that my App ID's Bundle Identifier matches the value of the items that are entered in the Entitlements area of the Target Project. Thanks for your help!
Dear Developer,
We have discovered one or more issues with your recent binary
submission for "XXXXXX". Before your app can be reviewed, the
following issues must be corrected:
Invalid Code Signing Entitlements - The signature for your app bundle
contains entitlement values that are not supported. For the
com.apple.developer.ubiquity-container-identifiers entitlement, the
first value in the array must consist of the prefix provided by Apple
in the provisioning profile followed by a bundle identifier suffix.
The bundle identifier must match the bundle identifier for one of your
apps or another app that you are permitted to use as the iCloud
container identifier.
Specifically, value "XXXXXXX.com.xxxx.xxxxxx" for key
"com.apple.developer.ubiquity-container-identifiers" in WeHeartApps is
not supported.
Once these issues have been corrected, go to the Version Details page
and click Ready to Upload Binary. Continue through the submission
process until the app status is Waiting for Upload and then use
Application Loader to upload the corrected binary.
Regards,
The iTunes Store Team
Found the answer, it seems as though my Provisioning and Distribution Profiles were out of sync. When in doubt;
delete your provisioning and distribution profiles on the iOS provisioning portal
recreate them on the iOS provisioning portal
Delete the old ones locally.
Download the new ones from the portal.
Clean the project
Drag the new profiles onto the xcode app
Do a fresh "Build for Archiving." ( Make sure iOS device is selected for this to be enabled )
Finally archive
Go to the organizer and Validate the Archive
Submit to the app store!
Cheers
For others who have apps sharing data between both Mac and iOS devices via iCloud, you will also run into this problem if you try to submit the platform which depends on the other's bundle identifier first. This is because the bundle identifier you're trying to share data with has not yet been registered as an app.
The solution is simply to submit the app whose bundle identifier you're using as the com.apple.developer.ubiquity-container-identifiers entitlement first.
For example, if you're sharing data between a Mac app with a bundle identifier of com.mycompany.osx, and an iOS app with a bundle identifier of com.mycompany.ios, you will likely choose one as the mutual data store. If you choose the iOS version, the your Mac app will have the value "com.mycompany.ios" set as your ubiquity storage and iCloud key-value storage. In this case you just need to submit the iOS app first so that the "com.mycompany.ios" bundle identifier registers as a valid app on Apple's side.