I am part of a development team with many apps spanning multiple business units and iOS teams. We are having a lot of trouble right now managing distribution certificates. Apple lets you have 3 distrution certificates on one development account, but there is no way to name the certificates uniquely, so they all look the same. The only identifying information on the different certificates is the date on which it was generated.
Apple, why can't we rename these distribution certificates so that we can manage them better???
We need the ability to allow multiple build boxes to archive and submit to iTunesConnect for TestFlight or App Store releases.
We are finding ourselves accidentally revoking each other's distribution certificates all of the time, and even worse making it impossible for beta users to install from TestFlight if the certificate has been revoked.
Apple, why do you disallow installation of TestFlight builds if the "developer's certificate is no longer valid"??? This is crazy. You don't do this when an app has been published in the App Store. Why should TestFlight be any different??? Why punish beta users because the developers have accidentallly revoked a certificate???
We also think that it is Xcode's "Reset" or "Fix it" buttons that are doing the certificate revoking and causing so much trouble.
So how are other large development organizations handling this better? We've got a big team, but not nearly as big as many others that are out there.
We've tried assigning different dev teams a certificate generated on a particular date and asking them to only use that date and never revoke anyone elses' certificate. We've also tried exporting certificates from a single box. But it seams that no matter what we do something happens that causes the certificates to become revoked. It seems that Xcode itself is causing this.
Have you ever tried fastlane
https://fastlane.tools/
also you can try match (one of the tools in fastlane) that could help you to sync with all your devs the certificates
https://github.com/fastlane/match
also with fastlane tools you can automatically submit to appstore and testflight ipas
HTH
We adopted the following approach and have been conflict free for a few months now! We first removed the 'admin' role from most of our development team members so that they couldn't so easily revoke certificates by clicking on a 'fix' button. Then we generated a single distribution certificate that we share amongst the team. We also encourage builds being made on a shared build box when possible.
Related
We have multiple applications custom build for specific clients. Each application has its own "Enterprise" Distribution Certificate "iOS UniversalDistribution". Today we received word that all our client's applications have stopped working, they won't even open. At first we thought it was a bug after an update, but we noticed that our Provisioning profiles have expired. We did not receive any warnings, notifications, emails, ... they all just stopped working.
The applications are able to update themselves with a custom service we've build. Now that they won't open on the devices we fear we have to manually install the new versions on the devices?
But this means that in the future this WILL happen again. After researching the apple documentation something is still not clear. If we build a new version of the application (.IPA file) and we push the updates in the app, will the application also update all the certificates accordingly? So if we do an update several weeks before with renewed provisioning profiles will it prevent this from happening again?
Thanks in advance for the feedback.
So, unfortunately, none of the existing deployed apps will run now, so you will not be able to use the self-updating logic in the app to correct this. This is up to the developers to keep track of expiring profiles and certificates and ensure they get updated as needed.
All of the information below assumes you are using an Enterprise Distribution Profile to build these iOS apps.
You should note is that there are two things that can expire: the provisioning profile and the certificate.
Expiring Provisioning Profile:
Typically the provisioning profile expiring is easier to deal with, as you only need to get a new profile on the device. Technically, doing a new build with a new provisioning profile will do this, but there are other ways. For example, if these are managed, company devices, you can typically use the MDM software to push a new profile to the devices, without requiring a new .ipa (app binary) to be installed on the device). Also, if you use wildcard app ids in your provisioning profile, installing another device with a newer provisioning profile will also work (although this is a bit unorthodox). Long story, short: You need to get the new profile on the device. At this point, that is likely through you informing users they need to go re-download a new version of the app.
Expiring Certificate
If the certificate used to code sign the application is expiring, you will need to generate a new binary with the new certificate. There are ways to resign an existing ipa, but if you have the source code, it is easier to just re-build with the new certificate. The good news is that the certificate only expires every 3 years for an enterprise distribution certificate (vs. every 1 year for the provisioning profile). So this is not needed as often. But this will certainly require you to re-create a new binary signed with the new certificate.
Preventing This From Recurring
If you rely on the app to check for updates and self update, you need to make sure a new version gets published well enough in advance that users will launch the app in the time between the new version being released, and the profile or cert expiration. This length of time depends on your app. If it's a corporate app that people use daily, you can probably get by with 2 or 3 weeks (for people who are out of the office). If it's seldom used, I would consider deploying a new version, with a new provisioning profile at least 3-6 months in advance of the old one expiring. This takes planning and reminders to ensure you don't miss the timing window.
Also of note, if you are using automatic code signing, you lose some control over when a new profile is generated and used, as well as the certificates. That's why I recommend for enterprise apps to use manual code signing settings to allow you to be very explicit with which provisioning profiles are used, as well as the cert. Also, delete all older profiles from the Mac when doing a build to ensure you are using the right profile (you can have many profiles on the Mac for the same application at any given time. You can find them here: https://stackoverflow.com/a/45642752/3708242). It's risky to assume Xcode will pick the most recent one.
I am enrolled in the Apple Developer Program as an Organization.
As you know you are only allowed to create a maximum of 2 development
certificates and 2 distribution certificates.
Problem:
I have 3 developers working on the App. So, they keep deleting each others certificate to be able to create provisioning profiles. Some time it gets messy and they delete push notification certificate and then we had to regenerate the certificates to create pem files and upload it to server again cause server stops sending notifications successfully.
How can I manage this in a clean way?
I tried to invite them and add them as developers in apple member center. that didn't work cause developer can't do anything. But, with admin role they still see each other certificates. but at least they can create more than 2 certificates.
And I added them as admins in the iTunes connect too. not doing this caused a problem. but I am not sure. they not been able to upload a version from their Xcode with their accounts cause its like they don't have permission for upload. "upload fails after they pick the team and provisioning profile with their account".
Anything wrong with what I said? Is that how apple wants us to handle it? or there is another way?
No magic trick here. You cannot have more than 2 Distribution certificates and your developer will have to manually share those and the associated private keys. I believe this is legacy as a while ago only the Team Agent was authorized to manage the Distribution certificate.
Have a look at tools like https://github.com/fastlane/match which automates the sharing process and solved the issue for my agency.
Nicolas
I have managed to get my Development and Distribution certificates in something of a mess (started with separate one for each App and more)
I'd like to start again with just one, generic, cert for each of Development and Distribution.
There are lots of tutorials on re-creating deleted or expired certificates but I can't find any confirmation that I can delete everything and start afresh (and, presumably, then use the new cert for new apps and/or updates to old ones?)
Has anyone actually gone through the steps of cancelling/deleting all Apple certificates and starting again? If so, any advice on steps and things to avoid will be appreciated.
thanks
Many thanks for the suggestions which I have now implemented.
I do now have just one each Development and Distribution certificate (although Xcode re-created the dozens of provisioning profiles I was trying to get rid of - I guess I will have to live with that long list for ever...).
An interesting result is the error message I received when I uploaded a new version of an App:
"Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['xxxxxxxxx.com.jeffmaynard.eurosceptic'] and the new version of software being submitted has an application-identifier of ['yyyyyyyyyy.com.jeffmaynard.eurosceptic']. This will result in a loss of keychain access."
Although the App has gone to review I am not sure of the consequences of this error message which I assume results from the certificate updates?
You have to clear your certificates in 2 places:
Keychain
Follow these steps to navigate and clear the certificates:
Open LaunchPad
Keychain Access
Select your Keychain
Select My Certificates
Now here you need to delete every certificate that starts with iPhone Developer or iPhone Distribution
Apple Developers Members Center
Login to Apple Developers
Go to Member Center
Click: Manage your certificates, App IDs, devices, and provisioning profiles
You have 2 tabs to interact Certificates and Provisioning Profiles
Remove all of them (Remember you can't delete those Provisioning Profiles, that are already in App Store).
Then you need to create it from the beginning: Follow my answer here
I've recently taken over a project as a freelancer. I have during the development used my own account so I changed most of the debug/release/etc to my own "iPhone developer" etc in the project.
Now, however, it is time to send the update to the actual app store. I've gotten access to the last developers account, I've downloaded the distribution profiles which I assume I need.
The problem now is that, as far as I understand, I need the last developers ".developerprofile" for signing purposes. Or is there some other way? I can't seem to download it from the apple developer account.
This is the first time I am doing any kind of release so I am a bit shaky on the whole provisioning stuff as I've only developed locally and for that xcode manages everything perfectly so far.
If you can you need to get the P12 file from the previous developer - stack overflow
You actually do not need the previous developer's certificate or provisioning profiles in order to continue the project on your own.
It's relatively easy to revoke the previous developer's certificate and provisioning profiles (via the Apple Developer Portal) and recreate new ones on your machine.
Once you log into http://developer.apple.com/ios, look for the "Certificates, Identifiers & Profiles" section.
There is a lot of information about iOS distribution. I think I understand the different distriubution models, but I am looking for best practice for distributing an app to a client.
I have a client who has an Enterprise developer account and uses AirWatch for MDM. Here is how I am going to recommend to them that we distribute the app to their organization since they have no one technical on staff that has any experience with Xcode or iOS development and they will not be given access to the source code:
Add me as a member of their developer account
I build the app using their certificate
I give them the .ipa and plist file to distribute either through MDM or website.
Is this the correct way to do this? What if I am going to sell this same app to three clients - would I do it a different way? Is there anything else that needs to be done to distribute through AirWatch?
Again, looking for best practice and how others are handling this situation. Please clarify if I have anything wrong.
UPDATE: Thank you all for the answers. From what I have learned how this is done depends directly on how the client wants to handle the situation. In the end the client added me as an admin on their account (we have worked together quite a bit). I was able to create the distribution profile, build, and deploy the app to them. Not all clients will do this for security reasons. In that case, they will need to provide you will a cert as stated below, or you will need to build the app on one of their machines as Buckeye said below...or go through Apple to distribute the app to them.
Feel free to correct any of this info if it is incorrect. I really think this is helpful information for a lot devs.
I am accepting Patrick's answer because it is the closest to what I actually did.
There are two ways you can do this, but for both you must be added as a member of your client's developer team. Once you have done this, you (or more likely your client) will choose weather to use their in-house certificate or your own distribution certificate that you will manage.
It can be done either way, it is only a matter of who will have authority in the future to submit apps with the same certificate under the same account. That authority resides in the possession of the associated key pair of the certificate. If you are added to the client's dev team and download their distribution certificate, you will NOT have this key and cannot sign distribution builds with associated provisioning profiles.
Therefore, you must either get a .p12 export of the certificate (which contains the key) from the client to install on your machine so that you may sign with it. This will allow you to submit from your machine, but you are then in possession of your clien'ts private key, which they would like to protect. Your other option is to use your own Certificate Signing Request to create a Distribution Certificate on the client's developer account. In this situation, only you have control over the certificate and the client must create new ones if they wish to work with other developers in the future.
Once you have done that, here is an informative guide for enterprise distribution.
As an Enterprise Agent I will tell you that unless your client lives under a rock (technically speaking regarding the Apple dev portal) I doubt they're going to give up the private key and cert. If they have zero legal/contractual access to the source code you've created the only course of action, speaking from experience, would be for you to visit their facility with the source code, compile it on their box that houses the private key & enterprise distribution cert, build & deliver the IPA and finally take the source back with you. That is how I have compiled every build with a 3rd party vendor where we don't own the source and need to deploy internally.
On the flip side of this argument if the client is, for some wild reason, willing to give up the keys to their enterprise castle and export the private key & enterprise distribution cert for you to use... for YOUR sake I would get in writing what the scope of your usage is with that cert and somehow document the fact you have deleted the key & cert after the process is over. Don't open yourself up to liability because if they share it with you there's a chance they may also share it with someone else and as we all know, not all development entities play by the rules. You wouldn't want to get accused of creating some rogue app under their name.
Regarding re-signing the IPA file... AirWatch won't let you do it. AW interrogates the IPA when you upload it and it will note that the embedded provisioning profile doesn't match the re-signed IPA and tank. It becomes a chicken & egg situation where you need the provisioning profile on the device before you install the app however AirWatch won't let you deploy the app unless the aforementioned embedded profile is correct.
Also, #Caleb is correct regarding B2B but the pricing model goes from the project to per-seat (iOS device). In other words if your contract is "you can install this app on an unlimited number of devices" the B2B approach is going to blow up in everyone's faces.
EDIT:
Below are your options when editing a Development Provisioning Profile in an Enterprise iOS Account:
Obviously here you can pick & choose developers and their devices from within the portal that can compile to that profile.
Now here are your "options" for editing the Enterprise Provisioning Profile:
As you can see you don't get an option to edit which portal users or devices can use this profile because it's tied to the Agent's CSR/private key and is deployed globally.
You would need:
Their certificate.
Their provisioning profile.
It's a quite common practise to do this.
My question is, is this the correct way to do this?
Yes.
What if I am going to sell this same app to 3 clients, would I do it a different way?
No, you'll do the same thing. You'll need to build the app separately for each client using each client's distribution certificate.
Another option is to build the app and sell it to your clients using the B2B distribution mechanism.