We have different enterprise applications distributed via Airwatch MDM. When some distribution profile was expiring after 1 year earlier we could see a popup on the iOS devices. Now its not showing due to some reason. I'm not sure why. Also I can't find the profiles section in the iOS 8 settings section. There it used to show the expiration dates for all the profiles.
If the developer is not noticing the expiration date, apps getting crashed after the expiration date.
I want to know the best optimum solution for this.
How do we get the notifications for this?
Is there any solution without redistributing a new binary?
Or do we have any reminder notification system for this?
You can update the provisioning profile without redistributing a new binary. If you go to the app and click on the "files" tab and select "edit" this will allow you to upload the new profile.
I'm going to tackle your questions with in-line answers:
If the developer is not noticing the expiration date, apps getting crashed after the expiration date.
Speaking frankly it's up to your Enterprise Agent to maintain and track when provisioning profiles are expiring. Likewise they should be planning your required yearly release in conjuncion with the expiring profile. It is not the developer's job to maintain that part of the app development process unless you're specifically paying them to do so.
How do we get the notifications for this?
See above. All profile expiration dates are in your Enterprise Portal.
Is there any solution without redistributing a new binary?
This won't always work, especially if your Enterprise Distribution cert is also expiring. If your Enterprise Cert expires you MUST deploy a newly signed binary.
Related
I support a handful of enterprise iOS apps that are distributed using AirWatch MDM. Initially, the first couple of apps were distributed all sharing the same wildcard provisioning profile.
We recently rolled out a series of apps that used the App Group capability which could not use the wildcard profile so each app created its own provisioning profile.
We have run into a couple of issues with these new apps now that the profiles are expiring. Trying to distribute the new profile via AirWatch has been unsuccessful and the only thing that has a worked for us is to deploy a new app update. I worry this approach is not really sustainable as some of these apps likely will not be updated within a year or 2 of profile updates.
I have a couple of questions from an Airwatch/MDM consulting perspective:
Is it best practice to have each app in an enterprise format have its
own profile or share profiles if possible?
Is it possible to distribute a profile with capabilities remotely?
When the certificate expires, is there anyway to fix the apps without
updating every app across the enterprise using the expiring
certificate?
Can I revoke the active certificate that is used for internally published apps prior to the expiration date without impacting them?
From a certificate administration perspective, should we create a shared Apple ID with a generic login or tie it to one particular developer?
We have very few apps now but it has become a bit of a support issue each time these expiration dates roll around and I feel like there has to be a better way for an enterprise to manage this that has hundreds of internal apps.
Is it best practice to have each app in an enterprise format have its
own profile or share profiles if possible?
Yes. I always use a specific provisioning profile for every app I manage. Using wildcard may seem easier, and it takes more time to set up every single profile, but it's more manageable.
Is it possible to distribute a profile with capabilities remotely?
Yes, but distributing the new profile via Airwatch doesn't always work.
It's rather a problem of signing more than capabilities
If the new provisioning profile is signed with the same distribution certificate, pushing it via AirWatch may work. But sometimes it won't and the user will have to manually remove and reinstall the app.
If the new profile uses a new certificate the apps will NOT receive the update. Don't trust airwatch's information about app expiration in the apps list!
My advice is to create a new version of the app and sign the IPA with the new provisioning profile, then release it as an update.
And additional advantage is that you'll keep track of who has the older version (which will stop working when the profile expires) while the new version will work just fine.
When the certificate expires, is there anyway to fix the apps without updating every app across the enterprise using the expiring certificate?
No, I usually increase the version number, create a new IPA, re-generate the provisioning prodile, use it to sign the IPA, and distribute the app as an update using AirWatch.
Can I revoke the active certificate that is used for internally published apps prior to the expiration date without impacting them?
No, if you revoke a certificate every app that uses it will stop working.
Source: https://help.apple.com/developer-account/#/dev7d381a7ff
See Apple documentation on managing expired certificates, it's long but exaustive.
From a certificate administration perspective, should we create a shared Apple ID with a generic login or tie it to one particular developer?
Use roles. The team Agent is the admin of the account and is used only when you have to accept new TOS, renew the membership, etc.
Set up developer accounts (I prefer one for each developer, so that everyone has it's own developer certificate) and make the team leader admin of the develoepr account.
This way the team leader can set up the apps for the deploy while the developer will focus on coding.
I understand it may seem complex, but once you get used to this structure you'll appreciate how manageable it is, and usually the team leader can manage many developer accounts with little work.
Supporting your mobile apps, releasing updates to follow new iOS releases and bug-fixing are time-consuming activity. And so is maintaining certificates and deploying apps. You should charge your customer for these services too, if you make B2B
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.
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.()
We have an iOS "In-House" app (distributed OTA) with a Distribution Provisioning Profile that, as you may know, expires in 1 year. We have gone through upgrading the profile and distribution pains last year, so we are familiar with the process of distributing the app with a new profile, but I want to ask some questions just for clarity. (We are currently 29 days away from expiration, so users are getting notified)
Last year we thought that creating a NEW distribution provisioning profile with the same name as the expiring profile would overwrite the expiring profile. We were incorrect, it does not, and the device wound up with 2 profiles of the same name. Since you cannot overwrite an old profile, the problem from a maintenance and help desk perspective is that when you distribute the app with the new profile, users (hundreds in our case) still get notified that "The provisioning profile will expire in x days" even after they've upgraded the app that includes a new profile.
As you can imagine, that is confusing to users and frustrating for higher ups in the tech department. As I understand it, you're left with two ways to deal with having an unneeded expiring provisioning profile on the device(neither of which is a good user experience). Either:
Tell the users to ignore the message that their profile is expiring (I believe the expiring profile notification comes at 29 days, 15 days, and every day starting at 7 days...though not positive) and have them upgrade the app with the new profile.
or
Once the users have upgraded the app with the new profile, have them manually delete the expiring profile in Settings > Profiles. UGH!
Is there any workaround for how to remove the expiring profile aside from walking the individual user through the process? Are we missing something?
I don't want to revoke the cert that is contained in the expiring profile because that will present more problems - i.e. app not working for users who don't upgrade.
Simply put, we would just like to have a process that forestalls the expiration alerts so a user never sees them.
I received a recent response direct from Apple regarding the effect an expired profile has on apps currently residing in the app store:
I understand you'd like to know if you need to delete the expired
certificates and provisioning profiles, and whether or not any action
taken in the provisioning portal will affect apps currently live on
the App Store. I'm happy to assist you in this matter.
Please know that it is not necessary to delete expired items in the
provisioning portal, nor will any action taken have any impact on apps
currently live in the store.
Not quite sure this answers your entire question but it did help me when I was wondering what would happen to the live apps.
If i understand your question correctly, i had the same exact problem this year.
I Actually had to wait until the Profile Expired before i was able to Renew it.
When the profile had Expired, i would go to the Developer Portal's Provisioning Profiles, and on the right side of the Profile, there would now be a new button next to the Edit Button called Re-new.
Clicking Re-new should renew the current profile.
When the profile was renewed, my team would joust Install the updated profile.
(I sent the updated profile by mail, by downloading the profile(s) from the Provisioning Profiles page)
If that option for some reason would not work, you could alternatively create a new Provisioning Profile, with the same App ID and email it to you'r team.
If you make your app part of the app store they will not expire. You can charge a lot for it and give out redeem codes to your clients or make it free and do some kind to authorization.
I was working with a enterprise customer that had a private distribution to iPads. The iPads were not regality connected a computer to sync apps, but 1 day a year after the provisioning file was made all the remotes sales team lost access to the app. The app was a 1.6 gb download. So that only happened once and the app when to the store as a free app.
I have developed an iPad app very specific to my needs, it is tailored just for me and therefore isn't applicable to be submitted to the app store. Every few months I can't get into my app because the provisioning profile has expired.
Is there an easy way (besides jailbreaking the device, or submitted it to Apple) that I can use the app indefinitely without having to generate a new provisioning profile every few months?
Ad Hoc profiles seem to have a long lifetime. So instead using a Dev Profile, an Ad Hoc profile might serve your needs better. My latest Ad Hoc profile created in May expires together with my current certificate next year.
Nope. Provisioning is working exactly as it's designed to work in this case.