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
Related
So I have a client who I’ve built this app for. The app had reached its MVP so we launched it and transferred the app to their developer account. Now I want to continue working on the app for them but I don’t have the proper certificate on my device to make changes to the project on the clients developer account. How do I go about getting the proper certificates set up so I can upload new app versions of the app to their App Store Connect account?
There is two solutions I can think of :
They can add your Apple developer account into their new developer account and give you the developer access (or admin access to have a bigger freedom). Therefore you will be able to recreate certificates for you in order to work on your project. (for me this is the best approach and it keep things clean). To do so, just ask one of the admin of the itunesconnect account on your client side, and he will add you as a Developer Manager in the account.
you can ask them to export their new certificates as a .p12 file (which contain the private and public keys) and their provisioning profile from their Mac OS key chain (the developer or team from your client that is handling the app nowadays if any). Then you will have no issue at all. (I do not recommend this one and vouch for the first one even if second one seems easy). Also if tomorrow they changed it or revoke it will require to do again the same update..
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.
A few years ago I wrote an iPad app that was to run on only a few of the client's iPads. They're currently having issues with the app exiting upon being opened. It turns out this is due to the dev provisioning profile associated with the app being expired.
I tried renewing the provisioning profile but am unable to access the Provisioning Portal because my dev account needs to be renewed. Renewing my account is not an option right now.
I'm aware that as of Xcode 8 users are able to install apps on physical devices for free. I don't have access to the client's iPads and have been issuing out updates by archiving the .ipa file and using diawi.com for them to install.
How can I just renew my provisioning profile so that my client can successfully open the app?
Thanks
This is not possible. What you need to do is generate a new, valid provisioning profile and run the app again on your client's iPad. However, I should note that for this type of development, Apple wants you to use ad-hoc distribution through the enterprise developer program.
Also, to be able to generate a new, valid provisioning profile you will need a valid account.
Ideally, your client should have their own developer account that they maintain, preferably an enterprise dev account (enterprise accounts don't require them to manage the specific device UDIDs the app needs to run on). With that, they could manage their own certs / profiles for the signing of the app. They could then grant you access as a team member to manage those things and update the app once a year.
Or, even better for them - you could even write them a script / use tools (like fastlane) to re-sign the app themselves so they could self provision. This takes you out of the loop for ongoing support, since it doesn't seem like you will / have provided ongoing support. Keeping an internal app running requires continual work (new OS updates, code signing expiration, etc.).
If you built an app for a client, you probably should have known / let them know that iOS doesn't allow unsigned apps to run on devices, and that developer provisioning profiles last at most a year. You also need to make sure they know you can't just write a native app and expect it to work forever. At some point (probably now, but they don't know it yet) an iOS update is going to break something you did in the app. The just can't see what is broken yet because your invalid cert is making it so the app can't launch. Given your lack of understanding of iOS code signing, I would assume that you likely did something in your code that was broken in subsequent iOS updates (given that very experienced iOS developers also have things break with new iOS versions are released).
At this point, I would explain them the situation and see if they would be willing to set up their own paid account (only $299 / year for an enterprise account) to get new profiles / certs set up to get the app back up and running.
EDIT: see conclusion at the end of this post.
First off, let me clarify I've found a few similar questions/answers on SO, but none that apply to my particular situation. The one that came closest is this one but it doesn't address the AirWatch aspect.
So I'll try to be very specific.
Background
I have an iOS application that's free. I also have the same app for Android and Windows 10 but those are not my concern.
The iOS app is available to anyone from the App store. But I have a few large corporate customers who use AirWatch to manage the installation/update cycle of their devices. They either have Enterprise or VPP Apple accounts. They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
In my mind, that's a perfectly legitimate request: they just want to have better control over what gets installed on their devices.
Problem
From what I understand, an Enterprise account requires that the application be signed with the customer's certificate. But if I have several such customers, that means I have to re-sign each application for each customer, every time I have a new update available. And those customers that have VPP accounts cannot use them because the VPP program only applies to paid apps, not to free ones.
Note: keep in mind that at that stage when I'm ready to provide the app to these customers, the app has already been reviewed and accepted by the App Store. So it's deemed legit.
After googling this matter for a while, I know it's possible for someone else to resign an app or to sign it for the first time if it is provided in unsigned form to start with. However, resigned apps are apparently not supported by AirWatch (and, I assume, other MDM's as well).
If that information is incorrect, then I guess all I would need to know is the recipe that I, as a coder, have to follow before providing the app to my customers and what kind of steps they have to take in order to deploy using AirWatch.
Question
So how do I get my free app to my customers so they can manage the distribution themselves, without me having to go through yet another set of hassles every time I change something.
Remember: if I only had a single corporate customer I wouldn't give it a second thought and I would just use their own certificates but I have several potential customers with the same requirements, so the point is to make it easy for all of them and for myself.
I hope my question was clear enough, thanks in advance for any help.
EDIT - Conclusion: I was able to validate that an unsigned IPA file can be signed with the customer's certificate and uploaded to their AirWatch distribution app. Which means I simply have to provide the unsigned version to any customer with the same issue and they will be able to distribute the app themselves with their MDM. Hope this information helps others.
If your customers really can't re-sign your IPA, I believe the best solution for you to do would be to sign up yourself for an enterprise account, then use your own enterprise provisioning profile to sign a single ipa for distribution to the companies that need the app. Their MDM platforms should be able to handle the "trusting" of your enterprise signing identity, so the experience for the end users would be no different than if they were installing and running one signed by their own enterprise account.
The downside of this is that you will then be on the hook for providing your customers new versions when your cert of profile is about to expire. If you have them re-sign your IPA, it would be their responsibility to keep track of that and resign / redistribute a new provisioning profile when they expire.
Also, I have never heard of any restrictions on MDM's distributing re-signed IPAs. I don't even understand how they could prevent it, as a properly re-signed IPA should look no different than an IPA that was build and signed using the new signing identity and profile. I would challenge that, as many MAM (Mobile App Management) vendors offer wrapping of apps that do re-sign the binaries and allow you to distribute those resigned IPAs through MDM systems. I would really expect any corporation with Airwatch to know how to resign an IPA using something like iReSign. That really is your easiest option. Build an IPA for each release, send it out to all your clients, and each can re-sign it with their own signing identity. That way if you stop doing development, they aren't reliant on your signing identity and profile to keep the application running.
because the VPP program only applies to paid apps, not to free ones.
You can manage free apps with VPP. It's maybe free but it's still a license. VPP manages licenses for an organization and allows admins to give and tack back these licenses.
I have right now free Apps in my AirWatch Console, in the tab "Purchased". This tab is only available if VPP is configured and displays only apps from the VPP. I can't go check in the VPP myself because I don't have any access but theses free apps wouldn't be in the tab "Purchased" if they weren't bought with the VPP.
They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
If you are ready to do that, your customers can upload the ipa file as an internal application and then deploy it to their iOS devices. As AirWatch customers, they should have access to the document VMware AirWatch Mobile Application Management (MAM) Guide with the Chatper 4 "Internal Applications". There is a particular process for iOS apps described.
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.