Select Page

This post is part four in a five-part series on MAM deployment models. For previous posts in the series, see: IntroductionPart II: Windows; Part III: Android.

They say to save the best for last, and while we’ll leave it up to you to decide which mobile platform is best for your needs, we can say one thing: enterprises hoping to execute an MAM deployment on iOS have quite a few options.

We’ll just get right into it. As it relates to MAM deployments on iOS, there are several different ways to manage and deploy apps, all of which have their benefits and drawbacks depending on your company’s specific needs.

For internal developers:

For internal developers who want to build an app and distribute it to test users, the process is fairly straightforward:

  1. Sign up for Apple’s Developer Program and create an adhoc profile, which binds specific devices to your profile using an ID system
  2. Build and upload your app
  3. Get a UDID (unique identifier) from every test user to whom you’d like to distribute the app
  4. Register the UDID in your account, and;
  5. Once that’s done, your test app can be installed on those devices and those devices only 

Under this method, Apple can control how many devices you can test with.

Although this method used to be quite tedious, today, it isn’t so bad. You can manage UDIDs manually, but through App47, we can help extract data automatically after a new user registers a device, tying the UDID to your profile at the same time. This streamlines the process and makes things smoother for everyone.

Through the public app store:

So: you want to put an app in the public app store. Here’s the basic steps:

  1. Sign up for iTunes connect and sign in
  2. Build and upload your app
  3. Wait out the Apple review process (usually 1-2 weeks)
  4. After it’s approved, users can go to the App Store and search for and download your app

Most people are familiar with this method, and for a general release, it’s a pretty simple process. Sign up, upload, search, and download.

Through the Volume Purchase Program:

A variation on the public app store process we mentioned above is the Volume Purchase Program from Apple, which starts to be handy if you’re looking to distribute an app to (and manage app security for) a larger number of users.

Unlike the two deployments mentioned above, this is less about the publishing side than it is consumption. The VPP uses the same technology you’d see for a free app redemption code. When you want to purchase, say, 1000 copies of a paid app and distribute it out to your users, you work with Apple to purchase the codes. You’ll receive a spreadsheet that contains however many codes you purchased.

If you were doing this all manually, it would be up to you to hand them out—and to reclaim them when users leave. Through MDM solutions or an MAM like App47, however, you can load the spreadsheet in and better manage distribution. Solutions like App47 allows you to manage distribution, reclaim tokens when employees leave, and in general, have more precise control over the purchase and distribution of apps through the VPP.

For enterprises looking for even more precise control, it’s possible to deploy B2B apps using the same Volume Purchase Program. The app is still published through the App Store, and it’s still reviewed by Apple, but with one major difference: you have full control over who can download the app. That is to say, these apps aren’t searchable through the public App Store.

Using this deployment method, the developer gets the Apple ID of the purchaser and approves that user. When the purchasers signs in, they’ll see that they can download or purchase codes for application X. If you want to distribute using the VPP but the app is strictly B2B (or you otherwise don’t want it to be searched), this is a time-tested method for doing so.

As with all the other deployments we’ve mentioned today, an MAM vendor can help you with this process, as well.

Through an enterprise or in-house profile:

And finally, we have the space where we spend most of our time: the enterprise, or in-house profile. The enterprise profile is a way to sign the application in such a way that it can only be downloaded to devices meant for enterprise apps.

Whereas an adhoc profile uses technical enforcement to determine how many devices you can test your app on, enterprise profiles use legal enforcement. To sign up for and use the Enterprise Developer Program, you have to agree to terms and conditions from Apple which say, in essence, that you’ll only use your profile to deploy apps in direct support of your company. It is up to you to have your legal team review this agreement and decide if you’ll be able to work within those parameters.

The good news is that once that’s done, you can sign in with your enterprise profile and distribute apps out to anyone; they don’t have to preregister or give a UDID. A recent change to iOS 9 means they will have to accept your profile with a UI that’s a bit different than years past, but that’s it.

This, unsurprisingly, is where we come in: using our app store, you can distribute apps, but also get a handle on security and make sure only authorized users can get your app. MDM solutions can help with this as well, but if you’re an enterprise developer and need an MAM solution, that’s exactly what we’re here to do.

And there you have it: a 101-level overview of performing an MAM deployment on Apple’s iOS. Have a question about this post or any other posts in the series? Reach out to us in the comments or on Twitter @App47!