I have been asked whether it was wise to publish a book on Packaging now. There is lots of talk in the Mac Admin community about the future of admin tools. The general consensus is that Apple wants to move macOS further towards a locked down system like iOS (and watchOS and tvOS). We have already seen the first moves in that direction with System Integrity Protection. Some suspect the new file system APFS may break traditional imaging workflows.
Note: I used to work for Apple, but that was years ago. I have no inside knowledge and all this is speculation, based on my many years of experience working with and for the company. I hope I am right, but would be the first to admit that I have made very wrong predictions regarding Apple before.
Up to now, these changes are not too severe. Some (myself included) even approve of deprecating legacy practices such as imaging, given that the alternative solutions bring many other benefits. However, there is the spectre of the completely locked down macOS, which can only be managed the same as iOS can: with an MDM server.
I do not think this is Apple’s ultimate goal. I also believe it will take longer than many are afraid of, and it may be even impossible in the long term without breaking the nature of macOS fundamentally. I’d like to give a few examples:
Omnigroup has been a productive and successful developer for macOS since NeXTSTEP. They were on Mac OS X before there was a Mac OS X. Last year, the OmniGroup switched some of their applications in the Mac AppStore from the one-time purchase model to a free-download with trial and in-app purchase model. I understand why Omnigroup decided to do this. However, Apple has no VPP solution for in-App-Purchases so an administrator cannot deploy Omni software with an MDM anymore. OmniGroup still sells their apps directly, so you can buy a volume deployment license directly from OmniGroup and deploy without the Mac AppStore, VPP, or MDM.
Veertu is an interesting new virtualisation solution, which started out in the Mac App Store. It could do that because it uses Apple’s Hypervisor Framework, which is meant to provide the system resources necessary for virtual machines to SandBoxed apps. However, last year, Veertu removed their solution from the Mac App Store because the limitations were still too stringent. Similarly, VMware Fusion, Parallels and VirtualBox are all not in the Mac App Store and not deployable with VPP or MDM.
MATLAB is a powerful solution for building scripts and tools with mathematical and engineering libraries. Calling MATLAB an ‘app’ would be like calling your MacBook a ‘typewriter with a screen.’ Scientists and engineers not only use MATLAB to build complex mathematical and statistical solutions, they share those solutions as products or open source tools. Many people may not even be aware that they are using a tool running the MATLAB runtime in the background. MATLAB is one of many powerful math/numerical/statistics tools, such as Wolfram Mathematica, IBM SPSS, R, etc. None of which are in the Mac App Store or even possible with the current Mac App Store limitations.
These math tools are deeply entwined with the UNIX philosophy of tools passing data from one to the other to do specialised steps of processing. Some workflows I have encountered are Rube-Goldberg-Machine-like sequences of MATLAB, Python, and bash scripts with a Qt or Java UI. As monstrous as these ‘solutions’ may be, they are essential for many people’s day-to-day work.
The only Adobe application in the Mac App Store is Photoshop Elements. There are many more Adobe apps in the iOS App Store, but none of their core Creative Cloud applications. One of the reasons may be that many Mac users, not only rely on the applications, but on plug-ins for these applications.
For some solutions, like AutoCad, the plug-ins have plug-ins. There is no method to provide, sell and deploy plug-ins for applications in the Mac App Store. You can argue that App Extensions can fill that functionality, and may even be more flexible than app-specific plug-ins, but they have certainly not been adopted on a large scale yet.
While macOS has improved how users discover and install drivers for printers, there is no way of managing driver deployment in the MDM spec. Administrators still have to deal with downloading and deploying printer driver installers and settings. The same is true for any other hardware driver software. While you can argue that the vendors sometimes seem to go out of their way to make driver deployment as complex as possible, even the best of them have no way of providing their software in the Mac App Store or manage it with an MDM.
This is but a short list of examples. I am certain any admin can easily list a many more. All of them have in common that Mac administrators need to use package installers and/or shell scripts to install and manage these solutions. Sometimes you can re-use the vendor installer, but even then you need to know how to inspect and verify these files. In many cases you have to reverse engineer the installation and re-build your own packages. (How to do all of this is covered in my book: “Packaging for Apple Administrators”)
As long as the Mac App Store has no manageable (VPP) solutions for upgrades, subscriptions and in-App-Purchases, it has to be considered broken for client management. Any such feature which gets added to the Mac App Store (such as subscriptions last year) have to have a VPP solution, otherwise it is useless for managed deployments.
The Mac App Store excludes entire categories of software because of the sandbox requirement, software providers. Users and admins still need a way to deploy that software. If Apple were to go ahead and lock down macOS completely, users and admins would have to either jailbreak their Macs, or abandon the Mac platform.
The number of users who would be affected by this is paltry, compared to the hundreds of millions of iOS devices Apple sells each year. So, the cynic will, “what does Apple care if a few hundred thousand users leave?”
A locked down macOS would provide little benefit over iOS running on an iPad Pro. A locked down MacBook may have more processing power (barely), and more ports for connecting hardware, but the software to use them to their full extent would simply not be available.
Apple wants to lock down macOS to make it more secure, because that distinguishes macOS from the other desktop systems. On the other hand, Apple has an interest in keeping macOS open because it is not iOS.
Apple has its own set of Mac applications that have no iOS counterpart: Xcode, Logic Pro X and Final Cut Pro. These are the ‘Pro’ apps, the lighter apps: GarageBand and iMovie have iOS counterparts. Swift Playgrounds which may be considered ‘Xcode lite’ is iOS only.
There are good reasons for each of these not being on iOS. Final Cut Pro and Logic Pro X rely very much on external hardware for input, most of which is not available for iOS. Xcode relies on integration with many command line tools (
git, etc.) to develop its full potential. There may be some projects within Apple that can be built without shell scripts, but I am sure they are in the minority. Just look at the
postinstall scripts of any Apple installer package.
Interesting Sidenote: Xcode, GarageBand and Logic Pro bypass the Mac App Store limitations by installing additional components at first run. Apple is hitting the limitations of their own rules. There is also no way of deploying these additional components with an MDM.
There are many people at Apple who use their Macs for graphic design, hardware design, running complex computations, writing shell scripts, compiling complex software and hardware drivers, and testing on virtual machines, etc. Do you believe Apple wants to buy them Dells so they can run Photoshop,
bash, AutoCAD, SPSS, or VMware? Apple also needs to deploy and manage the Macs in their retail stores. They are, after all, one of the largest deployments of their own OS.
So, assuming Apple is not planning to lock down macOS like iOS, what are they going to do?
They certainly will continue to restrict access by users and processes to security critical parts of the OS. They also want to gain (more) control of vectors where malicious software can inject itself into the system. Apple obviously wants to use MDM as the main conduit for Macs to be managed. The MDM spec already has the ability to deploy an custom package to a client. This is probably supposed to push client agents for management systems for features not included in the MDM spec (such as reporting).
Apple, third party MDM vendors and open source MDMs could build on this existing feature to provide package installation of software for non-App Store solutions. This alone would alleviate many concerns that administrators currently have. Maybe the packages will have to be signed with an Apple developer certificate or some other extra security step. (Learn how sign packages in my book.) This will require major re-architecting of many tools such as Munki, but those are do-able, maybe even desirable. The format the MDM spec is using to install software is, not surprisingly, a flat package installation file, so packaging skills will be needed more, rather than less in this scenario.
From my perspective, Apple’s choices are to obsolete the Mac platform, or to gradually keep improving security and working on the Mac App Store, VPP, DEP and MDM as management solutions while maintaining the openness that makes the Mac such a powerful and creative tool.
While I believe that ‘pro’ users of the Mac platform need to get accustomed to the fact that they are not Apple’s main focus anymore, I also refuse to believe that Apple is planning to obsolete the Mac entirely, because they would hurt themselves in the process.
The balance between security and openness will not be easy to find. The openness is what sets the Mac platform apart from iOS. The control and security is what sets macOS apart from the other desktop operating systems. There will be much back and forth between the ‘pro’ users and Apple. We as admins have to keep harping and nagging at Apple to do the right thing. (File bugs!)