WWDC 2020 Wish List

Today is Apple geek Christmas. In just a few hours, Apple will announce the next versions of iOS/iPadOS and macOS. As someone who’s made a living for a number of years helping organizations manage their Apple device ecosystem, I’m both excited, yet apprehensive about what Apple will be announcing.

Excited, because Apple is moving the platforms forward, with a strong focus on security and privacy. Apprehensive, because many of the changes in the last several OS revisions have been problematic with either/both design errors (i.e. SecureToken, Privacy Preferences Policy Control have been difficult to administer at scale) and/or poor implementation (iOS 13 and macOS 10.15 Catalina have been among the buggiest general-purpose OS releases Apple has ever done).

On to the anticipated and hopeful changes….

1. ARMageddon. The expectation is that Apple will officially announce a migration of the macOS platform to their own custom ARM processors similar to the ones used on iOS devices. Apple has been telegraphing this move for years, and this explains the choreographed series of moves behind many of the recent changes in macOS (modern filesystem, deprecation of kernel extensions and 32-bit apps and plug-ins, the addition of Project Catalyst to allow multi-platform apps, as well as heavily pushing both individuals and organizations to adopting the newest macOS quickly). The big questions I want to know are:
   a) Is there an application translation layer like the old “Rosetta” technology used during the PowerPC to Intel transition, that will dynamically convert Intel-native code to ARM?
   b) Or is the plan to push developers to recompile their apps for ARM, and release another generation of “fat” (aka Universal) binaries?
   ARM holds a lot of promise, both in performance (Apple not being dependent on Intel) and in power consumption/battery life (I anticipate we’ll see MacBook Pro’s with OLED displays and real-world battery life lasting for more than 12 hours).
2. Erase All Content and Settings for macOS. As someone who manages thousands of iOS devices, the ability to easily wipe a device to return it to a known-good factory-fresh state is extremely underrated. Re-provisioning macOS is a much more painful process, typically situated around Recovery/Internet Recovery, with considerations for firmware passwords, FileVault/unlock, and various Installer issues. Apple took a big step towards this in macOS Catalina with segregating the OS to its own read-only partition, with user data on a separate partition, just like iOS. It will be interesting to see if they find a way to easily return macOS devices back to a state where they can easily be re-deployed.
3. Improvements to Apple’s Mobile Device Management on both iOS and macOS. Apple introduced the concept of MDM on iOS first, and ported this functionality back to macOS 10.7 Lion in 2011. Managing iOS at any scale has always required MDM functionality, but it’s only been since macOS 10.13 that an MDM has become an essential requirement to manage macOS devices as well. The problem is that the current functionality of MDM on both macOS and iOS is showing its age, and it’s almost as if MDM needs to be totally refactored under the hood to ensure that devices actually receive the commands/profiles that are pushed to them (it’s quite a bit of a black box). MDM is not stateful; it can toggle settings, but it cannot re-evaluate them to ensure that settings are always enforced. On macOS, there is a lot of functionality that one can do with a user agent (ie jamf binary) that’s not possible currently over MDM. On macOS, MDM was based on the old MCX preference management, but we lost the “Set Once” functionality (i.e. establish a default user Dock, but still allow the user to change it). That kind of granularity is missing from the current MDM spec. So, too, is the ability to “pre-stage” MDM functionality, i.e. deploy a profile with management settings for macOS 10.15 before installing the OS upgrade. And, the update, and update deferral options, for both macOS and iOS need to be totally re-designed. Admins need the ability to enforce update- or upgrade-by dates (both number of days, or a drop-dead date) as well as restrict/defer updates or upgrades (right now it’s by an incremental number of days, up to 90, but this needs to be a lot more flexible, i.e. don’t allow upgrades before Jan 1 (end of year change freezes), or until June 1 (don’t allow upgrades during a school year, at least in the US).
   Custom preference management via MDM is possible in macOS, but often times as an admin you spend 95+% of the time finding the right preference key to manage, and testing it to confirm it works correctly, and only 5% of the time actually building the profile. Basically, anything that’s a preference in System Preferences should be manageable via MDM (not to mention all of the items in the CIS and NIST STIGs), and third parties (*cough*Adobe*cough*) need to be strongly encouraged to adopt MDM management of preferences. AppConfig on iOS is pretty neat; would be nice to see something like that on macOS as well.
4. It’s the stability, stupid. Paraphrasing James Carville’s comments about the economy from the 1992 presidential election campaign, this is a serious point that Apple has dropped the ball on, culminating in the extremely buggy iOS 13 and macOS 10.15 releases. Neither product was stable enough to be released when they were; iOS was painted into a corner due to the dependence upon new hardware, but macOS also shipped well before it was anywhere close to stable. Subsequent OS releases have improved things, but introduced their own bugs (I personally experienced more kernel panics with macOS 10.15.4 than I’ve had in the previous 2–3 years, and it wasn’t security software or a hardware problem). Apple is trying to push orgs to adopt the latest OS ASAP; on iOS, this is usually fine, as if there are problems with the update, Apple will generally pull it and/or release a fixed version quickly, whereas the pace of macOS releases is much slower (.1 release within 30 days of general release, then a new update every 45–60 days). The problem is when Apple releases a macOS update with bugs, you’re usually stuck with that release for another 2 months before the next release, which likely has its own set of issues (currently plagued with a bug that resets the computer/hostnames after a Catalina update — which Apple claims they won’t fix until the next major OS version this fall. C’mon, man!).
5. Changing macOS update naming. One confusing aspect of managing macOS is versioning… all modern OS releases have been 10.something, with versioning including major/minor releases, i.e. 10.15.5. But, Apple has sometimes released “Supplemental update” fixes and/or hardware-specific releases, where one has to determine the Build Number.
   It’s probably beyond time for Apple to drop the “10” and just go to a new version. macOS 11 code name Spinal Tap (“This one goes to 11”)? Or perhaps 16 (after 10.15)? Dropping the 10 could bring us to a more iOS like version numbering scheme, ie 16.0.1, 16.1, 16.1.1, 16.2, et. al.

Overall I enjoy using the macOS and iOS platforms as they align well with my concerns about security and privacy. Having said that, I have to admit that I have not enjoyed managing macOS and iOS platforms in recent years, due to all of the significant changes (many not well designed, or poorly implemented) and stability issues. Admin fatigue is real, y’all; and the “yearly releases with tons of changes, keep an eye on all of the moving pieces” seems to have strongly tested Apple’s ability to deliver stable, usable, and manageable systems.

Here’s hoping for improvements all around in the new releases.