This book primarily focused on Apple device management techniques that are used on the macOS, tvOS, and iOS devices, with the exception of the areas where certain functionality is only available on a given platform today. That’s because Apple has slowly brought the management story together for their platforms. This makes sense, considering the fact that each framework has to be maintained differently for each platform. That becomes a lot of development sprawl to maintain.
This isn’t to say that the platforms will merge and that we’ll see a unified operating system. But Apple does seem to trend toward a lot of similarities. That began with the Mac App Store and thus far led to a much more sandboxed Mac. It is impossible to know what the future holds. These and other changes can lead to a number of pretty informed assumptions about the future, based on what has happened in the past.
In Chapter 1, we covered how we got to where we are today. Throughout the main body of this book, we then looked at how to implement various options necessary for a successful Apple deployment. How does this impact you and why are we talking about the future, though?
This impacts each deployment as it saves hours or days previously spent to build something that got outdated in a year. That’s why the book goes into the future of the platforms, to keep from repeating the same mistakes and avoid future technical debt. In other words, think of the future long-term state of a given environment and all the attributes. Compare that to the current state and then prioritize each chunk of work to get from the new way to a new steady state. A tool that can help get that future state in mind is a balanced scorecard.
Balanced Apple Scorecard
Apple devices can act as a first-class citizen on any network. What emerged through the history laid out in this book is a collection of best practices, a tool chain that’s commonly used, and a general philosophy (or one for each vendor or open source project in some cases).
One way to maximize impact is to take a step back and look at the ecosystem of an environment from the perspective of “what do I need for my environment?” To guide that observation, this section includes a scorecard to use, but consider the ecosystem of a given Apple environment more holistically. The scorecard for any two organizations is likely to be different than any others, and the development of a way to quantify how an organization tracks is likely best when it stems from a negotiation between all the stakeholders involved. That might include legal, compliance, human resources, and finance teams. Don’t get entrenched in any opinions with the other stakeholders but do explain gently where their support is needed.
This scorecard provides a snapshot into the technology stack required by most organizations as well as the attributes of each in a simple dashboard that executives can understand. Many of the technologies in this scorecard might not be required by an organization at the time the scorecard is created but are likely to be required at some point in the future if not already, as the deployment (and organization) grows and becomes more visible – and even if they’re never required, it’s good to talk about them and just make sure that’s the case.
Balanced scorecards can use four boxes in a document built in Excel, mind map tools, or any other tool available. They’re usually a list of attributes that an organization cares about. In the following text, see a list of categories and some attributes to consider asking about. Most organizations won’t adopt all of the technologies on this list, but most should at least have a discussion about each:
Network access controls
802.1x access
Captive portal management
Proxy access and PAC file distribution
Centralized certificate, CA, and SCEP management
Printer distribution and management
Centralized font management
VPN management and access
License tracking and reporting.
All applications are available to Apple devices.
Centralized collaboration suite access based on device state.
All file servers and content management.
Virtualization for any applications not available for the Mac, per job function.
A seamless unboxing and deployment experience (including imaging for legacy devices).
Devices can be centrally managed.
Automated application deployment.
Standardized application packaging.
Automated QA and User Acceptability Testing for patches and application updates.
Dashboard that shows standard KPIs for the fleet.
Leveraging directory services for single sign-on (whether there’s a trusted bind in the transaction or not)
Integrated Identity Management with SSO and/or SAML providers
Migrate directory services into a cloud solution and provide login window access to those directory services
Antivirus
Endpoint backup
Centralized encryption management
Centrally managed and auditable policies following NIST guidelines (e.g., password aging and complexity)
Log analysis
Application access controls (whitelisting)
Threat management and mitigation
Forensic snapshotting and antitheft
Legal hold
Zero-touch assets that cover the most common tasks necessary to get your job done
Support staff trained on managing devices
Centralized auditable remote access
Service desk software that is integrated with management platform
User-controlled software deployment with automated approvals from management where needed
Device state management
Help menu providing easy access to tickets and standard support tools
Automated proactive maintenance
Now there’s something to cover at the next annual review! The point isn’t to integrate everything, but to make sure to be cognizant of what is integrated, why, the priority of each, how to quantify the deployment, and ultimately how it makes the user experience better while protecting your organization. These should also be time bound and viable. It’s usually not too smart to try and project the future of technology too far in the future, given that the industry moves so rapidly. But do look into the near-field future so there’s no need to rebuild infrastructure just put into place last year.
The Tools
One of the most important aspects of device management is to choose the right tools. These typically have a direct correlation to labor costs as most are used to automate tasks. A large multinational enterprise needs different tools that can scale with their footprint; a small business may get crushed under the weight of tools that are purpose-built for, often codesigned by, and maintained for larger organizations. Most tools aren’t a permanent decision, though. The antivirus, backup, collaboration, and file server access software are easily interchangeable. For a Mac, admins can also migrate between management solutions with a scripted workflow. However, migration between management solutions is more difficult for iOS devices. In order to move an iOS device from one Mobile Device Management solution to another, the devices typically need to be reenrolled and sometimes wiped (e.g., for supervised devices). This is the kind of migration not often undertaken, and so some vendor lock-in can occur.
Consider how tools interoperate to plan a switch or net-new installation as well. Many will build complex workflows that automate workflows. As an example, if antivirus definitions for a device don’t get updated, there are prebuilt integrations that can revoke access to various resources and create a ticket in service desk software. This allows administrators to automate a number of their tasks as well as tasks for other teams, which reduces the need for more service desk and desktop support teams and reduces the possibility of human error.
Some vendors provide connections to solutions within their own portfolio (e.g., they may have an MDM and an antivirus tool that they sell). Others provide support for some third-party solutions, which allows administrators to have a consistent administrative experience across multiple tools. Some have mature APIs but no prebuilt integrations. The level of customization for each integration often requires more training to learn how to build tools but comes with more options and can therefore give administrators more flexibility in how they automate tasks. This trade-off is a consistent theme in any management stack. Bite off too much and not much gets done.
The reason there are so many options now is that the population of Apple devices out there warrants it. This allows niche vendors to offer more value to customers with solutions tailored to their needs. As the number of tools to manage various aspects of Apple devices has exploded, it’s gotten harder to determine one that fits with each environment. Apple innovates at such a rapid pace that those in the space can’t be everything to everyone. Picking the right vendor therefore requires research and a bit of diligence.
The future of Apple Consulting lies within the powers of the tools we use. There are so many options out there on the market to manage a fleet of Macs with. Choosing one and going all in helps, but you need to know when to pivot. Ask yourself if a tool is doing everything in its power to help administrators constantly maintaining it.
Justin Esgar, Founder and Organizer of ACES Conference
One aspect of choosing the right tools is to find solutions that keep current with Apple advances and maybe even think ahead to what Apple might be planning next.
The Near Future
This book has covered User Accepted MDM, User Accepted Kernel Extension Loading, Privacy Preferences Policy Control, and now Extensions in the System Preferences. Anyone who has paid attention throughout this book will note these really mean one thing: transparency for end users. The argument against some of these transparency alerts is that when prompted so often, users click accept every time they get prompted. This leads to a fine line between how to inform people and get their consent and how to best protect companies that issue devices to those users.
Administrators can do more to manage devices if they can prove ownership. Device supervision means proof that a device is owned by an organization. It doesn’t mean that the developers who wrote supervision actually want organizations to spy on end users without their knowledge. This is nothing new. Apple Remote Desktop had a different icon in the menu bar when it was in use. But in those earlier days, it was much less likely an administrator could gain access to a credit card number, social security number, or personally identifiable information as easily as they can today. Further, if that data was remotely accessed, there wasn’t nearly as much of a market for the data as there is today.
Privacy Controls
The biggest changes over the next few years will be to continue that trend, where users must consent to management that impacts their privacy, but not consent to changes that impact the management of features on a device. This might seem simple, but the balance between an organization's telemetry and how to provide privacy on devices is far more complicated. Organizations need to manage devices in a cost-effective manner, and a lack of centralized administrative capabilities actually requires a lot of deliberation and even a little backtracking here and there.
Keep in mind, Apple has changed the way devices are managed universally. They played nicely in a system led by Microsoft, but the challenges were different. Users didn’t use desktops in a closed Local Area Network, they used phones and tablets on devices constantly connected to the Internet directly. They set aside 3–40 years of corporate IT dogma to improve security and privacy. This new theory of device management seems popular enough that Microsoft, Google, and others have slowly adopted most of the same options as well. Transparent management and privacy protections are what most of us want, and so we should assume our coworkers want the same, no matter how many support cases they file in a given month.
Being an Apple admin requires a little patience. Apple doesn’t publish a road map that spans a decade like some vendors do. Apple doesn’t guarantee that a given model of device will be available for five years. Apple also doesn’t comment publicly on most of these features outside of the Worldwide Developers Conference (WWDC). This doesn’t mean that individuals at Apple won’t comment on what they’re up to. What “Apple” tells their users, like any organization, is often just one person who talks about something with no information beyond their own circle within the company. “Apple” is a company of individuals, not a single organism. Anyone who is in a position that provides them access to privileged information about future plans likely isn’t willing to risk that position.
“Apple” would love to tell people more. There are a number of questions that software developers and product managers at Apple haven’t answered for themselves, much less written a single line of code for. And as they chart a new course for our industry, we have to expect that Apple will constantly be moving our cheese. Job security is a wonderful thing!
The Apple Product Lines
Anyone new to the Apple world would probably be surprised that Apple once distributed wireless access points, routers, 1U rack-mount servers, rack-mount RAID enclosures, and even a full server-based operating system called Mac OS X Server. In fact, Apple has built and sold server services since the introduction of the Mac.
Right around the time that Oracle bought Sun, Apple doubled down on their iOS investment and released the iPad. At the time, Apple reportedly had $64 billion in cash on hand and so could have purchased Sun with a relatively small investment in cash compared to what they had in reserves. But the iPad was a much smarter investment of those resources.
Apple started to spin down their own lines of servers and pull functionality out of the operating system that didn’t align with a long-term vision at about that same time. Apple didn’t try to be something they weren’t anymore and sell enterprise servers. Instead, they parlayed their success with further investments into iPhone and the emergent iPad to become the wealthiest company in the world. Apple doesn’t want to be a server company, and it’s doubtful that more than a few people within Apple ever did.
Over the course of the next few years, Apple discontinued all dedicated server hardware and slowly slimmed down on the number of services in the Server operating system. First, they removed specialty services such as Podcast Producer and Xgrid, then groupware functionality such as Mail, Contacts, and Calendar services. These services were never going to rival Office 365 or Google Apps. Apple finally canceled the macOS Server project entirely in 2022. This allowed them to repurpose engineers to other teams and move faster on the client platforms.
Apple simplified their product offerings when they cut more than just the server hardware and software. Apple discontinued the Apple AirPort Base Station from the product line. This was another moment in the slow spin-down of various teams at Apple who had previously been tasked with owning the entire network stack. Apple made the AirPort since the early days of Wi-Fi, mostly out of a need to get good wireless options available for their own lines of computers. The AirPort devices were over four times the cost of base stations with similar specifications from competitors, but they were solid devices and relatively easy to set up and configure. At one point, that product line included a base station with integrated storage as well. The AirPorts were stable, rarely had issues, rarely needed updates, and had great range. But when similar devices started to plummet in cost, Apple shuffled resources to more profitable adventures, as they should have.
As with server hardware, Apple has removed devices that don’t sell well to maximize their investment into the devices that sell like hotcakes. This is good business. Expect the trend to continue for one of the wealthiest companies in the world (if not, according to the day, the wealthiest company in the world). Consider how the Apple portfolio has changed since the early days. Apple divested the LaserWriter when there were other good options for printers users could buy. Apple made switches and network appliances as well, but don’t need to at this point. Apple canceled these and their servers when the Return on Investment (ROI) calculations made it smart to do so, and they were no longer needed in the ecosystem.
If at first you don’t succeed, try and try again. Apple tried to make mobile devices twice before they succeeded with the iPhone. There were more times, but they didn’t leave Apple labs. The iPod to iPhone and iPad release will go down in business history books as one of the most important business decisions of all time. The MacBook sells well for a computer, although pales in comparison to the sales of iPhones and iPads. But pay attention to those annual reports and notice the lack of discussion about desktop computers and some Apple apps on the App Store (some of which have never been mentioned).
Apps
“There’s an app for that” is now part of everyday vernacular, especially among those who work in the IT industry. Since the inception of the App Store, millions of apps have made their way onto the Apple App Stores and changed the way many organizations purchase and use software. Where organizations once needed to purchase large software packages that ran the business, the App Store has allowed people to buy smaller apps that do various tasks and string those workflows together either with built-in integrations or by linking various tools together with third-party automation solutions.
Evolutions in Software Design and Architecture
The ability to link disparate tools together is facilitated by a few trends in how software is architected. The first is that since the first iPhone was released, software has increasingly moved from client-side apps to web-based apps. This move has been to cut down on development costs, make software easier to deploy at companies, and allow software to be run on more and more platforms. Additionally, the more companies that have transitioned into web apps, the more engineers that are trained on how to develop for them and so the easier it has become to train engineers.
Another trend is microservices or a trend toward smaller code and so more easily run as functions in environments like Amazon’s Lambda service, Google’s App Engine, or a plethora of other options. These replace large monolithic structures of code that are hard to maintain and even harder to make parts of the code public (e.g., through APIs an app can consume). This allows a lot of different developers to work on various services collaboratively and not step on each other’s toes. The move away from huge servers saves the organizations that embrace a microservice-based architecture millions of dollars in hosting fees.
Because so many companies need their software to interoperate, the authentication mechanisms have also evolved. Federated web identities allow two pieces of software to trade data on behalf of a user (e.g., with technologies like OAuth Connect and SAML) or admins (using tokens such as a JWT). The ability to have a federated identity means administrators can easily install plug-ins in software and automate tasks in their name. Where authentication was once handled by Kerberos or with local salted hashes, developers could now just import a library to do OAuth (or implement a microservice that handles that code) and easily be able to work with other vendors.
Another aspect of how software has evolved would be URL handlers. Websites have long looked at the http:// or https:// prefix to know that a URL represents a web page. Before that, URI schemes could include ftp://, smb://, or one of the originals referenced in the IETF specifications, gopher://. It turns out that an app can register that prefix as well, known as a URL handler, much the way that users once registered a file extension. This allows software hosted on the Web to open an app, receive data from the app, and send data to the app with deep linking. Most modern software solutions not only interpret URLs this way but then interact with microservices authenticated through a federated identity and so get away from monolithic structures that have too much logic built into them that cost an arm and a leg to rebuild every decade when programming languages change. Further, if a site is built in Java, Python, or a bevy of other languages, there are plenty of tools that allow admins to build once in those languages and compiled as native apps for Apple and Android (although a truly native Swift app is smaller and better in nearly every case).
The Evolution of Apple Software
The programming languages that Apple either distributes or designs have changed over the years. Apple has quickly iterated the tools and code used to create apps. This makes code more interchangeable between platforms. The fact that code has become smaller and more modular also means that bits of code can be shared more easily on social coding sites, such as GitHub. This means developers can build more, faster.
Smalltalk was a language developed in 1972 with the last stable release in 1980.
AppleScript is a language introduced in 1993 that can still be run on a Mac. AppleScript can be used with services, Automator, or invoked through shell scripts today and is meant to be used for simple automations.
Objective-C took parts of Smalltalk messaging and added them to C and was the main programming language for NeXT and by virtue for subsequent Apple products until Swift was introduced.
Swift is licensed under the Apache 2.0 license and has been available since 2014. Swift is now the language most often used to write tools for Apple devices, with many components reusable between tvOS, macOS, and iOS.
Python, Bash, and even Perl are common scripting languages used on the Mac. These have been compiled and distributed with the operating system, although sometimes it pays (as with Python 3) to update to newer versions. Recently, Apple has begun to remove these from a default installation, so a native Swift app is in most cases the best bet to automate tasks if possible.
Cocoa and Cocoa Touch aren’t languages, but APIs commonly imported into projects when a developer writes apps for Apple products. Cocoa apps are usually developed in Objective-C or Swift. Since Cocoa is an API, it can also be called from Python, Perl, Ruby, AppleScript, and a cornucopia of other languages with a bridge. Cocoa provides access to many of the built-in frameworks, and there are a number of projects that can be found to get other frameworks in projects. Package managers such as CocoaPods help keep them up to date and provide some build automation where needed, although Swift Packages are a better alternative for most.
Carbon was an API that helped bridge the gap from OS 9 to OS X. Carbon was never updated to 64-bit, so Carbon was deprecated in Mac OS X 10.8. Cocoa has been around for a long time, but don’t expect it to disappear any time soon. Apple will also further restrict what lower-level functions can be accessed from Cocoa on the Mac in the future and continue to evolve Mac, iOS, and tvOS options for Swift.
In the first edition of the book, we said “Stay on the lookout for an eventual shift in what chips Apple uses on the Mac.” These are all now ARM chips made by Apple, so Swift is easily portable between machines. This allows the same app to have different interfaces for how users interface with apps on different types of devices. The reason watchOS isn’t mentioned earlier is that it’s an extension that developers add into other apps and not truly a stand-alone device.
In addition to the tools Apple provides, organizations that want to develop cross-platform apps that don’t require much of the native functionality found in Swift can use a number of different mobile development platforms such as Appcelerator, AppInstitute, AppMachine, AppMakr, Appery.io, Appy Pie, Bizness Apps, BuildFire, Como, Crowdbotics, GoodBarber, iBuildApp, Kony, PhoneGap, ShoutEm (Javascript), TheAppBuilder, Verivo, ViziApps, Xamarin, and Xojo. There are a lot of these, and each appeals to a specific use case – after all, each developer wrote theirs because they identified a gap in the market.
Low-code apps are a great gateway drug to test a thesis that any organization might have: an app will reduce the need to buy a third-party app/service, remove a barrier for adoption for the platform, or increase productivity. As the app gets more complicated, then it’s likely to become too mature for a low-code type of solution such as those mentioned earlier. Additionally, the options each of these organizations is able to provide are limited to the options Apple makes available on the platform. However, to satisfy the needs of multiple platforms at once and be able to get an app out the door in days is often pretty much worth it, which explains why they remain popular.
Now that we’ve looked at developing apps, let’s look at Apple apps and the future of each.
Apple Apps
The Server app is finally gone. But a few tools are still necessary to enable the Apple platforms. Apple Configurator was written by one of Apple’s first employees in order to address problems he saw in the classroom. The tool has gone through several iterations over the years and has since become an integral part of the Apple management offerings, as seen in its use throughout this book. Other tools can do some of what Apple Configurator does, which we’ve covered in this book, but none have reached a level of maturity or official support where the loss of Apple Configurator would not negatively impact the ability to deploy iOS devices en masse. Therefore, there’s little risk to developing workflows based on Apple Configurator. In fact, the product built on top of Configurator’s command-line interface makes it seem like it will only become more necessary in the future, or the introduction of APIs that allow similar functionality in other apps might mean Configurator-type of functionality becomes parts of other apps.
Apple Remote Desktop (ARD) began life as Apple Network Assistant and has evolved over the years. As networks have become more complex, ARD is less useful than it once was. Today, there are a number of competitive products ready-made for remotely controlling devices, which include Bomgar, GoToMyPC, TeamViewer, Splashtop, and dozens of others on the app store. Additionally, for those on a LAN, there are dozens of options for VNC-based clients that can access the VNC server built into the Mac. ARD isn’t useful for iOS or tvOS devices. Either ARD will get an update so it can connect over APNs or it will not likely be a product in the future now that there’s a rich ecosystem of products that can do what it does. In the meantime, ARD should be used if the alternatives are cost-prohibitive or lack features needed, such as the ability to connect to devices remotely.
Apps that should be safe are those that empower the platform. Think of Xcode for software development and Apple Configurator for setting up and managing large iOS device deployments. There’s not a strict ROI calculation to be done on these, and they’re necessary for the third-party applications available for the platform to mature. Do expect them to evolve, though.
Productivity Apps
There are other apps as well, built into the operating system. These can come and go, based on technology changes. For example, when all Macs shipped with writable DVD drives, the iDVD app was necessary. Other apps have remained somewhat consistent over time, even if they’re packaged differently than when they were first released.
iWork was introduced in 2005 and is a collection of desktop apps that Apple distributes to rival Microsoft Office and Google Apps. iWork includes Pages, Numbers, and Keynote. Initially sold for $79 per copy, iWork was then distributed for free with Apple devices manufactured after 2013 and later just made free for iCloud account holders, once online collaboration was added to the suite. It’s important to note that Apple has had a suite of apps going back to 1984 with AppleWorks Classic, which would then be spun off into Claris and come back as AppleWorks, which reached End of Life in 2007 in favor of iWork. Microsoft Office is certainly the dominant player in word processors, spreadsheets, and presentation software, but Apple has maintained their own option since before the inception of the Mac and is likely to continue to do so in the future.
Professional (or prosumer as some are called) apps like GarageBand, Logic Pro, Final Cut Pro, and iMovie are also likely to stay and just get better with an infusion of options through various machine learning frameworks.
Apple Services
Activation Lock: Locks devices from activating if they’re wiped, without the iCloud account that was last registered on a device. The ability to bypass Activation Lock is a key feature of most MDM solutions.
Backup and restore: Used to back up and restore iOS devices.
Back to my Mac: Share screens and files with other computers that are using the same iCloud account. This service doesn’t allow access to devices for accounts on different iCloud accounts and so is not a replacement for Remote Desktop.
Calendar: CalDAV service provided by Apple to keep calendars in sync between devices and share calendars between devices.
Email: Email service provided by Apple, with accounts in the domains me.com and/or icloud.com.
Find My Friends: A geolocation service so friends and family members can share their location with one another and locate devices physically. Find My Friends is simply called Find Friends in the iCloud interface.
Find My Phone: Allows you to geolocate your devices from other devices or from the icloud.com portal, where the option is called Find iPhone.
Handoff: Allows you to continue tasks such as writing an email or viewing a website from one device to another. Currently works with Mail, Maps, Safari, Reminders, Calendar, Contacts, Pages, Numbers, Keynote, and any third-party apps that are developed to work with Handoff.
iCloud Drive: File storage that is accessible between (and often synchronized to) any devices registered with the iCloud account and accessible from the iCloud.com web interface.
iCloud Keychain: Synchronizes passwords between devices.
iCloud Music Library: Adds any content you purchase from one device to automatically be downloaded to other devices.
iCloud Photos: Synchronizes all photos and videos to iCloud (and so to each device that uses the service). Photos can then be placed into albums and shared to other Apple devices.
iWork: Shared Pages, Numbers, and Keynote documents.
Messages: Instant messaging service from Apple.
News Publisher: If you’ve signed up, allows you to write articles for the Apple News app.
Notes: Keeps content synchronized between the Notes app on computers, mobile devices, and the iCloud web interface.
Photo Stream: Stores photos in My Photo Stream for 30 days (duplicative when using iCloud Photos).
Storage: Each iCloud account gets 5GB of free storage and then provides upgrade plans up to 2TB of storage for syncing all files between Apple devices.
A screenshot of i cloud home screen. There is the text, good morning, Charles, at the top. Below the text, there are icons for mail, contacts, calendar, photos, i cloud drive, notes, reminders, pages, numbers, keynote, news publisher, and find i phone.
iCloud.com home screen
These services become more and more integrated into the operating system with each release. As an example, if the “Allow Handoff between this Mac and your iCloud devices” option in the General System Preference pane is enabled, Handoff is used to enable the Universal Clipboard to copy and paste text, photos, and other content between devices. Users can also send and receive iMessages from a Mac, answer calls on an iPhone from a Mac or Apple Watch, and have websites available in Safari that were opened on an iOS device. The frameworks available for developers also mean that technologies like Handoff appear in more and more apps. In the future, expect more and more services provided by Apple and third-party apps to make use of Handoff, given how much simpler it makes people.
The use of Bluetooth to provide an easy way to quickly transfer information between two devices isn’t limited to Handoff. Apple Classroom makes use of Bluetooth to allow teachers to locate nearby devices assigned to their classes and provides teachers with the ability to open apps, browse to a specific website, lock devices, view screens, AirPlay the screen to another device, and set passwords on devices. These options are similar to (although a subset of) options in Apple Remote Desktop and expect to see more innovative uses emerge over the coming years (something we thought would happen with iBeacons but never really materialized).
Apple Device Management Programs
Apple School Manager, introduced in 2016, isn’t required to use Apple Classroom, but it does give the option for Shared iPads, which is the first time we see multiuser iPads. It’s also the first time we see Managed Apple IDs, which are used in Rosters in Apple School Manager. iCloud content is then synced to multiple users in much the same way it’s done between Macs using iCloud Storage. Apple Classroom is also made better with an MDM solution that supports the Education profile payload.
Apple School Manager does more as well. Apple School Manager provides a portal for schools to manage Accounts (users), Classes (groups), Roles, MDM Servers that are used (or at least the token generation for servers), Automated Enrollment (the Device Enrollment Program), Device Assignments (which maps devices to users), Locations, Apps and Books (otherwise referred to as the Volume Purchase Program), and iTunes U, a service for accessing educational content through iTunes or the iTunes U app. Office 365 now has built-in integrations with Apple School Manager and expects more from Shared iPad and Managed Apple IDs in the future.
Managed Apple IDs initially came to Apple School Manager and can now be found in Apple Business Manager. Apple Business Manager is a portal similar to Apple School Manager but designed with less learning management in mind. While you can’t yet use Managed Apple IDs to manage iCloud or the App Store for a given ID, expect this functionality to mature in the future.
If an administrator started out with the standard Volume Purchase Program and still has a number of VPP tokens, then those need to be migrated to Apple Business Manager, but probably with a support call to make sure it’s all done correctly. The ability to purchase credits on a PO rather than use a credit card is a reason a number of companies will migrate to the platform, but make sure to understand exactly what happens with those VPP tokens before you do so in order not to orphan previous app purchases.
Automated Device Enrollment is the new name for DEP management. DEP should be migrated when possible in order to take use of the default DEP server option, which allows administrators to assign a different DEP server to each type of Apple devices, especially useful when there are multiple vendors to manage different types of devices (e.g., an MDM for iPhones and a different one for Macs). Apple Management accounts are consolidated, just make sure to work with each MDM vendor to best understand what impact to expect, given that each vendor might integrate the various services differently. That includes Apple Business Essentials, a cloud-hosted device management platform from Apple, introduced in 2022.
Getting Apps to Devices
One barrier to ship a new app is actually how to get the app out of Xcode and onto devices to test and then how to get that app onto the App Store. The first step to doing so is testing. Testing in iOS can be done using Xcode using the iPhone Simulator, manually distributing an .ipa file to a device (which is a bundle of compiled files that comprise an app), or through TestFlight.
TestFlight was founded in 2010 and acquired by Apple in 2014. TestFlight is provided to developers in the iOS Developer Program. TestFlight allows users to install and test apps before they are distributed through the App Store. Developers can see logs and review feedback from people who test apps as well. If an organization will build apps, then they likely at least need a working knowledge of TestFlight in order to support developers, who can use TestFlight to test up to 100 apps at a time. Don’t expect TestFlight to go anywhere, so any time spent learning how it works is time well spent, and it helps you to understand how the App Store works a little more as well.
Once an app has been tested, it’s time to distribute the app to devices. This can be done through web servers that distribute .ipa files for iOS and .app files for macOS. Any attempts to build internal or third-party app stores are typically linked to such a distribution model, and provided an app has been notarized, this isn’t likely to go anywhere. The App Store options for distribution continue to evolve. Those options began with gift codes, moved to VPP, and then got the option for Business to Business (B2B) apps, but those aren’t yet available for schools through Apple School Manager, and they aren’t supported by all MDM solutions.
Distributing software for the Mac is a bit different. Software can be distributed as an .app bundle, through a package file (a .pkg file), or through the App Store. An .app bundle is easy to copy, simply compile from Xcode, and open the application. We’ve covered installing an app through the App Store thoroughly in this book, and that process is pretty well ironed out at this point. The process will change here and there as options mature, such as the ability to install an iOS app on a Mac. Packages are a bit more complex, although far simpler than App Store oddities.
A screenshot of install flashprint 5 window. There are tabs for, introduction, license, destination select, installation type, installation, and summary on the left. The introduction tab has been selected.
Installing software manually on the Mac
Autopkg is an open source third-party solution that automatically builds packages. Anyone who hasn’t begun to automate their package build train should. Some third-party management solutions provide packages for various software titles as well. Autopkg can also be integrated into management tools (e.g., via the JSSImporter project to get packages into Jamf Pro). Many large enterprises think they have a couple hundred apps deployed only to realize they actually have a couple of thousand once an inventory can be had from the MDM. All of this is why so many environments really just want to get all of their software from the App Store.
More and more software titles are distributed through the App Store. Apple makes $99 per year and 30% (although the number can vary) of all income generated through the App Store. As of 2018, Apple had sold over $130 billion worth of apps, a number that has doubled since then. This makes the App Store a considerable revenue generator for Apple. That caused many to wonder if all software would eventually have to be installed through the app store. Microsoft Office is used by nearly every company in the world and so runs on a lot of Macs. Office came to the App Store in 2018. While Office is only one of two million apps, it was a holdout for the Mac and along with other notable titles that moved to the App Store showed Apple chip away at apps not currently distributed through the App Store.
Just when it seemed as though all software was destined to the App Store, other App Stores began to emerge. These were slowed due to adjudication until they made it to the Supreme Court. The high court found against Apple in 2019. The two main vendors to look at if you’re interested in what third-party app stores have to offer are GetJar, with 850,000 apps, and Appland with 135,000 apps.
Manage Only What Is Necessary
Most school districts in the early 2000s were obsessed with the dock experience on client computers. It was as though teachers and IT administrators in education environments just couldn’t help but obsess over the fact that a user changing one of these was akin to the student spray painting “O’Doyle Rules” on the wall of the school. Schools would talk for hours about the various ways students found to break out of a managed environment to move the Dock or remove icons from the Dock.
One of the best use cases for management in education is to make devices simpler to use. That simple user experience on first-grade iPads will help the kids follow along with the teacher without getting overwhelmed. In an increasingly one-to-one world, don’t obsess about the details. Children are really good with computers now. Show them how to use Spotlight to find the app they need instead of relying on the Dock – they’ll thank you later.
So why manage the Dock at all? To make it easier to get started using a device. This is true for a lot of the other settings as well. It’s not usually necessary to manage the background of iOS or Mac devices. It’s appropriate in customer-facing devices like in Point of Sale environments, but rarely in a distribution of devices where every user has their own. The less petty settings that are managed, the more time can be spent on the things that really matter, like security.
Administrators need to manage certificates that allow devices to join networks, directory services settings, and the state of a device when it’s provided to a user, so they can get to the things they need to get to most easily. This includes the ability to put the appropriate apps on devices, set the icons in an order that will provide for a good user experience, and provide any settings to help configure apps to access necessary resources. In other words, delight your coworkers rather than micromanage their experience (within whatever compliance guidelines are necessary).
But what does this have to do with the future of device management? It’s important to consider the Apple philosophy in order to future-proof deployments. That philosophy is to protect privacy and enable users. Anything that is too far from what Apple engineers test in their own QA labs risks being made out of date with a small release. This isn’t meant to be heavy-handed, just practical.
Sometimes, we have to pay attention to the trends involved and listen to what people from Apple tell us, even if what they say doesn’t match with what we want to hear. For example, various representatives from Apple discouraged the use of MCX for a couple of years. Later, that functionality was deprecated in subsequent releases of the operating system. All workflows that leveraged MCX had to be rearchitected to use other, more modern techniques. This meant that some of the work was done twice. What can we expect next? Let’s start with Agents.
The Future of Agents
The word “agent” can mean a few things, according to the audience. Will the future of Apple device management allow for LaunchAgents? LaunchAgents and LaunchDaemons will be around until probably at least 10.17. They will likely become more and more restrictive, though. So expect some kind of signing infrastructure and potentially a vetting on behalf of a user in order to invoke them.
Some people refer to kernel extensions as “agents.” It’s more appropriate to call them “drivers,” but we’ve seen enough that ∗∗∗should∗∗∗ be LaunchDaemons that we might as well just address them here. When the first edition of this book was written, Apple still allowed third-party kernel extensions. Those have all but been removed and replaced by extensions that are specific to a task and so can be sandboxed more easily. A list of extensions is available at https://developer.apple.com/app-extensions/. For example, if an app is to redirect network information, Apple developers want to make sure that the end user has agreed to that (or is at least aware of it); therefore, before the network extension is loaded into memory, the user is asked to approve of what is happening.
Developers like to know a system is in a given state so they know their code will work as intended. The ability to run code with the privileges a kext receives though is not popular within Apple, nor is anything that has root access. First, users needed to approve kernel extensions. Then they needed to be signed and notarized. This is similar to what has changed with agents in the past few releases. They haven’t gone away, but they have become more restrictive.
MDM is invoked by an agent called mdmclient. So there is no such thing as an agentless management solution. But it’s easy to think of a scenario where administrators cannot manage anything Apple hasn’t previously given access to manage via API endpoints, MDM commands, or profiles. This means less reliance on third-party agents, especially if users can see them in System Preferences and disable them. As the other management options are being trimmed back, consider how important mdmclient has become. At this point, anything that can be managed with the built-in MDM framework in macOS should be managed there; and anything managed in other ways should be reconsidered.
The term agentless comes from the fact that MDM is an Apple-supplied agent. Don’t be overly concerned about losing any custom or third-party agents. Instead, if a task can be performed either with MDM or using an agent/script/command, do so with MDM.
Other Impacts to Sandboxing
The sandbox implementation on iOS and tvOS has always provided a locked down environment that only allows users to interact with systems in ways Apple explicitly allows for. Administrators have to work around this, which makes many deployments seem more logistically complicated than they are technically complicated. That is likely to remain consistent in the coming years as threats (not only to phishing attacks but to privacy and persistent threats) continue to evolve.
Rather than have preferences stored in a centralized repository, each app might eventually have to have its own preference file in the app bundle. And Managed App Config is how this is dealt with on iOS. Administrators can pass parameters to an app on a Mac similarly. Look for apps that can be configured in such a manner rather than reverting to edit defaults domains and learn how to do so in order to be in front of any changes that may come in the future.
In order to run, all apps should be signed. In order to install, all packages should be signed. In order to load, all kexts must be signed and notarized. The Notary service is a proof that Apple performed some checks that apps and kexts actually do what they say they do and no more. The added security isn’t just a perception, it also means an app can have a hardened runtime, which lets an app run with additional security protections. This means developers need to follow a few specific rules though; most notably, they have to inform the user of every entitlement in use.
These entitlements are similar to the technology that came out of sandbox (.sb) files. Apple has enforced more sandbox technology on the operating system. Sandboxing does restrict what administrators are able to automate. For example, we can’t write to /System and so can’t automate tasks that called on resources nested in there in the past. As the platform becomes more widely used, it also becomes a more attractive target and needs those additional security measures to be enforced. These are all examples of parts of iOS technologies that moved into the Mac, which brings up the question: Will iOS and macOS merge?
iOS, macOS, tvOS, and watchOS Will Remain Separate Operating Systems
Apple has been clear that there are no plans to merge the operating systems. Instead, the message has been clear that each operating system is ready-built for a given purpose, and each is used on the appropriate type of device. This doesn’t mean they won’t merge someday, but it certainly means that we should plan deployments for the next few years with the assumption that they will remain separate. We should also watch for the barriers to fall in order to unify parts of the operating systems.
As mentioned earlier in the chapter, this isn’t to say that many of the necessary frameworks necessary to enable each won’t end up unified over time. There are far more apps for the iPhone than for any other app in Apple’s portfolio of devices. And it stands to reason that if those apps can run on a Mac, the Mac is a more attractive device to purchase.
How will these work with VPP?
How will they react to containerization technologies like Managed Open-In, AirWatch Container, and the MobileIron AppConnect?
Where are preferences stored and how are they loaded? Will Managed App Config play a larger role in the app ecosystem?
The third-party tools are all SDKs, and so the onus will be on developers to resolve any issues that Marzipan creates. The Mac seems to evolve more toward iOS, but there are ways iOS has evolved toward the Mac as well.
Will iOS Become Truly Multiuser?
The Mac didn’t have multiple users for decades but has had multiple users for over 20 years at this point (officially since the release of 10.1 in 2001). iOS has always been a single-user operating system. The integration between Apple School Manager and Apple Classroom gave the first glimpse of what multiple users might look like on iOS devices. Apple School Manager, using Managed Apple IDs, allows education environments to run different users on a single iOS device and provides a brief glimpse into what a multiuser iOS might eventually look like.
Each user can have an app shown or hidden. So apps can be on the device unbeknownst to a user, and when the device switches users, it just shows a different set of apps. This gets around the need to push apps to devices every time a user logs in. While Shared iPad is only offered in Apple School Manager today, Managed Apple IDs are now available in Apple Business Manager, and the future may hold a shared iPad for enterprises.
The impact, though, might not be that we have iPads in the hands of multiple people. The devices are just different. iPads cost less, are much more personal devices, and, other than niche use cases, have never needed the ability to have multiple users log in. The impact instead might be that users authenticate to access a device and then are able to better federate access between services with modern protocols such as OpenID Connect, SAML, and web tokens. The federated identity picture is still in its infancy on the Apple platforms.
Changes in Chipsets
The advent of the Intel in Apple devices saw Apple finally welcomed into many enterprises in ways Apple hadn’t been welcomed in the previous decade. This allowed Apple to exploit the desires of many to have a choice rather than just use Microsoft, all the time. Ironically, once the platform finally caught on enough to be the darling of “innovative” leaders in enterprises, Apple began to move away from Intel.
Apple purchased PrimeSense for $350 million in 2013 in order to make the chips now used for Face ID. Apple purchased parts of chip maker Dialog for $650 million in 2018 (which brought in 300 engineers). Apple once owned part of the ARM alliance. Intel chips have had a number of pretty substantial security vulnerabilities over the past few years. It’s also increasingly important for Apple to preemptively check that no changes have occurred to the firmware on chips.
Apple has switched things up before. Apple has made the A series of chips for iOS devices since 2007. The Intel transition in 2005 signaled a move from PowerPC, which resulted in a collaboration that had begun between Apple, IBM, and Motorola in 1991. But the shift led to a drop in apps for a short period. Some developers had to refactor to work with the new chips. Apple released the M1 MacBook in 2020 and the M2 MacBook in 2022. They also released a compatibility option called Rosetta 2 to allow for a simpler transition. To see a list of software that works with the M-series of MacBooks, see https://isapplesiliconready.com/.
Another chip that Apple touts is the T2, a security chip introduced in 2017 (the T1 was released the year before and brought Touch ID with it). The T2 runs its own operating system called bridgeOS, a derivative of watchOS. This is the basis for the secure enclave. The secure enclave is where encrypted keys are stored and locks down the boot process. The camera and microphone go through the T2 physically as do the encryption mechanisms for the SSD drives on a Mac, and so the T2 becomes important for FileVault. The T2 is likely to be embedded into all Macs at some point.
Universal adoption of the T2 (and subsequent releases) means that Apple suddenly has a lot of new options around Apple Pay, Face ID for the Mac, and a number of innovations we can’t possibly have put together because we’re not sitting in their design labs. What does this mean for those who need to plan an enterprise deployment of Macs with a three-year budget? It means if you have an option to buy a device with a T2 or without, it would be wise to spend a little more to get the T2-enabled device. Chips keep Apple from innovating as quickly as they’d like, so Apple is likely to continue to do more themselves. But the impacts to an enterprise are minimal, other than planning purchasing options to align with the desired life cycle of devices.
You’re Just Not an “Enterprise” Company
Apple is not an “Enterprise” company. Those who have been in the Apple space for a long time have heard this throughout their entire careers. Other companies that are mentioned as not enterprise companies include IBM, Cisco, Microsoft, VMware, and the list goes on. It turns out that being “Enterprise” means doing the specific thing that a 200–200,000-person company wants a company to be doing at that moment. Many companies say they will do things, but not every business unit can do everything a company wants them to do all the time.
This isn’t to say Apple hasn’t become more and more “Enterprise”-friendly over the years. Engineers once said “you’ll never be able to lock the home screen on an iPad,” then tout that as a great feature, and later treat it as table stakes. We’ve gone from agent-based management that seemed barely tolerated on devices to a Mobile Device Management framework built just for centralized and streamlined management of devices. That framework is not ready to completely replace agents as has been made clear throughout this book. It gets closer every year, as teams at Apple identify each feature that organizations want to manage. That framework works when devices aren’t on corporate networks.
Apple has a tool called Enterprise Connect. Apple has an enterprise sales team. Apple has an Enterprise professional services team. Apple has a number of executive briefing centers. The Apple CEO goes for long strolls with the CEO of IBM and has meetings with presidents of various countries. Apple built Exchange Active Sync policies into iPhone OS and, due to overwhelming needs from large customers, invented a whole new kind of management. Apple continues to integrate with the latest enterprise software, whether that’s emerging SAML providers (including Microsoft), 802.1x network requirements, etc.
Sure, Apple is not an Enterprise company. But think about this: Apple is just getting started in the enterprise space, and as more enterprises adopt the platform, they’re likely to become more and more enterprise focused.
Apple Is a Privacy Company
In this book, we’ve covered dozens of security features on iOS devices. These include Managed Open-In, SIP, certificate deployment, policies, application blacklisting, signatures, and so much more. Apple has had a number of slips with security over the years, such as when they accidentally showed a root password in clear text.
For the most part, these are just programming slips and mean Apple just needs to get better with Quality Assurance, especially in a time when competitors such as Microsoft do so well in that regard, which is amplified in the eyes of the security community. Growing so rapidly is hard, given that the more people who use software, the more weird things they do to that software – and the more bugs they find.
Security and privacy are different. Apple devices have great security, but they’ll always be able to get better. In the face of so many privacy blunders by their competitors, one place where Apple shines is privacy. This privacy is seen and felt in all of the recent updates that frustrate Apple administrators. These block an administrator from performing various tasks.
The options for managing iOS devices over the years have opened up a lot of possibilities. iOS devices that are supervised can be managed in ways that we never thought would be possible in the iOS 4 era. All with privacy in mind. As an example, when Volume Purchase Program (VPP) apps are deployed, management solutions can push an app to an Apple ID. And if a user associates, the MDM can see the hash of the user that was used. But the MDM doesn’t receive the actual Apple ID; thus, they protect the privacy of the end users. Expect questions like “what are the impacts to privacy” to come up with every new management feature provided.
This brings us to one of the most important concepts that emerged in the minds of the authors of this book. While not much may have changed in the ethos around device management at Apple, the need to keep users safe has grown exponentially. The hacker mentality that brought many Mac administrators into the fold with the advent of Mac OS X creates danger for many standard users. And so many Mac Admins have left the platform to go manage Linux and other platforms. We all want different things out of our careers.
Summary
The only thing that is certain is change. The Apple platforms themselves change constantly, and so the way we manage them must change as well. The most important thing to ask about every new feature or change is how to manage a feature. And yet we need to manage features far less often than we might think.
Less is more. This doesn’t mean don’t manage anything on devices. It does mean that if a framework to manage features and settings in the operating system like MDM doesn’t have an option that it’s worth a second long and hard think about whether that should be managed long and short-term. A great example of this is how extensions can only be managed from within the app that instantiated an extension. Anyone who manages something that requires custom scripts should make sure to accept the fact that they’ll own occasional changes as Apple changes the underlying tools (e.g., from bash to zsh or the need to install python, etc.) until that setting doesn’t need to be managed any longer.
As we’ve shown in this book, Apple has had a consistent set of tools to manage devices since the inception of the Mac. Apple changes the tools to address IT industry trends or larger global security and privacy concerns. But the tools have always been there and in some cases still look similar to how they did in 1994. The name of the tools can change, the way they connect can change, and the way the tools manage settings can change over the years. Most were fairly static for decades, but began to change more quickly to address the invasion of privacy felt by many Apple customers given how ubiquitous technology has become. That’s not likely to end any time soon.