Manually installing an iOS enterprise app without "Untrusted Developer" warning (inhouse distribution)

Question

As we all know, installing an inhouse signed iOS enterprise app manually on a device, will prompt the user to trust the Enterprise Developer before first use of the app.

However I'm currently looking into better options for iOS distribution scenarios where neither Public App Store, MDM nor connecting the device to a admin machine are options.

This documentation about the installation flow of appaloosa's enterprise app store seems to suggest that there is a flow where the user manually installs the iOS configuration profile first and then installs the IPA as usual in a second step. The screenshots in the documentation do not show any untrusted developer warning. I tried to reproduce the flow with a iOS configuration profile created in Apple Configurator 2 and signed with the inhouse distribution cert of the app I attempted to open afterwards. Unfortunately it would still bring up the warning for me, so either it is not possible or I missed something.

Question: Is it possible to get around the untrusted developer warning by manually installing an iOS configuration profile (e.g. including the inhouse distribution certificate) over the air beforehand? If yes, how does the configuration profile needs to be set up?

If this would be possible, it could improve UX for enterprise users by having a clean 2-step installation flow vs. a 1-step installation with a shady warning:

Known user flow           User flow in question

1) Go to website          1) Go to website
2) Download app           2) Download profile
3) Open --> warning       3) Accept profile install
4) Trust in settings      4) Download app
5) Open --> success       5) Open --> success

--> works, bad UX         --> is this possible???

Answer 1

There seems that there are only 2 ways of doing what you described:

1. What you actually wrote (manually trust developer)
2. What Appaloosa does, so actually using MDM solution

In the second case, accepting the profile (in their docs you see "Includes enrolment challenge") actually means that they will be remotely managing your device. While it makes sense in corporation for company devices, I would not be very eager to do it on my personal device.

If you want to explore MDM option (at least from UX perspective, to get look and feel), there are several services providing free trials. That will allow to verify, if the MDM solution is valid in your particular case.

What they (appaloosa) did not show, is that accepting this profile requires several confirmations (including alert about remote device management), which are alerting to the user more than once. Also, every installation of the app (for not supervised phone) triggers another alert where you have to agree.

So, in terms of UX only, I believe its a giant overhead with zero to none benefit :)

Answer 2

The process for in-house apps has indeed been made a little bit tricky by Apple with this "trust the developer" action, and is often source of confusion for non-technical users. The error message displayed by iOS is really not helping (could provide a button to open the Settings app on the right screen!) and the section in the Settings is not the easiest to find, nor does it explain clearly what it is for/how it works/...

The "other" process you describe exists in some way but is a bit more advanced than that: there is a way to trust the developer automatically and it comes with device management. It is actually not only installing an app, but also registering the device into an enterprise/MDM (Mobile Device Management) system. This makes the device managed, and therefore may provide some already trusted developers for inhouse deployment, as well as managed apps. To find more on this, you should look for "Device enrollment challenge" or "MDM enrolment for iOS"; Apple provides some extensive docs for it and some services implement it.

Please note that this is a very nice tool in a large corporate IT deployment context, device fleets, ... but absolutely not adapted to a less "internal" app deployment (ex: if you are an agency and want to provide apps to your clients, ... which in some way might break the Apple Enterprise agreement but that's another question). The enrolment process gives the provider a very high level of control on the device, and therefore there has to be a very high level of trust when doing it.

As soon as you are enrolled however, you can install apps without this additional step.