WWDC 2022 Wish List

It’s Christmas in June for Mac (and iOS/iPadOS) admins. Apple’s World Wide Developer Conference 2022 is just a day away. It’s expected that we’ll learn about the new features and functionality of macOS 13 (rumored code-name Mammoth) and iOS/iPadOS 16, as well as updates to watchOS, tvOS, and perhaps the announcement of the realityOS for Apple’s future wearable VR devices.

At WWDC 2021, Apple surprised a lot of folks by (finally) adding a couple of major features that Mac admins had been asking about for years.

1. Erase All Content and Settings on macOS — making it very easy to reset a Mac to a fresh OS, and rapidly return it to service, just like iOS/iPadOS have had for years.
2. Provisional Enrollment of T2 and later Macs to Apple Business/School Manager — again, something iOS/iPadOS have had for years. It does require the AxM user be an Administrator or Device Enrollment Manager, but it works well (keeping in mind the 30 day provisional enrollment).

Apple also did announce the ability to manage/enforce updates via MDM (i.e. Install later, with deferrals and enforcement). However, this feature has not worked well, for multiple reasons:

1. The revised notifications on macOS 12 are a user interface disaster. The update notifications are larger than the default notification window size, leaving the most important information invisible without expanding the notification window. The expansion target is in the upper right corner, and small, so if you miss it by a couple of pixels, the notification disappears, with no way to bring it back.
2. The deferrals have been random/intermittent, particularly before macOS 12.3.
3. There is still no real “enforcement” of updates. Given the state of IT security these days, it’s more important than ever for admins to ensure that users are on the latest OS. Real, functioning update enforcement is possible on Windows, and it needs to also come to macOS. Most admins have resorted to adopting Erik Gomez’s Nudge tool for this purpose.

Besides redesigning/fixing notifications, and adding true update enforcement, here are a list of things that I’d love to see Apple address. This is not a list of things that I believe Apple will do, but it’s a list of things I’d like them to work on at some point.

1. Speaking of Software Updates… the fundamental process of updating software on macOS is completely broken, and has been since at least macOS 11, when fundamental changes were made to support Apple Silicon. The biggest issue is, there are situations where softwareupdated, the software update daemon running in the background on macOS, goes completely “out to lunch” and must be restarted (sudo launchchtl kickstart -k system/com.apple.softwareupdated). When this happens, the Software Update preference pane either spins forever, or it reports “No updates available.” After much hue and cry (and Feedback and AppleCare cases), has Apple fixed this in macOS 12.4? We’ll need to wait until a 12.4.1 or 12.5 release, but, having been burned by this over the past 18 months, it’s very frustrating trying to ask users to update, only to have them report back that their computer can’t find updates. Combined with the inability to enforce updates, mentioned earlier, this is a huge problem. There’s also things like the fact that software updates on macOS seemingly take forever, and, particularly on T2-based Intel Macs, shutdown stalls and freezing during bridgeOS updates leads to many issues, and (sometimes temporarily, sometimes permanently) bricked Macs.
2. There’s also the issue of MDM update and upgrade commands. Apple has pushed admins to leverage these for OS upgrades, yet the user experience has been and still is terrible, and, similar to the above, it’s also not reliable/repeatable.
3. Volume Purchase Program deployment on macOS is a complete Dumpster fire. Unlike iOS, where app deployment is predictable and reliable, neither are the case for macOS, and it’s been like this for years. As a result, I only use/recommend VPP on macOS for the Apple apps (iWork/Xcode), but, even then, I’ve had to stop using VPP to deploy Xcode as it is so unreliable/unpredictable. Xcode is definitely an edge case, being about 30 GB in size, but the user experience of deploying Xcode through Jamf Self Service is terrible. User clicks install, it processes for a few seconds, and then reports “Complete”. The user then looks for Xcode in their Applications folder, doesn’t see it, so clicks Install repeatedly, resulting in Duplicate Command MDM errors. The actual install of Xcode can take up to 4 hours, if it happens at all. One of the great things about VPP on iOS is that it’s pretty reliable and automatic — updates are deployed as devices check in. That is most definitely not the case on macOS. Remember the log4j vulnerability? That library was present in Xcode, and, while not exploitable, InfoSec folks do not like this showing up on their security scans. I could not determine when computers would receive the updated Xcode. It was far easier for me to just delete the older, unpatched app from systems to achieve compliance, and request the users to reinstall it (assuming that process worked), if they still required it. I’ve unpublished Xcode from our VPP and resorted to deploying and decompressing the .xip file from Apple’s developer site. Which, of course, means I need to re-deploy the whole 10+ GB XIP file any time there’s a version bump. This is awful.
   Another common issue is that there is no method to do In-App Purchasing for an app deployed via the Volume Purchase Program. It’s up to the vendor to potentially offer your organization a Business to Business app with the full functionality — assuming you are purchasing enough licenses to make it worth their while.
4. While we are discussing VPP, where is the ability to deploy Safari browser extensions in an automated fashion? Not supporting the ability to easily deploy required browser extensions relegates Safari as an also-ran browser status, after the juggernaut that is Google Chrome, Microsoft Edge, and even Mozilla Firefox. Also, given the inability to prevent all but specific extensions to be installed, makes it more likely that security-conscious organizations will completely block the use of Safari browser extensions.
5. MDM improvements… the core features of MDM were designed back in the days of iPhone Configuration Utility, came to macOS in 10.7 Lion, and have not significantly changed or expanded in that time. Based on the older Managed Client eXtension (MCX) technology, we lost the “Set Once” functionality. One major problem/issue with MDM and configuration profiles is, once you establish a setting, the user interface to change that setting is disabled for the user. While this is desired in some cases, it is not in others. For example, I’d like the ability to set a default dock, but let the user change it. However, deploying a profile to set that default dock, prevents the user from changing it.
   I’d also like to see Apple make changes to MDM so that it is more stateful/intelligent, and could be used moreso for configuration management (like Puppet on Linux). Apple did announce Declarative MDM at WWDC 2021, but it was light on details, and also limited, both in functionality and scope (only applicable to user-enrolled iOS 15 devices). I fully expect Apple to expand upon this for iOS and iPadOS at WWDC 2022, but macOS always seems to late to the party.
6. Improvements to Privacy Preferences Policy Control — introduced in macOS 10.14, this is the requirement to create profiles to allow applications to access folders or resources. I find that many admins still do not understand exactly how to approve/allow-list processes/network extensions, and go overboard with allowing too much functionality. Another issue, profiles deployed to a client do not show the allowed apps/services in the Security & Privacy preferences. Perhaps the rumored revamp of System Preferences in macOS 13 will change this, but the current situation isn’t great. Also, for end users, the experience of opening a collaboration tool, beginning a meeting, attempting to share one’s screen, having it not work, and having to futz around in System Preferences->Security & Privacy->Privacy, to enable Screen Recording or Accessibility, then have to quit the app and re-start the meeting, is not a good one. It would be logical if these kinds of applications could receive an entitlement to prompt the user for the required permissions, much like they can for Microphone or Camera access.
7. Full passwordless support — many organizations would like to move to fully “passwordless” solutions, utilizing either biometrics or smart cards. macOS is VERY close to being able to do this (Apple Silicon Macs allow smart card authentication at FileVault pre-boot; sadly Intel Macs do not), but there are still situations where a password is required, and TouchID or FIDO2 aren’t supported (WKWebView support, anyone?)
8. Shortcuts on iOS are very nice, and we have a lot of really smart users that have figured out how to use these to automate repetitive tasks. The issue is that Apple has not thought about enterprise deployment of shortcuts. The current solution to use iCloud to share/deploy them is… problematic in regulated environments. This is something that’s a clear advantage for Apple, yet they do not have a solution for widespread deployment of Shortcuts.
9. Fixing Feedback. For years, Apple has been preaching to admins to file Feedback (with an Apple ID associated with Apple Business/School Manager, not an Apple ID associated with a Developer account) as well as open an AppleCare Enterprise (if your organization has an agreement with Apple, which I find invaluable). In addition, if your concern is an urgent or critical one, your Apple SE has the ability to escalate your concerns internally (be aware you’ll be asked about the number of impacted systems). Perhaps Apple has been too successful in getting folks to report issues/suggestions/improvements, because it sure seems that Apple is struggling to keep up with the volume of reports. It’s frustrating to report something, then find out someone else also reported this, and received the response that “no other organization reported this” when clearly that’s not true. Submitting feedback sometimes feels like you’re screaming into the void, and is about as effective. I know Apple cares about security and privacy, but perhaps opening up their feedback somewhat (perhaps accessible to ABM/ASM Apple ID’s, and give organizations the option to make their feedback public or not) would be beneficial to everyone. People can more easily dupe/vote on feedback, or research there if they are experiencing issues (and refer to them in ACE cases and discussions with their SE’s).
10. I think an overarching theme here is the quality of Apple’s software releases. We’ve definitely seen improvements from the days of Catalina/early Big Sur, not to mention iOS 13 (as Hall and Oates sang, Some Things Are Better Left Unsaid), the broken state of software updates (which never worked right on macOS 11 and may have been fixed in 12.4) and update deferrals (not really functional in macOS 12 until 12.3). Features need to work reliably, or else they should not be in the OS, or the OS shouldn’t be released. Apple seems overly reliant on the admin community to report these issues, which we do, but given the problems with feedback referenced above, I question whether the information is getting to the right people. Or else, Apple is under-resourced to address these known issues before the OS is released.

A lot of folks believe that issues like the above exist because… “Apple does not care about the enterprise market.” I think that’s not at all true. Apple has taken a lot of steps to make the Mac more enticing to the enterprise market, and has also hired, and continues to hire, a number of people from the Mac admin community. Apple will not publish roadmaps, or compromise security and privacy, but has done things (like the Erase all Content and Settings, and Provisional Device Enrollment) that improve the Mac management and lifecycle. The question we are all waiting to hear, is if they will do more, and address many of the rough edges associated with managing macOS and iOS.