Apple @ Work is brought to you byÂ Jamf, the standard in Apple management. Learn more at Jamf.com/9to5mac.
Over the past few weeks, Iâ€™ve been looking at various tips and tricks for mobile device management systems. If you are new to the MDM world, itâ€™s how you manage devices in bulk. Whether you are managing a few or thousands of devices, an MDM solution can be helpful. It allows you to push out deploying devices without even touching them, install configuration policies, and install and manage applications remotely.
This week, I wanted to talk about the application management process with MDMs. Apple has changed up this process over the years, and itâ€™s become an absolute joy to manage and install apps on macOS and iOS through MDMs. In the early days of iOS management, we had to use iTunes to load content on to iPads (no, I am not kidding). It was painfully slow to install even one application, and you donâ€™t want to know how slow iTunes was during the process of updating iOS. There was almost no chance that I would install anything but major updates to iOS because it took so long.
In 2012, Apple released a tool called Apple Configurator that was dedicated to preparing iOS devices for mass deployment. It allowed you to configure up to thirty devices at a time (with a massive USB hub). The Apple Volume Purchase store was released around this time as well. It was a bizarre process if you connected your VPP account to Apple Configurator, though. When you purchased an app, you got a spreadsheet with iTunes codes listed. Youâ€™d take the first code listed, redeem into iTunes (to get the app file), and then load it into Configurator. It then asked for the spreadsheet (it wasnâ€™t even a .numbers file either). There were early bugs that made that first code unusable in Apple Configurator after redeeming it in iTunes, so I usually bought an extra code. Apple Enterprise Support was always willing to make it right with a free code, but it wasnâ€™t worth the hassle of calling. As you can probably see, this process did not scale up to the 1000+ device deployments Apple sees today with businesses and schools.
From there, we moved to MDM based app installs that came over the air. IT teams rejoiced at this because it meant that you didnâ€™t have to touch each device. The downside of this is that it required end usersâ€™ acceptance with the deviceâ€™s App Store account. This was a problem for kiosk devices, devices for younger kids in Kâ€“12, and other multi-user scenarios. But one of the great benefits of this system was that Apple brought over the ability to revoke licenses and take them back. This meant that if you only needed an app for a short while on groups of devices, you could deploy it, let them use it for a period of time, and then bring it back into your app library.
A few years ago (iOS 9 or later, or macOS 10.11), Apple moved to a new authorization mechanism for apps, and it was called Device Based App Assignment. This method allows the MDM administrator to deploy apps to a device and the end user doesnâ€™t have to do anything to receive the application. Like before, the app can also be revoked at any time. The only downside to this model is that if a user has an iPhone and an iPad, theyâ€™ll only have access to the app on the device it was assigned to via MDM. Device Based App Assignment is perfect for kiosk deployments, Kâ€“12, and enterprise users alike.
We are now at a place with app installations on macOS and iOS where everything is just about perfect. The process of the Volume Purchase store transferring the licenses to my MDM happens in the background. My MDM and the VPP store are connected via a token that I have to renew on a yearly basis. Apple built the system so that the app licenses ultimately lie with them, so I could change my MDM vendors in the future without losing all of my licenses. Once itâ€™s in my MDM (this process can take anywhere from one minute to five minutes on average), I can then go through the process of installing the app. While different MDM vendors will present the UI differently, they all generally do the same thing with app installs. I have the option to install it on a specific group of iPads or leave it in self-service. Self Service is an in-house app store that schools and businesses can have. I always force the install so users donâ€™t have to go search for the applications.
My only workflow hindrances that I still have with app installations on macOS and iOS is dealing with in-app purchases. Apple still doesnâ€™t have a way to unlock IAP content remotely. Thankfully, a lot of applications that require IAP offer a version for a paid amount that unlocks everything from the beginning. Overall, the current model for managing and deploying apps via MDM is reliable and efficient, and there isnâ€™t much else you could want from an IT system.
I sometimes get questions about if an MDM is needed for smaller deployments (under 10 devices), but I think app management is the killer feature that makes it worth it. With tools like Jamf NowÂ available for small business, there is no reason that companies should spend time deploying and managing devices without a top notch MDM.
Thanks to Jamf for sponsoring Apple @ Work.Â Jamf, the standard in Apple management, is committed to enabling IT to empower end users and bring the legendary Apple experience to businesses, education institutions and government organizations via its product portfolio.
Learn more at Jamf.com/9to5mac.
Photo by Joshua Oluwagbemiga on Unsplash
Check out 9to5Mac on YouTube for more Apple news: