Enterprise-signed iOS apps on unmanaged devices is a pain. How should we proceed?
It’s worth it to see if you can make the alternatives (public distribution or avoiding BYOD) work instead for your enterprise apps for iOS.
Deploying enterprise-signed apps to unmanaged devices is a topic that comes up sometimes from my customers. People have read that they can self-sign apps, they have an enthusiastic development team, and now with major EMM platforms able to push apps to unmanaged devices, IT teams are more eager to give it a go.
In many cases, the need to distribute private enterprise apps for iOS on unmanaged devices comes from having apps specific to your business, and either a BYOD program that doesn’t require EMM enrollment, or the use of contractors who need your app, but can’t subject their devices to your corporate controls for whatever reason.
So, what’s involved?
The basics of signing iOS apps
Firstly, the developing organization needs to join the Apple Developer Enterprise Program (ADEP), as iOS devices will only install signed, trusted apps.
If you’re not familiar with this process, joining the ADEP, like many Apple programs, requires a D-U-N-S number and proof of identity; the cost is $299 per year. Once signed up, roles (which comprise agent, member, and administrator) need to be assigned to the development team. Once a signing identity has been established, Xcode will use this to sign the app when it is being built.
There are actually quite a few certificates involved. Some are installed as part of the Xcode installation, for example, but app developers should be on top of this. Members will need to create APNS SSL certificates, and distribution certificates will need to be created by someone with agent or admin roles.
How the app is signed will determine how it can be deployed, and without a distribution certificate, the app will only run in a testing sandbox. But once properly signed for distribution, a provisioning profile is assigned to the app, and you have your .ipa file ready to distribute.
Installing apps and trusting the developer
Prior to iOS 9, users were prompted to trust apps from enterprise stores during the installation process. Since its release in 2015, users now have to go through a few extra steps in order to install these apps, which aren’t necessarily intuitive for less technical users, as it involves going to the profile section of settings and trusting the developer.
If the app is pushed by MDM, then the management certificate already installed on the device establishes the trust, allowing users to skip this approval process. However, this is obviously not the case with unmanaged devices.
While this prevents the inadvertent installation of enterprise apps for iOS, it can slow down any rollout projects, or involve the use of support staff in a way that isn’t required when using the App Store. Writing up a document containing screenshots and step-by-step instructions in an imperative for any successful rollout. And let’s not forget that these steps will need to be followed every time the app is updated.
App Store Connect and Custom Apps for Business
Apple does offer its own solution to app distribution, by using App Store Connect to distribute custom apps for business (formerly known as the B2B program). This can use APNS functionality to distribute your apps without making them visible to the public, but requires the target business or educational organization to be signed up to either Apple Business Manager or Apple School Manager. In order to use this method, you’ll need the DEP account number or customer ID for each business you intend to distribute to.
But again, this becomes problematic with unmanaged BYOD users, or when an app needs to be distributed among several contractors who do not work for the same firm, as it requires devices to be enrolled in MDM. As such, I’ve yet to encounter any of my customers using this method in practice.
Why not use the Apple App Store instead?
My advice to anyone that needs to distribute enterprise apps for iOS is to seriously consider using the public App Store. You’ve already done all the legwork of developing and signing the app, so why not push it to the store that any iOS device can access? You can still push it to enrolled device with MDM if you need to, but also un-enrolled devices will have a much easier time installing it.
Privacy and security concerns are often touted, but the Apple will perform security checks against your app, and you can always add a nominal charge to dissuade curious store browsers. Combine this with building authentication into the app, and it becomes useless to anyone you haven’t supplied credentials to.
The $99 annual charge for hosting on the App Store is usually going to be far less than the cost of having your IT team explaining installation and trust instructions every time the app is updated. The only major risk is having your app rollout delayed if your app is rejected by Apple, or if you receive feedback that requires some re-work before acceptance.
A simpler alternative
If you absolutely cannot use the App Store, and have contractors that require your app, consider giving them the use of an MDM-enrolled device for the duration of their contract. Again, the upfront costs of device acquisition are probably offset by the time and effort saved in wrapping, distributing, and writing instructions for your enterprise app for iOS. Plus, you now get to streamline deployment using DEP/VPP, and can use the MDM certificate to trust the app. In this scenario you no longer risk your intellectual property ending up on a potentially jailbroken or infected device.
(Correction, January 28: This article was updated to reflect the distribution options for Custom Apps for Business.)
