On Jun 11, 2014, at 00:41 , Martin Umgeher <email@hidden> wrote:
So now I'm stuck. Does anyone have an idea how to solve this issue?
How can I get rid of this mysterious App ID XYZ.foo?
How to find out where and why it is used?
Is there a way to preserve keychain access when changing the App ID prefix?
I don’t know if my last experience in this quagmire is still relevant, but here are some things that I ran into a while back:
— In the distant past, it was fine to use multiple prefixes. At some point, the policy changed so that developers should only be using their developer ID prefix (XYZ in your case).
— In particular, you must use XYZ for MAS-unique entitlements such as iCloud access and (I presume) push notifications. Forget about trying to use ABC.something in an app with such entitlements. It simply won’t work.
— You can’t delete app IDs. You’re going to have to let the old ones sit there forever.
— In spite of ABC prefixes being essentially useless, Xcode appears to choose a *random* wildcard appID to use when it wants a wildcard appID for debugging (i.e. non-archiving build operations). So, it may continue using ABC.* even though ABC is obsolete. AFAIK there is no functional downside to this, it’s just untidy.
It’s not entirely clear what you mean by “preserve keychain access”. If you mean there’s app/user-specific data stored in the keychain under ABC.*, then I don’t know how you’re going to get to it from an XYZ.foo app. In the worst case, perhaps you can put out a utility under ABC.* that extracts the data for migration to the new app. If no one jumps in with a better answer, it may be worth using a TSI to get a definitive answer on this.
HTH
|