Starting in macOS 13.4, there is no longer a way for Mac admins to programmatically manage beta program enrollments. During the 13.4 beta cycle it was announced seedutil is deprecated, to be removed entirely in a future release, and the only path forward to enroll in beta programs being Apple IDs.

In the past, when working with static Mac hardware, I would add secrets to recipe overrides and keep them only locally on the Mac used to run AutoPkg. While still mostly insecure, at least those secrets weren’t also available in a code repo, and less prone to being compromised. With ephemeral CI runs though, this isn’t possible. A secret store which can be referenced at runtime, outside of the repo becomes necessary. Thankfully my colleagues at Gusto had encountered this before and already had a solution to avoid committing plain text secrets.

Troubleshooting technology issues this past year has been especially challenging due to the distance coronavirus has forced upon us. Getting good data to help our users has been more difficult when it’s not possible to be in front of their computer. Mac admins who have worked with Apple support or filed feedback know the very first data point usually requested is a sysdiagnose. No logs, no help. A sysdiagnose contains a voluminous amount of log files which can help pinpoint exactly what’s gone wrong with a Mac.

I’m going to try something different for this post. Instead of solving a technical problem or analzying an element of Apple device management, I’m going to propose a new feature. This particular feature has been on my mind since 2018 when I first opened an Apple enterprise support case asking product engineering to consider it for their future roadmap. Of course that’s mostly wishful thinking. What I want is not what everyone wants. Even years later though, I can’t shake the feeling this would help in a variety of scenarios. What I’m proposing is a managed AirDrop feature, and I hope after reading through why you’ll file feedback too.

Authorization rights on macOS determine are a core part of the security model which determine who can and can’t access specific functions. For example, system.preferences.datetime determines authentication required to modify Date & Time settings under System Preferences. A curious power user could cause a lot of harm changing authorization rights, and for the most should be left well alone. However, modifying authorization rights is particularly useful in granting standard users access to areas only admins can go by default.