In House Enterprise App Distribution On Web Server

Question

Created Feb ’19

Replies 3

Boosts 0

Views 4.1k

Participants 2

I am looking for some information regarding how to appropriatley deploy an In House Enterprise App on a Web Server and still stay within apple developer license guidlines.

According to the XCode help guide on this issue, you can:

"Note: If you don’t distribute your app using a MDM system, users can install your app using the iOS App (IPA) file but then they will need to manually trust your organization to launch the app."

Continuing from that link, apple provides a nicehelp doc on how to "Distrubite in-house apps from a web server":

From my understanding, you can create a manifest.plist that contains a url to your .ipa file. From there, the user downloads the manifest and the device takes over to read the manifest and download the .ipa.

However, according to theApple Enterprise License Agreement, section 2.1:

"You may permit Your Permitted Entity to deploy Your Internal Use Applications to Permitted Users on Your behalf, provided that such deployment is at least as restrictive and protective of Apple as the terms of this Agreement (e.g., posting the App on a public website or non-authenticated server would be prohibited)."

Obviously, you can easily put the download to the manifest behind an authenticated web server; however if you try and put the .ipa file behind some form of authentication, the "internal mechanism" of the device that reads the manifest and downloads the .ipa doesn't know about any authentication method to your server and will be rejected, causing the install to fail.

It seems then, the .ipa download would have to be public, at least from the device's perspective.

What are the appropriate steps to deploy an internal app in this manner, while not being in direct conflict with the enterprise agreement?

Boost

Answer 1

guywithmazda OP

Feb ’19

When the .plist is requested, you could have your web server create a unique one-use token that is injected into the .ipa file's url in the plist, and saved in a database (this assumes that only logged-in users have access to the plist). Then, it watches the requests coming in, and when it sees a token in a url for the .ipa file, it checks the database for the token. If it finds the token in the database, it serves the .ipa file and removes the token from the database. Any request that comes in without a token, or with a token that is not in the database, is ignored.

0

Answer 2

camdeng14 OP

Mar ’19

We had considered generating the plist on the fly, generating a short lived public uri for the download. A short lived public uri, while secure, seems like it would violate Apples TOS (for a few minutes or so).

However, injecting a one time use access token to the uri on the fly seems like it would satisfy terms.

0

Answer 3

guywithmazda OP

Mar ’19

Note that iOS 7 sent both a HEAD request and GET request for the .ipa file. I don't know if newer versions of iOS still do that or not. So make sure you don't delete the token until the GET happens. Also, you could keep track of when the token was generated and consider it expired after a short time.

0