I'm in charge of developing and submitting the apps to the app store as the clients have sent us their apple logins. As far as developing the apps, that's been OK (I haven't submitted any yet) but in the next week I will need to submit at least three, all with different Apple IDs.
I've removed the Xcode password from the keychain and synced my certificates to the second Apple ID I have. Oh god, the mess it made with my keys, and profiles. When I did this with my own Apple Id (Xcode 3) I had to do the whole thing manually and could name keys, etc like I wanted. I entered the second Apple Id (Xcode 4) and now Xcode want's to manage everything for me. I like this but it created the keys and profiles with some stupid names. It makes it very difficult for me to sign apps with one or the other and also to backup one client's keys and not confuse them with mine. I'm afraid to enter the third Apple Id because I know the mess will be impossible to handle.
I'm open to tips, gotchas to look out for when working with multiple Apple IDs so that I can know "how it's done". And also, any other things along the way that I might encounter in the submission progress.
This is much easier if you use a separate user account on OS X for each client.
If you use one shared account for everything, then there shouldn't be any conflict if you only have one developer key and use separate bundle IDs for each application. The signing works backwards from the bundle ID - from the bundle ID it finds the correct provisioning profile, and from the provisioning profile it finds the correct distribution key.
Related
I've recently had some involvement with a group with an organizational account for iOS development.
They have multiple teams all developing separate iOS applications. I was somewhat surprised to learn that there is no coordination at all of use of the organization's "iOS distribution" certificates. Instead whichever developer needs to submit a build just creates a new one, revoking one or more existing ones if necessary (Apple appears to allow a limited supply of three of these to be "live" simultaneously). Justification for this practice seems to be a combination of the observations that:
distribution certificates created by one developer aren't (easily) usable by another (you can find quite a few questions around SO on this topic; the solution appears to be to make sure the private key element of the certificate is also shared, but this organization has yet to take that on board. Example, another example; there are many more).
xcode7 makes it easier than ever to churn distribution certificates, so it's clearly Apple's intended way (xcode6 would have needed a trip to the developer center).
distribution certificates are only needed for the fairly small window of appstore submission; once the app is in the appstore it makes no difference whether the distribution certificate is revoked.
Apple seem to have some slightly odd last-in-first-out rules around distribution certificate renewal (if you have "old", "newer" and "newest" and you revoke "newer" or "newest"... you'll find you still can't create a new one until you've revoked "old"). Or at least those rules appear odd to an organization which would have liked to divide up the limited stock of distribution certificates between various teams/projects, but found that didn't fit what Apple actually provide.
However, I observe a very serious negative consequence of this policy of rapid distribution certificate churn is that testflight builds don't stay valid for very long at all and tesflight users find themselves getting dialogs about invalid certificates or having apps they're supposed to be testflight testers of disappearing from testflight all too soon. (In fact see also this question along the same lines).
Given that Apple clearly see testflight as an important piece of the appstore infrastructure, I find it hard to believe this organization is going about things in the way Apple actually intend things to be done. Can someone with some insight into the Right Way of doing things please enlighten me?
Apologies if my terminology is off in some of the above... I just dabble in this stuff.
The right way is to have one distribution certificate and share the private key. We share a small keychain that contains just the private keys and certs needed for development/distribution among our org. You can add this 'stub' keychain to all your development machines, and if it's checked into version control, you can push out updates to everyone easily. You can also password protect it, in which case Xcode will ask you to unlock it when using to codesign.
The fact that it's "easy" to churn the certs is actually a bad thing, IMO. As you've observed, it's easy for other developers on the team to screw things up, particularly regarding TestFlight, although I heard from another developer recently that Apple might have fixed that. (I haven't confirmed it myself.)
I'm stuck in a slightly weird situation. When our app was first created, nobody really knew what they were doing and I'm trying to clean things up a bit.
In the iOS developer center, it seems that there are two App IDs for my app. I think I can delete one of them, because the other one is the one that is actually being used, but I'm not 100% sure.
Here is the App ID that I think is actually being used in our released app:
Here is the "other App ID":
The annoying thing is that the "other App ID" seems to match the bundle ID of the app and xCode seems to be trying to use it as the application-identifier when the app is submitted to the store. I don't want the application identifier to change.
Is it safe to delete the other app id? Can I force xCode to use the correct application identifier? How can I tell which app ID is actually being used by our released app?
Edit:
Why this arose is because after submitting our latest build to the store for testflight, I got this notification:
Dear developer,
We have discovered one or more issues with your recent delivery for
"My Cool App". 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 ['ABCDE.MyCoolApp'] and the new
version of software being submitted has an application-identifier of
['QWERTY.MyCoolApp']. This will result in a loss of keychain access.
After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.
Regards, The App Store team
The fact that the application-identifier is changing, and that it appears to be using the "prefix" as part of this value, suggests that it was using the first app ID, but now it is going to use the second.
Do you have access to login in to the iTunes Connect for that account? That's what you really need to verify the bundle ID (aka app ID) of the released app.
Login at itunesconnect.apple.com, click on apps, click on your specific app, click on the 'more' tab, click on 'about this app' it will show you the bundle ID being used for the released app. Feel free to delete the OTHER app ID out of your account. Not the one in iTunes Connect :)
The bundle ID in your Xcode project can always be modified to match whatever app ID you'd like, as well as you can easily regenerate any necessary provisioning profiles for any app ID. (of course, you should make it match the existing one in iTunesConnect if you want to release an update for that app)
Edit:
It sounds like you've been able to match up the app ID, but not the prefix. The way prefixes are assigned has changed over the years and now they are all team based. You can read this technical note and see if it will help you resolve the warning you encountered.
Developer Link
The primary difference between your 2 App ID is the ID:
the first one has '*' as ID. It means it is a wildcard ID. You can create multiple applications using different bundle identifiers with the same provisioning profile using this ID. But you don't have access to specific capabilities such as Push Notifications, in-app purchase (because multiple apps will share the same profile
the second one is fully qualified and can be used only with the app whose bundle identifier is 'MyCoolApp' and can have access to full capabilities of apps.
Note that your app ID naming convention should be in reverse url format as Apple advices: myCompany.myInternalGroup.myAppId.appFlavor for instance.
I am trying to understand the role of the first part of the AppID for iOS apps.
This part was formerly known as the "Bundle Seed ID", but is now often referred to as the AppID Prefix.
A while ago (iOS 5?), Apple made some changes in both their portal and their documentation and started to recommend using the "Team ID" (unique per developer account) as the AppID Prefix. This is simple and straightforward for new developers with new apps.
But what is the the best practice for handling existing apps with regards to the AppID prefix?
I know that it is not possible to change BundleID (= the second part of the AppID) between two app versions, but is it safe to change the prefix between app versions?
Note that I am not referring to replacing a "wildcard AppID", e.g. ABC1234567.*, to an explicit AppID using the same prefix, e.g. ABC1234567.com.mycompany.myapp. There is tons of information about this (most of it outdated, though). I am thinking about changing the complete AppID, e.g. ABC1234567.com.mycompany.myapp, for an existing app by replacing the prefix with my Team ID, e.g. DEF7654321.com.mycompany.myapp.
I think I have read somewhere that it should be OK to change the prefix for existing apps, except in the special case that the app is using the keychain to store data. If this is true, the easiest way to handle the prefix for existing apps would be to migrate to the new Team ID when it's time to release next update. When all my apps are migrated, I can continue using the Team ID (as Apple recommends for new apps) and finally forget about all this mess.
Can anyone confirm this?
If you can shed some more lights upon the concept of the AppID prefix, and what it is actually used for on an iOS device (except the keychain which I already know about), I would be happy if you could write a comment. Perhaps we could build up the full understanding of this by adding bits and pieces from different sources. Sadly, the Apple documentation is very thin in this area.
(There is another similar question: Can I change the Bundle Identifier in my app after it's been approved? But that is mainly focusing on the BundleID, i.e. the second part of the AppID, so this is not a duplicate, even though some of the answers and comments are touching upon this topic.)
My conclusion, as of today, is that it is completely safe to replace the AppID prefix by a new one, with the exception of apps using the keychain. This opens up for migrating the prefix for all my exiting apps on the App Store to the new TeamID based prefix.
This conclusion is based on the following input:
A discussion I had with Apple's developer support a couple of weeks
ago. They told me that there should not be any problems changing the prefix, except for apps using the keychain.
A test I did, using ad-hoc distribution, verifying that an existing app on a test device did not lose any data when it was updated to a new version with another prefix.
The fact that I have successfully uploaded new versions, with replaced prefix, of two
of my existing apps without any problems so far.
The status of the two "live" apps that I have changed, is that they have been approved in the review. However, they are currently waiting in "Pending Developer Release", since I am waiting for a third app to get ready in order to sync the release with that one.
If I see any kind of problems when they go live on the App Store, I will of course update this answer.
Update:
The two apps were released successfully more than three weeks ago. The roll-out worked as expected and I have not received any user complaints.
In summary, the answer is YES, this is completely safe!
Apple published a new tech note on February 12th 2014 confirming that it's possible (and safe*) to change Prefixes yourself for Wildcard App IDs, but it's still impossible to do it yourself for Explicit App IDs.
However, they say you can contact member center maintainers if you would like them to change your Prefixes for Explicit App IDs.
Gonna include this part here in case they change their mind again:
All other App IDs will require the assistance of the member center maintainers - if you are not using a wildcard App ID, then you should contact the iOS member center maintainers for assistance. Here are the steps you can use to do that:
Go to https://developer.apple.com/contact/.
Submit a request by clicking the link under Enrollment and Account.
* Keep in mind that if your app stores data in Keychain, changing app ID prefix will result in one-time Keychain data loss.
I have been excited to try to add for the FIRST time a new App on iTunes Connect to TEST my GAMEKIT features.
I have read this technical note and I am getting confused because I had already a boundle id for my App that I created when I started developing it (that's my current bundle id with which I created the current provisioning and testing profiles: hello-*).
In order to use GameKit and InApp Purchase should I create a new Bundle Id?
I am confused because:
I don't know if the current Bundle Id is valid (in respect to the technical note linked above)
I don't know if hte Bundle Id influences the things that I can ADD in the App later (E.g. in App Purchase, GameKit, ...)
If I create a new App with a name (say: HelloApple) but with a bundle Id with wildcard (Say: hello-*) will I be able to add a new App with the same name but a different bundle Id in a later stage? This indeed before publishing ANY of the two Apps.
I don't fully understand why there is a choice between using or not using a wildcard; in other words, if a non wildcard bundle id is needed to use in App purchase and GameKit why should a developer want to use a wildcard App Id?
Any help will be appreciated, in particular I need to solve my first issue: which bundle Id should I use in ordert to use GameKit and InAppPurchase?
Before answering your questions some definitions:
Bundle ID: A reverse DNS string that precisely identifies a single app.
Bundle ID search string: it is used to match a set of bundle IDs, where each bundle ID identifies a single app. For example, if the bundle ID search string is com.mycompany.MyApp or a wildcard such as com.mycompany.*, then it will match the bundle ID com.mycompany.MyApp.
App ID: A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team. In the technical note that you link it is ABCDE12345 and called the Bundle Seed ID.
(Development) Provisioning Profile: you use it to authorize your app to launch on devices and use certain store technologies when you are in development. It is comprised of: a single App ID, a set of devices, and a set of development certificates. The provisioning profiles are created in Member Center and you need them on your device to run your app. XCode can download provisioning profiles and install them onto devices.
Now I will answer to your bullets:
To use Game-Center (GameKit) and IAP you need an explicit App ID, that is and App ID with a bundle ID search string that has no *. A wild-card App ID is one in which the bundle ID search string that has a *, and is the one you have now.
What you create initially is an App ID with an associated Bundle ID. If it is explicit you can add Game-Center and IAP, if it is a wildcard App ID not... that's it.
You can not have two apps with different names but the same explicit App ID or Bundle ID. But you can have two apps with different names that do not use Game-Center or IAP with a unique App ID using a wildcard App ID.
You ask why the wildcard is useful... Well, I said that if you do not use Game-Center or IAP you can have two or more apps associated to an wildcard App ID. Then you can create a provisioning profile with this App ID and you only need to install this provisioning profile on your devices for all your apps. There is a default provisioning profile of this type called the Team Provisioning Profile which is valid for all your apps, but you could create more specific ones that are valid for a subset of all you apps.
This process is really useful for big teams. If you have a small team and few apps it is really confusing, but it helps to understand the reasoning behind it.
But there is more to say about all this. I recommend that you read the "App Distribution Guide" as I did recently. It is an extensive guide, but for the moment you only need to read sections of topic "Maintaining Your Signing Identities and Certificates" and "Maintaining Identifiers, Devices, and Profiles". The guide is very clear, full of screenshots and it will answer all your questions. Also you can go back to the guide down the road to quickly solve some issue (and you will have issues).
The first time that I created an App with Game-Center and IAP more than a year ago I looked up stackoverflow to answer all my questions. But I've been having issues when certificates expired, when I added new devices, etc, and every time I found and Ad-hoc solution after a lot of fiddling around and going back to stackoverflow. Don't get me wrong, there are great answers in stackoverflow but it is a much better strategy in my experience to read something longer that explains the big picture. App ID, Bundle ID's, Certificates, private keys, etc, is a messy subject, specially if you do not understand why it is built this way.
The bundle id is just an identifier for your app. It's mainly used to provide you with the certificates you need to use to sign your app before submitting to the App Store or to use it on development devices (e.g. for testing). The bundle id can be whatever you want. Apple recommends using the syntax com.yourcompany.yourapp to keep it consistent among apps you develop and avoid conflicts with other app's identifiers.
A wildcard can be used on all your apps, while a specific id can be used with one app only. I advice you to have an id for each of your app and only a wildcard for development (so you can run on your devices as many apps as you want without having to bother about the certificates until you decide to ship the app). You don't need to have access to all services (like Game Center or iCloud) on all your apps and therefore you better sign the single certificates just with the services your app needs.
What I think Apple wants is:
Create a different bundle ID for each app that uses in-App purchase/GameKit or both.
You can have same App-ID, and bundle ID for apps that do not use these.
If the bundleID you have for your app is not used for any other of your apps, you can use it.
Somebody more knowledgable, Please correct me if I am wrong.
So I took over an existing iOS app from a client, that is currently available for public use through the App Store. When I was given the project in xcode, I noticed that all provisioning profiles associated with the app had expired and all were under the name of the previous developer.
So, I added myself as a developer and joined the team and code signed the development copy under my credentials. I created a new ad hoc provisioning profile for testing, and released a version through TestFlight to some registered devices. No problems. The app is greenlighted to go live.
Can someone please help me out with the release process from this point on? Do I create a third new provisioning profile for App Store release, and tie it to the code signing in XCode? Is this going to be problematic considering the version that is live now is under completely different (expired) profiles from a different developer? Is there some alternative way I need to do it through Apple? I'm trying to be super cautious here... if for some reason I release the app and its crashing because of some step I didnt take by accident, the poop will hit the fan.
You're going to have to release it under a new name on the App Store and forfeit all the ratings and reviews. Apple won't let you swap developer profiles on an existing app.
Other developers may disagree, but it looks like a huge PITA. See here
Transferring ownership of an iPhone app on the app store
The official answer seems to be NO
I didn't interpret the question as regarding change of ownership of an app.
I read the question as: I've inherited maintenance of an app and we'll want to submit an update as the same seller.
In this case, you can generate your own certificates and distribution profiles, and you can then build and submit the app.
I have done this numerous times. That is, I have inherited responsibility for an app that I did not necessarily craft originally. I easily created new signing and provisioning credentials, appropriate for the app the be submitted as the seller (not me) on their behalf.
And for what it's worth, the App Store Distribution profile is necessary, but only used when the app is submitted, so Apple can ensure that it is coming from a developer that has the right to submit it. (Remember, these profiles are signed with the same certificates used to sign your app package.) If that Distribution profile should expire or change, it has no bearing on an app already in the App Store.