WWDC 2023 Wish List
Apple’s World Wide Developer Conference is fast approaching (the keynote will be streamed on apple.com at 10 a.m. PDT on Monday, June 5, 2023). With this annual announcement of new Apple operating systems, including macOS (14), iOS (17) and iPadOS (17), rises the hopes and dreams of the folks who manage these computers and devices for a living.
Below is my wish list of features/functionality that I’d like to see addressed in the new OSes, predominantly macOS. To be clear: this is not what I expect Apple to announce/release, but what I’d like to see to make the job of being an Apple admin easier. Let’s get to it!
1. A softwareupdate function that works repeatably and reliably to present the user with pending updates. This functionality has been broken and unreliable on macOS since macOS 11 and the changes revolving around Apple Silicon (volume ownership). Yes, we’ve gone 3 major OS revisions without a reliable way for users to see/install available OS updates. The fact that this has dragged on this long is inexcusable, and it would do Apple well to ensure this critical functionality is 100% bulletproof BEFORE macOS 14 ships this fall.
2. The ability to ENFORCE OS updates and upgrades. Combined with the problems with being able to view pending updates, admins have personally spent way too much time chasing down users to update their Macs to the latest OS, with the latest security patches. We were given the “Install Later” MDM commands/functionality in macOS 12, but, sadly, there’s no ”teeth” here, and the update-or-defer dialogs were intermittent/inconsistent. Time for another approach that doesn’t revolve around third-party tools like Nudge https://github.com/macadmins/nudge or super https://github.com/Macjutsu/super
3. The ability to ENFORCE a minimum OS version during enrollment into an MDM (i.e. macOS 13.4 or later only). When one’s security posture is such that you want all devices on the latest OS, and you have devices enrolling into your MDM that have sat on a shelf or warehouse somewhere, and enrolled running macOS 12 or iOS/iPadOS 15, that’s a problem. There must be a compromise to allow OS upgrades or updates during the enrollment process (we’ve even seen this with specific models like the first Mac Studio, where it undergoes a software update during Setup Assistant). I recognize that this may prove challenging with Apple’s non-enterprise consumer workflows, but c’est la vie.
4. Improvement in the user experience of MDM update (minor OS version) and upgrade (major OS version) workflows. The current process of sending MDM commands, hoping and/or praying that they work, and having the users’ Mac spontaneously reboot to apply the updates is NOT a great user experience, which is ironic, since that’s something that Apple is generally known for. Also, being able to schedule update windows/times. In general, MDM update/upgrade commands tend to behave inconsistently/unreliably, which is problematic when there are so many OS releases.
5. Platform Single Sign On was announced in macOS 13, but we’ve yet to see a single vendor ship a compatible product. One of the Achilles heels of the current implementation is the inability to create a user account dynamically during first login. Hopefully there will be some method to do so in the future.
6. Increased federation options with Apple Business/School Manager. AxM has had the ability to federate with Azure AD, but only in Commercial, not in Government Compute Cloud (GCC) High (FedRAMP). Apple also introduced support for federation with Google Workspace, but those users of other IdP’s like Okta or JumpCloud could benefit from this. Instead of Apple having to build this support, there is a new OpenID Connect federation standard. In this case, Apple would need to add support for OpenID Connect to AxM, and let the Identity Provider vendors actually build the support. This is a critical need for many organizations, and making the vendor do some of the work should help increase the number of federation options.
7. Alongside federation comes Managed Apple IDs. These are essential for many workflows (such as user-based enrollment or shared iPads), however they are so restricted (no e-Commerce/App Store support, no Apple Pay, HomeKit, iCloud Keychain, Sidecar, Handoff support, etc). These were designed for a specific (educational) use case, but their use is required outside of those environments. Ideally each org would have a “control panel” in AxM that would allow them to selectively enable/disable features, either tenant-wide, or per federated directory group.
8. Besides improving the functionality of Managed Apple IDs would come the requirement (for macOS/iOS/iPadOS) to enforce that users can ONLY sign into their corporately-owned and managed device using a Managed Apple ID.
9. There are many situations (use of Migration Assistant? Users deleting MDM cert from the system keychain?) where a computer’s MDM enrollment may break. Prior to MDM, we had the CasperCheck tool: https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/
It would be great if there was an automated way to kick off re-enrollment into the same MDM, without going through the full enrollment process (and yes I recognize the security concerns about silently enrolling devices into an MDM, but in this case, we want to re-enroll a device, which is also in AxM). . This would prevent a lot of “erase-and-reinstall” situations when this functionality breaks. Thanks to Rich Trouton for this suggestion.
10. Make Apple’s Volume Purchase Program work reliably on macOS. I’ve touched on this repeatedly in prior years, but there’s been no change. As well as VPP works on iOS/iPadOS, it does NOT work reliably or consistently on macOS, as anyone who’s attempted to use this method to deploy and keep Xcode current will tell you. I tend to avoid deploying VPP apps on macOS for this reason.
11. While on the topic of VPP, where is the ability to deploy Safari browser extensions in an automated fashion? No ability to deploy, or restrict, Safari extentions relegates Safari to an also-ran in the browser wars, and why many orgs enforce Google Chrome or Microsoft Edge as default browsers on macOS. Also, given the inability to control what extensions can be installed, it’s far more likely that security-conscious organizations will completely block the use of Safari browser extensions.
12. There’s still no solution for VPP and in-app purchasing, except to reach out to the developer and ask them to build a B2B App Store version of their app, with the additional functionality enabled. This is something many developers won’t do unless you’re planning to buy hundreds of licenses of an app, as it may not be the best use of their time.
13. Additional functionality for app developers with the appropriate entitlements to request/prompt the user for permission to record the screen, or accessibility. I would love for someone to sit Tim Cook in front of a new Mac and have him sign into Microsoft Teams, join a call, and share his screen, and all of the steps/dialogs and quitting and re-opening apps. Again, for a company known for great user experiences, this isn’t one.
14. Changes to Passkeys to increase their security posture. First, the implementation of Passkeys on iOS/iPadOS/macOS requires the use of iCloud Keychain, which doesn’t currently work with Managed Apple IDs, and cannot be used in highly-regulated environments. Secondly, there’s no control over the sharing of passkeys, which is less-than-ideal in a corporate environment. Being able to restrict them from being shared would greatly help with enterprise adoption.
15. Shortcuts are awesome, particularly on iOS/iPadOS! However, Shortcuts cannot easily be deployed (typically requiring signing into multiple devices with an Apple ID), and they are not portable across devices, even if you have the same suite of apps installed. These issues need to be addressed before Shortcuts can be more widely used in enterprise — which is a pity, because you can do some awesome things with them.
16. Apple has deprecated the OpenBSM/auditd framework, used by many organizations to log specific events from macOS to their logging service. Some additional functionality has been added to the Endpoint Security Framework, but it’s incomplete compared to what’s available in auditd. Hopefully, Apple expands the logging in ESF to match auditd before that is fully removed from macOS. Thanks to Robert Gendler for the suggestion.
17. Too many things are not easily able to be managed by configuration profiles. Sure, you may be able to determine what key needs to be set, and create a custom profile, but there’s usually a lot of research/testing to find these keys, if they exist and work. For example, while there are automatic download and update settings on iOS/iPadOS, and they’re enabled by default, there’s no current ability to control these settings with an MDM profile. If you’re sending devices to places where bandwidth is low/constrained, you need the ability to disable this functionality, but they’re not in the MDM Restrictions for iOS/iPadOS.
18. While we’re talking about profiles, when Apple moved from MCX to configuration profiles for configuration management, one critical feature was lost. Set Once. The problem with deploying a configuration profile to manage settings is, it disables the user interface entirely from being able to change any of those settings. Many times that’s desirable, but there are certainly common use cases (like the Dock, or Energy Saver settings), where one would like to be able to use a profile to establish a default dock, or power settings, but also allow the user to customize/change it, and that’s not currently possible, unless you use scripts to perform these tasks.
19. Apple’s new method of signing into a device to access betas (RIP seedutil) is not a bad idea, but it’s not fully implemented. There’s no way to deploy a profile to specify a specific beta program (i.e. AppleSeed for IT/CustomerSeed, versus Public Beta, or Developer). It would be great if we could also enforce that you can ONLY sign into the beta program with a relevant Apple ID (i.e. Managed Apple ID, personal Apple ID, or Developer Apple ID, respectively).
20. Feedback — Apple’s standard mantra of “Have you filed Feedback?” any time a bug or unexpected behavior is reported, is getting tiring, particularly when:
a. multiple people/organizations are reporting the issue, and
b. many of them may have already filed an AppleCare Enterprise OS support case.
Asking for both seems like a lot to ask the busy-keeping-up-with-Apple admins. Why is either method not a valid way to report issues with Apple software? These systems should work together, not be islands with no real interoperability. If ACE has given me debug profiles, asked for a screen recording, and a sysdiagnose, why does one need to repeat the same steps/process for feedback? Also, when there’s a critical bug or design issue, having to solicit many people to file feedback to get it addressed, should not be required (and can and has overwhelmed Apple with feedback). Fixing critical, major bugs should not be a popularity contest. New feature or functionality request? Different story.
21. Improvements to Apple Enterprise OS Support — I frequently receive reports from users that I am not able to replicate, but do not doubt they are seeing the issues. I will create an ACE ticket, and receive the usual request for debug profiles/screen recording/EDC or sysdiagnose/first-born child, and will ask the user to follow through with then. Half of the time, the users don’t follow through, but half of the time, they do, but they must send all the logs/movies/sysdiagnose to me, and I have to spend time as intermediary download and adding these to the case. It sure would be nice if there was a Feedback Assistant-like app that could handle submitting files to a specific AppleCare case, assuming the case ID was known.
22. Improved Apple Software Reliability and Testing — I’m not sure what others’ experiences have been with macOS 13 and iOS/iPadOS 16, but mine have been more problematic than the previous generation of Apple OSes. Whether it was the ongoing softwareupdate issues, the “My Mac Boots Into Recovery After Updating macOS” reports, or smartcard/PIN lockout issues, or issues with HDMI output with macOS 13.3, or just general confusion about OS update and deferral workflows, macOS 13 has not at all been smooth sailing (in a recent review, I noted 7 AppleCare Enterprise OS Support cases in the last couple of months that all came back to acknowledged issues/defects in the OS). I know Apple cannot replicate every workflow that we as admins use, and they push those of us in Enterprise very hard to ensure we help them by testing their new OS releases with our workflows, not just in the summer, but all throughout the year. Unfortunately, that’s not enough. There’s no reason a company with the financial resources of Apple cannot do a better job of QA’ing their products before release. And not just the major releases, either.
23. This brings about an oft-requested topic. The relentless pace of yearly OS updates has led to many of these design or implementation issues. OS X 10.6 Snow Leopard was an OS release that focused on stability and performance, and not new features/functionality. As macOS has gone through numerous major architectural and process changes in recent versions, it seems like it would be beneficial for Apple to spend a significant amount of time over the next year focusing both on stability/reliability, as well as polishing many of macOS’ rough edges.
Here’s hoping at least some of these “wish list” items come true at WWDC 2023.
