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.)

Dig Deeper on Apple iOS in the enterprise

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

We use B2B distribution for our apps. So do several other companies I know of that are in enterprise sales. It is not uncommon. Also the author is incorrect — DEP enrollment is not required to be a B2B customer. However MDM is required. Also there is another way to deploy enterprise apps easily: the app trust may be saved in an iOS backup. So if the app distribution method includes a backup restore then loads the app, the user sees no prompt. We have several customers using GroundControl with custom app and no MDM in this way, at large scale.
Lots of interesting stuff in there—we'll have a lot to talk about the next time we do a podcast. Thanks for commenting!
Thanks for the comment Aaron. I'd gone by the notes that Apple provided. Glad someone with hands-on experience in the scenario was in the audience. 
You cannot use public App store to distribute enterprise Apps. Apple will reject your App unless you App is applicable for non-employees in a bigger scale. 
Also you can use Apple Business Manager with redemption codes to distribute custom apps without MDM.
This is absolutely correct in that your app would technically no longer be classified as an enterprise app once published on the App Store, but plenty of applications require authentication to use, or for the user to be a customer before they can benefit from the app. It is possible to have apps uploaded to the app store, and while you risk 3rd parties downloading them, in-app authentication can prevent those users from accessing any of your content, and adding a cost to the app discourages casual downloads. If we consider apps like Salesforce 1, for example, while free to download, it is ultimately of limited use to anyone who doesn't have a login for the service. Or banking apps will require you to be a customer of the app before you can access information. Apple will not allow you to use the public app store to restrict access to the app itself, but you can limit access to your company information, as many apps do. Using Testflight is an option that many websites discuss, but I deliberately didn't include this in the article, as it requires a new version of the app to be uploaded every 90 days, and initial download isn't completely straightforward for some less technical users.