I have an enterprise app out in the field signed with a distribution certificate 3 years ago that is due to expire next month. Ideally I would like to not have to redeploy my app to my users and according to the apple docs Re-Creating Certificates and Updating Related Provisioning Profiles, it appears I can create a new dist cert, update my profile with the new cert and my app out in the field will not be effected. I have read some conflicting posts on the matter from a few years ago now admittedly that say I will need to re-deploy my enterprise app so was wondering would anyone be able to confirm for me what teh latest state of play is.
Any information would be greatly appreciated.
No, you don't need to redeploy an app if your bundler identifier is same.
You can revoke current certificate and create a new one. This action can result into 'stop' usage of app in mobile device (if or when it has connection to apple server). The reason for this is, user needs to accept/trust developer of new certificate from device's settings.
Once user accepts/trust new certificate, your app will continue working as it was.
You can ask me, if you still have any confusion or problem in understanding this scenario.
Recently, I practically tested this scenario for one of my enterprise app and it was successful.
Hope it would work for you also !!!
Related
So, my first App is on the AppStore for almost a year now. I started receiving notices from Apple that my iOS Distribution Certificate will expire in 30 days time. That's fine — they expire.
But, the email says to go to Certificates, Provisioning and Identities to renew — only there is nothing there that specifically guides me through such a process that I can see — and it's a very clean, spartan portal so I imagine I would see something especially if I was directed to go there specifically for this reason.
As I've never renewed a certificate, I wonder if anyone might be able to guide me through the process? There seems to be no clear answer.
My concern is that the expired certificate would somehow break the App currently in the store? (I don't know that it will, or will not — but I'm not excited to find out in real time.)
Am I meant to create a new certificate in Xcode? Does it need to be somehow applied to the current version of the App, or the one in the App Store, meaning I may need to publish a new version of the App for hygiene?
Any pointers or help are greatly appreciated.
Julian
If your Apple Developer Program membership is valid, your existing apps on the App Store will not be affected. However, you will no longer be able to upload new apps or updates signed with the expired or revoked certificate to the App Store.
https://developer.apple.com/support/certificates/
For updating the app you need to generate new certificate.
We are building iOS apps for distribution in our own internal App Store using an Enterprise Developer Account from Apple. For building, we need to generate a provisioning profile, which expires 12 months from the creation. After expiration, the app doesn't work on the devices (crashes immediately because of expired Provisioning Profile), and each device needs to reinstall a new build of the app.
How can we provide our users an user friendly workflow in which they do not have to cope with crashing apps after 12 months?
Thanks in advance,
Bas
The expiration of provisioning profiles is a hassle with enterprise distributed apps. And it is something that will require ongoing maintenance from your internal development team, mobile support teams.
First, I want to point out that you don't mention certificates. Because they only expire every 3 years now (as of this writing - originally they expired every year), developers often forget about them. However, their expiration is actually more troublesome than the profiles. When a profile expires, you simply need to get another valid profile on the device. This can be done in multiple ways. You can use an mobile device management (MDM) solution to push just a new profile. Or if another app with a valid profile (that uses a wildcard ID) has been pushed to the device more recently, this can also get a valid profile on the device.
If the certificate expires, you will actually need to re-build the app with the new certificate. Old builds signed with the expired cert will not run unless. Technically, you can resign the old IPA, but the main thing to note is that the actual binary is invalid and will not work until a new binary with a proper code signing is generated. Fortunately this is only every 3 years, so it is less frequent, but I can almost promise you when it happens you will have a mess on your hands if you don't plan for it. Again, as with the provisioning profile, you could handle this by using MDM to push something new to the device. In this case, you would use MDM to actually replace the while app, not just the profile. A little more work, but it could be done.
Of course, there are reasons you may not want to use MDM. Cost could be a concern. Employees may not want the company to manage their personal devices (if these apps are going on personal devices). Ability to manage the MDM infrastructure / workload. If MDM is not a great solution for your organization, I would recommend another approach that isn't as ideal from a user experience, but could solve your problem. You could built your apps to be self-updating. In other words, on launch, your app checks a server to see if a new version is available. If so, it prompts the user to update. This wouldn't require the device to be managed, and you could easily build a shared framework to make this easy for app developers. One downside to this approach is if the user doesn't launch the app between the time you post the new version (with new profile / cert) and the time the profile or cert expires, the app will not launch, so the auto-update functionality can't run to tell the user to get a new version. It will just appear to the user as if the app is crashing. That is the one UX problem with this approach. But if you can manage that, it can provide an alternative to the MDM route.
You can manage this with an MDM server. Essentially the workflow looks something like this:
User installs MDM Profile and Accepts the prompts to allow the MDM Server to install apps.
The MDM Server is able to manage the device according to the permissions set in the MDM Profile. Apps managed by the MDM Server can then be installed and removed arbitrarily.
A quick google search for iOS MDM Server should get you headed in the right direction. Pricing for various paid options is somewhere around $15 / device / year, last time I looked into this (about a year ago). But there are one or two reasonable open source MDM Servers available as well.
My previous attempt to get some help on this topic, failed, so I'm retrying again.
I've built my PhoneGap application without any problems until our Apple Development subscription expired (I guess, all the certificates expired as well).
While renewing our Apple dev program at our company, my boss made me a new account and added me as admin to the company.
I tried remaking the certificates, and while all my builds worked over at PhoneGap Build (means, that the certificates are valid), while trying to submit our app via the Application Loader, I get a binary error, and can't go any further.
Upon browsing the forums I've found out that this could be an issue with the certificates, so I came here to ask, what could be wrong with my setup.
I have to specify, that before this expiration happened, all our builds were submitted by using a Macbook, that is no longer available, so I can't access the old keychain information.
Also, another important information: while struggling with this issue, I remade all the certificates and profiles. (the App ID remains the same, since i don't need to change anything there)
Another note: our application supports push notifications, so I added that to the App ID, and created 2 certificates: Apple Development iOS Push Services and Apple Push Services. (I don't know if I need both, but I followed a tutorial, and it worked perfectly until the recent happenings)
We couldn't release our app for weeks now, which is a huge problem right now, so any help would be appreciated.
Recently, I had an experience of expiring profile & certificate and my all distributed apps were stopped running. So i want to go in depth of this logic. I have few question listed below. Anyone please answer because most iOS developers still don't know the answers.
Why apple is expiring certificates and profiles exact after one year ?
Can we extend the limit of expiration year from one year to any ?
How iOS decide, The particular app certificate is expired so it should not be run in the device ?
When installed app life is deciding by iOS i.e. When app is installed first time OR when Certificates and Profiles created ?
Most iOS developers are wondering for knowing the logic behind this certificate expiration process so please answer who knows the truth behind this.
Thanks in advance.
Why apple is expiring certificates and profiles exact after one year ?
So that you don't set up a parallel app store(IMO)
Can we extend the limit of expiration year from one year to any ?
For Enterprise licenses, 'in-house' distribution profiles have a validity of 3 years. Here is an old thread you may refer.
How iOS decide, The particular app certificate is expired so it should not be run in the device ?
From Apple docs: The first time an application is opened on a device, the distribution certificate is validated by contacting Apple’s OCSP server. Unless the certificate has been revoked, the app is allowed to run.
When installed app life is deciding by iOS i.e. When app is installed first time OR when Certificates and Profiles created ?
Same as above, certificate and PP expiry dates are taken in account before running the app. Try installing an app which was signed with old certificate and you'd see.()
I am updating in-house app for a client which they have a previous version currently on over 100+ iPads.
I want to push an update, but when i try to sign the app with the distribution provisioning profile it asks me for the private key. After searching, people suggested to revoke the old certificate and generate a new one on the machine i'm using so i can have the private key. I don't know if this is the best approach or not, but my client is concerned if I will be revoking the current In-House Distribution certificate, it will affect the applications which are currently distributed on those 100+ iPads? Thanks!
Unfortunately, yes. For enterprise distributed apps, the devices will regularly check with apples servers whether the certificate which has been used to sign them is still valid. So revoking the certificate will make those installations fail. Maybe not until the next reboot, maybe not when there is no internet connection available, but sooner or later, the app will refuse to launch.
If availability of the app must not be interrupted, you need to take precautions - for example by preparing the new version and notifying all users ahead of time that at a certain date, the old version will stop working and the new one must be installed.
Update:
I kept investigating and it appears like you can have two distribution certificates at the same time now. This is meant to eliminate gaps in app availability by allowing you to phase from one cert to another, way before the first one expires.
If this is still true, you might be able to simply create another distribution certificate without revoking the existing one. You will need to create new provisioning profiles as well (or update the old ones to use the new cert), but that shouldn't invalidate those already deployed. You would then be able to distribute the new / updated app and the existing installations will remain unaffected.
It has been some time since I last worked with enterprise distribution and right now, I don't have access to an enterprise dev account, so I can't try. But I don't think there is any risk if you just go ahead and try it - I assume the portal will either let you create a second cert or it just won't...
Toastor is correct - I recently had a discussion with Apple about this and it intentionally differs from App Store apps. When the distribution certificate is revoked (or expired) for an Enterprise app, the app stops working after expiration is reached, or revocation information is retrieved from Apple.
However if you manage several Enterprise apps, instead of requiring users to install a recompiled version of every single app with the new certificate, you may:
Push the new Provisioning Profile(s) to users over MDM (like Airwatch) **
Use a wildcard App ID for your apps and then as long as the user installs one app with the updated cert, it will apply to all apps that share that App ID
Allow users to download the updated Provisioning Profile without requiring an app install **
** CAVEAT: I don't code apps but do manage our certs, App IDs, and Provisioning Profiles. I haven't yet tested these approaches - it's my best effort based on notes from my recent discussion with Apple.