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.
Related
I have an app which I've just submitted to the app store. In the developer portal it has push notification checked, however it's not yet configured.
I want to add Push notification capability to this app. I try to turn on Push in XCode Capability tab. There was a issue and I press fix issue, it said the ID is not available, though it it the ID for the app already available in the app store.
Also under the General tab:
Now what do I do to fix it? Despite having read "iOS Code Signing: Under The Hood" from Ray Wenderlich I'm still having a headache.
EDIT:
OK the accepted answer wasn't really it. I finally found the correct answer to this question from JRRevuelta's post in the Apple forum:
Go to your Apple Developer "Certificates, Ids, Profiles", and under
your App IDs list find the App ID in question and, If your App ID is
in the form: com.myDomain.MyApp Then the name in your App ID record
has to be: "XC com myDomain MyApp" Don't ask me why, but it works.
(is the default name that XCode assigns when you create the record
from XCode), but for records that exist prior or that you created
directly in the Developer site, the name should be whatever you
want... but its not. Some glitch introduced in one of the latest XCode
releases.
Apparently this problem only surface in recent Xcode.
Check the following steps it may solve your problem:
manually removed INVALID iOS Team Provision Profile Managed by Xcode from Developer Portal
manually created iOS Developer Provision profile
Downloaded it via Xcode
For more information you can check: https://stackoverflow.com/a/36175175/4557505 answer, this answers the same issue which you are having
I think you need to create the SSL certificates and set up a provisioning profile matching your needs. Assuming you already have an development provisioning profile for your app-id you just need to add the SSL certificate for development. When done testing add the certificate for production.
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 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.
I just added a 2nd developer account to my computer to distribute apps. I wanted to keep everything seperated so I created another account for it.
I can validate and send apps with the new account, but now I get an error when I validate apps under the old account.
the error says my bundle contains a key value that is not allowed, the complete error message is
"Invalid code signing entitlments the entilment in your app bundle signature does not match the one conained in the provision profile. the budle key keu value that is not allowed 73pngm574.abctest
I'm using the xcode wildcard id for my app so abctest is the bundle id and 73pngm574 is my dveloper id
One thing that has worked for me is using Xcode to set things up correctly for you. Xcode --> Preferences --> Accounts. Use the account setup to link to your developer account and Xcode should sync things up for you.
You may need to remove any old keys or profiles you've copied in or tried setting up previously. Not exactly ideal, but "usually" works for me.