The company i work for have a few iOS apps distributed through the Enterprise program. We dont update these apps very frequently. So making sure that the certificates and provisioning profiles dont expire until we've had the chance to renew and redistribute the apps can be easy to forget. How does your team ensure this doesn't happen?
-
Your Certificate or, Provisioning Profiles will expire in an year from its creation date, you can't keep it alive. Though within team you can manage one thing keep the original `CertificateSigningRequest.certSigningRequest` file using which the key was generated, so that after the Certificate expires, you use the same file, so that all of you don't have to create new Private Keys. And even if you loose the file, you can regenerate from Private Key and use to create new Certificate. – iphonic Jun 02 '15 at 12:01
-
Yes, but how do make sure that you don't end up in a situation where the certificate expires before you've created a new one and distributed an updated version of the app with the new certificate? Calendar reminders? Check manually on a regular basis? some other system? – Trj Jun 02 '15 at 12:27
1 Answers
There's really not much you can do to prevent this, other than trying to keep all your apps being created with the same certificate / profiles, as up to date as possible. I have yet to find a good automated solution.
To manage it, I think the best solution is to create a reminder each time you generate a new certificate that will remind you in 11.5 months to renew the certificate (using the original cert signing request file). Then generate your certificate and new provisioning profile to be distributed to the developers (either by hand or by having them all signed into their Apple developer accounts as team members).
Once you have your new certificate and profiles, you'll need to regenerate the IPAs through xCode, or simply re-sign the ipa using the instructions found here: https://stackoverflow.com/a/25656455/3708242
For our internal apps using our enterprise distribution profile, we have put in self-update logic that allows us to push updates so that the users won't end up with an app that won't launch due to an expired provisioning profile or certificate.
Although I know many developer frown upon the use of wildcard ids in provisioning profiles, they do have one advantage here. If you have one app that is on all the devices, you could potentially get by with only updating that one app, as long as the new app has a provisioning profile and certificate that are not expired, and the provisioning profile has a wildcard id that matches all the internal apps you have. Once the valid profile is on the device, it will allow older apps to run. For more details about what I am talking about, see this answer: https://stackoverflow.com/a/29121777/3708242