Goodbye seedutil, hello Apple IDs

Published May 18, 2023 / 1396 words / ~7 minutes to read

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. Apple has taken away a long used utility relied upon by Mac admins and not given much back in return.

A short history

seedutil was a utility used to enroll Macs in beta programs - CustomerSeed, DeveloperSeed, and PublicSeed. Though I can’t pinpoint exactly when it was first introduced to macOS, a quick Mac admins Slack search shows it goes back to at least 2016. Rich Trouton first wrote about it in early 2018. Up until this past release, Apple used it in the macOS Customer Beta Access Utility, a payload free package (minus software license agreement PDF) wrapping seedutil in its postinstall script. To access CustomerSeed, Apple’s terminology for AppleSeed, one could run /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil enroll CustomerSeed, refresh Software Update, and the latest available beta would be available for install. Similarly, on iOS, a profile could be installed.

Apple has deemed this method antiquated and unfit for purpose. Though pessimistic, I am guessing primarily because individuals could bypass accepting terms, upsetting Apple’s lawyers. Anyone with knowledge of the command could enroll their Mac without also being a part of any AppleSeed or developer program.

The new path forward is to use an Apple ID with beta privileges to sign into System Settings > Software Update, after which beta program options are made available. When Apple announced the change I thought it a welcome addition to seedutil, given the potential difficulty for those not familiar with command line tools. However, my hopes were quickly dashed when I realized it marked seedutil’s demise. A speed run in the enterprise world, this may be the fastest Apple has ever deprecated a utility.

/System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil current
Currently enrolled in: DeveloperSeed

seedutil is no longer supported. Use Software Update to manage beta enrollment.

Legacy Program: DeveloperSeed
Is Enrolled: YES
Build is seed: NO
Asset Server URL:
NSShowFeedbackMenu: YES
DisableSeedOptOut: NO

seedutil wasn’t going away in the next major release or in 13.5 or “deprecated” like login hooks which continued to work for years. No, an important part of the Mac admin toolbox was being taken away within weeks of it being announced, and in the very same beta cycle. Apple had deemed incompatibility between old and new was too pronounced to keep the legacy tool around. Though always a private framework never meant for widespread public consumption, many used it to manage their Mac fleets anyway. Considering the short transition period, many felt the rug pulled out from under them.

In with the new

The new Apple ID enrollment method is straightforward, but not without its quirks. seedutil and Apple IDs don’t play nice together and if already in a beta there is some unexpected behavior. I found even after signing out of an Apple ID from within System Settings > Software Update I was still able to select a beta program. If a Mac is being enrolled in a beta for the first time using an Apple ID, that Apple ID must first accept terms from either AppleSeed or the developer program.

The existing profile keys meant to disallow beta access continue to more or less work. With AllowPreReleaseInstallation false in a profile payload, the option to enroll in a beta program doesn’t show up at all. If the key is set and a Mac is already enrolled, it will stay enrolled until manually unenrolled. If the key is set and a Mac is not enrolled, the option won’t be displayed. Running open "" opens the preference pane directly to prompt Apple ID sign in if required. If betas are not allowed, the warning below pops up.

Restrict beta enrollments with a profile

Where Apple IDs fall short

Though convenient for individuals, Apple ID driven enrollment does nothing to satisfy enterprise requirements. Where before management tools could wrap seedutil, now there are no options to manage enrollment at scale. Work has effectively been shifted to the user to reach the same end state. It’s somewhat common for enterprises to run betas on a small subset of their fleet in order to get ahead of issues before they reach a wider audience. Many organizations supported opting into a beta using an app like Jamf’s Self Service or Munki’s Managed Software Center. With these changes making it harder to enroll, the likely outcome is enterprises will test less frequently, resulting in more bugs making it out of beta.

seedutil was also used to report on current beta program state by parsing its output, with reading /Library/Preferences/ as an alternate option. Software update catalog URL is now the only signal available. MDMs can report on catalog URL and whether the catalog is default (not beta), but few do. mdmclient can be used to run a synthetic MDM command locally to report through something like a Jamf extension attribute, but again depends on a private API Apple may change or remove in the future.

/usr/libexec/mdmclient QueryDeviceInformation

OSXSoftwareUpdateStatus = {
    AutoCheckEnabled = 1;
    AutomaticAppInstallationEnabled = 1;
    AutomaticOSInstallationEnabled = 1;
    AutomaticSecurityUpdatesEnabled = 1;
    BackgroundDownloadEnabled = 1;
    CatalogURL = "";
    IsDefaultCatalog = 0;
    PreviousScanDate = "2023-05-15 13:36:50 +0000";
    PreviousScanResult = 2;


As an IT engineer managing a fairly large fleet, the sudden seedutil removal caught me off guard. And, as anyone doing this long enough knows, the only avenue Apple provides for enterprise customers to make their voice heard is Feedback Assistant. Feedback FB12112616 has been filed asking for either a MDM command or profile key. If you have similar needs around beta program management, considering duping the feedback below.

Apple has no responsibility to maintain a private tool not intended for IT admins, but it has been used that way and broadly across many large enterprise organizations. With the new Apple ID driven beta program enrollment, the burden of downloading and installing beta software is now on the individual user, and cannot be controlled by an admin, either through MDM or a CLI tool. It is a common workflow for enterprises to use seedutil to enroll a subset of their Macs into a beta program in order to test new releases before they hit the entire fleet. In our case, we use a config management tool to report on (/Library/Preferences/ and set (seedutil) a Mac’s beta program for around 5-10% of our deployment. There have been times when software engineering teams have been caught off guard with breaking changes because they didn’t have the opportunity to test beta releases. With betas more widely used we can get ahead of these issues and resolve them before they reach the rest of the org. The benefit here has been tremendous, especially since users have to do nothing in order to be enrolled. Our tooling, which wraps around seedutil, does it all for them. By requiring Apple IDs in order to access beta software, the burden shifts to the user. Where before they had to nothing, they now are required to take multiple, unfamiliar steps for the same access. As an enterprise we still need to be able to easily configure beta programs programmatically, without user interaction.

I am specifically asking for MDM enrolled, supervised devices to be able to be enrolled into a beta program using MDM. Below are ideas, not requirements. I would be equally happy with either choice.

  • Implement a new key in the payload specifying beta program. Something like setBetaProgram where the options are CustomerSeed, DeveloperSeed, and PublicSeed.
  • Add a new MDM command called ConfigureBetaProgram which, wait for it, configures the beta program for a Mac. Using a command, it would not be possible for someone to install a profile locally to get access. Whichever MDM based method is used to grant beta program access, also make it possible to get the current status. With seedutil and /Library/Preferences/ going away, there will soon be no way to determine if a Mac is in a beta program, and if so, which one. Both of the below would be preferred.
  • Write current beta program state on disk somewhere to a plist.
  • Add a new field returned to MDM when device information is polled indicating current beta program.