How to script System Settings on macOS Sonoma

I’ve been tracking and cataloging all the different components of System Settings for a while now, and now that the latest version of macOS is out in the wild, I wanted to dive into macOS Sonoma and see if anything new was worth noting in System Settings.

System Settings remains nearly exactly the same as it was in macOS Ventura as far as high-level sidebar categories go, but if you dig deeper you will find a few new sub-menu items that you can open with a shell script. Let’s take a deeper look at what’s new.

Continue reading How to script System Settings on macOS Sonoma

Four ways to determine if macOS Rapid Security Response updates have been installed on your fleet.

Well, it happened. Apple has used the macOS Rapid Security Response feature for the first time since announcing it at WWDC.

It’s designed to enable quicker and more frequent security patching for the latest Apple operating systems, especially for WebKit-related flaws that affect Safari and other apps that use Apple’s built-in browser engine. If you’re looking for additional reading on what RSR is and how it works, the articles below are a good starting point:

It’s worth noting that this specific update is only available to the latest version of macOS 13.3.1, and that Apple has stated that security updates and patches may only be available to the latest versions of macOS moving forward.

If that doesn’t drive some urgency to update your Mac fleet, I don’t know what will. But how do you determine which computers have been successfully patched?

If you look up the macOS version on a patched mac with sw_vers -productVersion, it still reports 13.3.1. Same with inspecting /System/Library/CoreServices/SystemVersion.plist. If you click on About This Mac, the window does properly list 13.3.1 (a), with the (a) indicating that the Rapid Security Response update has been applied.

How do we determine if the Rapid Security Response update was installed programmatically?

Here are four different options:

1. Use sw_vers ProductVersionExtra

sw_vers now includes a new key titled ProductVersionExtra after a Rapid Security Response update is installed. If you run /usr/bin/sw_vers on a machine that has been updated, you’ll see the following output:

% /usr/bin/sw_vers

ProductName:		macOS
ProductVersion:		13.3.1
ProductVersionExtra:	(a)
BuildVersion:		22E772610a

So with /usr/bin/sw_vers -ProductVersionExtra, you can determine if the Rapid Security Update has been applied to 13.3.1.

2. Use system_profiler SPSoftwareDataType

You can also use system_profiler which does display the fully patched version number with the (a) identifier.

% system_profiler SPSoftwareDataType

    System Software Overview:

      System Version: macOS 13.3.1 (a) (22E772610a)
      Kernel Version: Darwin 22.4.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: Brian's Computer
      User Name: Brian
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 13 minutes, 51 seconds

If you wanted to extract the System Version number, you could awk it out using system_profiler SPSoftwareDataType | awk -F ': ' '/System Version/ {print $2}'

% /usr/sbin/system_profiler SPSoftwareDataType | awk -F ': ' '/System Version/ {print $2}'

macOS 13.3.1 (a) (22E772610a)

3. Use system_profiler SPInstallHistoryDataType

Alternatively, you can use the system_profiler SPInstallHistoryDataType command we discussed a few weeks ago to determine if the update was installed and recorded in the machine’s update history.

% /usr/sbin/system_profiler SPInstallHistoryDataType | grep "13.3.1 (a)"

    macOS Rapid Security Response 13.3.1 (a):
      Version: 13.3.1 (a)

4. Use softwareupdate –history

The softwareupdate command contains a --history flag that can show a history of everything installed via Apple’s software update mechanism.

% /usr/sbin/softwareupdate --history | grep "13.3.1 (a)"

     macOS Security Response 13.3.1 (a)      13.3.1 (a)     05/02/2023, 23:26:10

Or if you’d just like to grab the version number without the title of the update, you can use awk.

% /usr/sbin/softwareupdate --history | awk '/13.3.1 \(a\)/ {print $4, $5}'

    13.3.1 (a)

How critical is this update?

The words “Rapid” “Security” and “Response” sure make it seem critical, but the truth is that as of this writing, Apple has not revealed what the update is patching. This is also the first time we’ve seen a Rapid Security Response update from Apple, so I imagine as time progresses, we’ll get a better sense of what these updates contain and how much importance and attention you should give them.

How do I get users to update?

Use whatever methods you’re using now to encourage users to upgrade macOS. That might include a company-wide email, an @here mention in Slack, a built-in feature of your MDM, a third-party tool like Nudge or Superman (they are currently working on RSR support), or a simple script like the one below.

# RSR Checker |
# Check if macOS Rapid Security Response is installed.
# If not, prompt the end-user and open the Software Update pane.

dialogMessage="Apple has issued a critical security update. Please run Software Update ASAP!"

rsrUpdate=$(/usr/sbin/system_profiler SPInstallHistoryDataType | grep -m1 "13.3.1 (a)")

if [[ -z $rsrUpdate ]]; then
  echo "macOS Rapid Security response not detected. Encouraging user to update..."
  /usr/bin/osascript -e 'display dialog "'"$dialogMessage"'" with title "'"$dialogTitle"'" with icon POSIX file "'"$appIcon"'" buttons {"Okay"} default button 1 giving up after 15'
  echo "$rsrUpdate is already installed."
  exit 0

Want a fancier version of the script above? Let me know, and I’ll build it out a bit and publish it to GitHub.

All of this is a great reminder of the emphasis Apple has put on making sure your Mac computers are on the latest version of macOS, as those are the only machines that will be able to receive these Rapid Security Response Updates.

Happy patching, and happy adminning!

Looking for more RSR discussion? Check out Trevor Sysok’s blog post, expanding on some of the topics written here.

How to Identify macOS Update History

As an admin, you may need to look up a list of previously installed software updates for a device. You can do this pretty easily with system_profiler and the SPInstallHistoryDataType command.

/usr/sbin/system_profiler SPInstallHistoryDataType

This will spit out a complete list of updates installed on the device and their source and installation date, sorted by date.


      Version: 4.25.0
      Source: 3rd Party
      Install Date: 3/29/22, 8:12 AM

    Apple Configurator:

      Version: 2.15.1
      Source: Apple
      Install Date: 3/29/22, 12:03 PM


      Version: 12.0
      Source: Apple
      Install Date: 4/7/22, 8:41 AM

    macOS 12.3.1:

      Version: 12.3.1
      Source: Apple
      Install Date: 4/10/22, 12:22 PM

This is useful, but let’s say I want to only show macOS update history. In fact, I want to precisely determine, “Has this device updated to macOS Ventura from a previous version of macOS?”. If not, then it likely came preinstalled with macOS Ventura or has been wiped and restored with macOS Ventura.

So let’s dive in and figure out how we can accomplish our end goal…

Continue reading How to Identify macOS Update History

UnActivation Lock v1.5

In last week’s post on how to disable and prevent user-based Activation Lock, I highlighted a script that I wrote that can prompt users to log out of Find My Mac if a Mac has Activation Lock enabled, which allows the MDM to put a “disallow user-based Activation Lock” key in place on the machine. (If you’d like a deep dive on Activation Lock, I’d encourage you to re-visit that blog post).

With the initial release of that script pushed out the door, I got to work on the improvements I wanted to add for the next revision. In addition to my own list, I also included some feedback and feature requests that I received from the mac admin community.

If you want to download the latest script, you can find it on GitHub. If you want a breakdown of the changes, keep reading.

Continue reading UnActivation Lock v1.5

A Guide to Disabling & Preventing iCloud Activation Lock

It’s time for an adventure down the rabbit hole that is iCloud Activation Lock!

Apple’s iCloud Activation Lock feature is one of those features from Apple that is great for personal users and device security, but can be an absolute pain for admins.

I have spoken to many an admin who has a pile of MacBooks or iPads sitting in their office that are activation locked, sometimes with no method of recovery for getting back into those laptops. It’s such an issue that oftentimes perfect useable laptops have to be sold for parts because they cannot be re-used without the Activation Lock being removed from the device.

How do these devices get activation locked by users in the first place?

Keep in mind, there are two types of Activation Lock (device-based and user-based).

From Apple’s documentation:

There are two types of Activation Lock available to organizations:

Device-based: Device-based Activation Lock requires Apple School Manager, Apple Business Manager, or Apple Business Essentials and is generally simpler to manage for organizations. It enables MDM to fully control enabling and disabling of Activation Lock through server-side interactions.

User-based: User-based Activation Lock requires the user to have a personal iCloud account and for them to enable Find My. This method allows the user to lock an organization-owned device to their personal iCloud account if the MDM solution has allowed Activation Lock.

I will be focusing on user-based Activation Lock in this post (Device-based Activation Lock as of this writing, only applies to iPadOS and iOS).

I’m going to break this blog post into two sections: Steps you can take for devices that are already activation locked, and some thoughts on how to prevent Activation Lock in the first place.

Continue reading A Guide to Disabling & Preventing iCloud Activation Lock

How to open every section of macOS Ventura System Settings

Awhile back I wrote about identifying panes in System Preferences in order to figure out how to deep link directly to specific parts of System Preferences. That resulted in a near complete dictionary on how to open nearly every single section of System Preferences via script in macOS Monterey.

macOS settings have changed drastically in macOS Ventura, bringing with it a new name (System Settings) as well as a unified visual interface that has been a bit divisive among the apple community. A recent post from Rich Trouton reminded me to take a look at System Settings now that macOS Ventura has been released, and create a revised list that reflects the changes that were made in the latest operating system.

You can find the complete compiled list of macOS Ventura’s System Settings here.

A few observations regarding the new System Settings:

  1. Apple seems to be using a new “extension” schema for items in System Settings as referenced by the new .extension naming you see in the screenshot below. However, some of the bulkier sections of the app have maintained their previous .preference schema, particularly Privacy (open " and Accessibility
  2. Even though the new app is called System Settings, the URL scheme still retains it’s systempreferences designation of x-apple.systempreferences
  3. Apple is still mixing .preference and .preferences in their URL schemes, although most of that comes from legacy stuff that is still compatible.
  4. All sections of System Settings support URLScheme now! In Monterey, it was a mixed bag and depended on if an individual pane supported URLSchemes or not.
Continue reading How to open every section of macOS Ventura System Settings

ScreenNudge: A method to approve macOS Screen Recording

It’s time for an adventure in macOS screen recording approval! This is a journey I’ve been on for many years (since early 2020) and the result is the script presented here that I have tweaked and refined over that time period.

Many Mac admins are well aware that as of macOS Catalina, Apple has required explicit end-user input to approve an application’s access to a Mac computer’s screen. This has created a bit of a pain point for admins who want to ensure that screen recording (for remote support apps for example) gets approved BEFORE they need it.

The inability to preapprove screen recording can also result in a frustrating experience for the end-user. Imagine a new employee on their first day, trying to join the Zoom meant for onboarding new employees, only to discover that Zoom requires them to grant access to Screen Recording if they want to share their screen to get assistance from the onboarding team. Now they have to exit the meeting, navigate to the Security & Privacy pane of System Preferences, go to the Privacy tab and locate the appropriate section where they need to grant approval. This can be a lot to ask of some users, particularly those users who are not super savvy or comfortable with the macOS operating system. (This was another one of the reasons for writing this script).

Because of this, most admins will walk a new employee through the process of approving app access to screen recording on their first day or include it as part of their new employee computer setup documentation. However, as an admin, the more you have to explain and walk someone through a process, the farther you get away from a true “zero touch” deployment.

It was with this in mind that I created a script that would help guide the end-user directly to the System Preferences pane1 they need and prompt them with appropriate instructions. It includes built-in persistence and will repeat that prompt until the app becomes approved and then automatically close System Preferences if the user has left the window open. This script is best paired with a PPPC Profile that sets that bundleid of the application to “Allow Standard User to Approve.” That way, the checkbox can be clicked without requiring the user to unlock the System Preference Pane first, thus removing a step for the end user.

Here’s what it looks like:

ScreenNudge prompt in action. Requesting user to approve Screen Recording.

“Wow, sounds great! Where can I get it?”

– Mac Admins

I’m glad you’re excited! The script can be found here.


  • This script runs on macOS 10.15 or higher. macOS 11 or higher is required for standard user approval (that MDM command was made available in Big Sur.)
  • The script works best when the app being targeted is being deployed with a Privacy Profile library item that lets standard users approve Screen Capture. (Available in macOS Big Sur 11+).
  • The MDM agent running this script needs Full Disk Access in order to read the tcc.db and confirm screen recording has been approved. Most MDM agents have this access by default (check the MDM Profile installed on the machine in System Preferences > Profiles), but if your specific MDM does not, you’ll want to grant it access with a PPPC Profile.
Continue reading ScreenNudge: A method to approve macOS Screen Recording

How to identify the Bundle ID for macOS and iOS applications

It’s time for an adventure in app bundle identification!

As a Mac admin there are times where you need to find the Bundle ID of a macOS or iOS application. This might be for an app config, if you’re blocking an app by its bundleid (oftentimes more reliable using a file path), or if you’re configuring PPPC Profiles for an application..

Finding macOS App Bundle IDs

Method 1 – Using Terminal

Finding an app’s Bundle ID on the mac is pretty straight forward. All you have to do is open Terminal and enter the following command:

codesign -dr - /path/to/

Pro Tip: You can drag and drop your app into Terminal right after the codesign -dr – to get the full path of the application.

It will spit out both the certificate leaf and the Bundle ID. I mention this method first because usually when admins are trying to look up a Bundle ID it’s for creating a PPPC Profile, and that usually requires the certificate leaf as well.

In the example output below I can see the Bundle ID for Brave Browser is com.brave.Browser

Everything past the designated => will be your certificate leaf which you’ll need if you’re building a PPPC (Preferences Policy Control) Profile.

$ codesign -dr - "/Applications/Brave"

Executable=/System/Volumes/Data/Applications/Brave Browser
designated => identifier "com.brave.Browser" and anchor apple generic and certificate 1[field.1.2.840.113635.] /* exists */

Method 2 – Info.plist

You can also find an app’s Bundle ID by inspecting its package contents. Right-click on the app you want to retrieve the bundle ID for and choose Show Package Contents.

Inside the Contents folder is an Info.plist. This will contain a CFBundleIdentifier key containing the Bundle ID in its key value.

If you want to script the identification of a Bundle ID, you can also read the CFBundleIdentifier key value pair with a piece of code using something like PlistBiddy or other tools that can read plists:

$ /usr/libexec/PlistBuddy -c 'Print CFBundleIdentifier' "/Applications/Brave"


Finding iOS App Bundle IDs

What about iOS/iPadOS/tvOS Apps though? Finding the bundle ids for those doesn’t have to be hard. The easy way is to use one of the following websites:

If you can’t find what you’re looking for using the above options, you may have to look for the Bundle ID yourself. Navjot Virk has a great post on how to find a bundle ID of an iOS app.

Identifying System Preferences Panes

It’s time for an adventure in identifying macOS System Preferences Panes!

In my previous post I talked about the different ways that admins can deep-link to specific System Preference Panes, but how do you identify those panes and how do you even know if the pane itself supports url scheme linking?

Note: This post is relevant to macOS Monterey and earlier. If you're looking for more information on macOS Ventura's System Settings, check out that blog post here.

Identifying Pane Name & Anchors

How did I discover the url schemes for those panes and how can you do it as well?I’m glad you asked!

You can find the pane and associated deeplink anchors with just a little bit of applescript.

  1. Paste the code below into Script (located in /Applications/Utilities)
  2. Open System Preferences to the exact pane that you want to identify, and run the script.
  3. It will output the name of the current pane and any associated anchors.
-- Open System and click into desired pane/setting. Then, run this script to find out name (Pane ID) and any anchors.

tell application "System Preferences"
	set AppleScript's text item delimiters to ", "
	set CurrentPane to the id of the current pane
	get the name of every anchor of pane id CurrentPane
	set CurrentAnchors to get the name of every anchor of pane id CurrentPane
	set the clipboard to CurrentPane
	display dialog "Current Pane ID: " & CurrentPane & return & return & "Pane ID has been copied to the clipboard." & return & return & "Current Anchors: " & return & (CurrentAnchors as string)
end tell

You’ll get an output like this and the pane id will be copied to your clipboard:

System Preferences Pane ID and Anchors

Now unfortunately, sometimes this doesn’t capture ALL anchors that you can deeplink to (really I’ve only found it problematic with the Security & Privacy pane).

If you find some anchors/sections missing, you may want to dig into the preference pane itself and see if there’s any bits of code that reference available options. For example, the script above when run against the Security & Privacy Pane doesn’t return any options for the Input Monitoring section. However, I can open /System/Library/PreferencePanes/Security.prefPane/Contents/Resources/PrivacyTCCServices.plistand see the key value I’m looking for (and what that section is actually called) is ListenEvent.

Identifying if the pane supports URLScheme.

Not all Preference Panes support URLScheme. For those that don’t, you can accomplish the same action of opening the pane with Applescript in most instances. But how do you know if a specific pane supports a URLScheme? Let’s explore.

Most of the preference panes themselves are located within /System/Library/PreferencePanes/.

Here’s how to find if the pane supports url schemes:

  1. Open Finder and Go To /System/Library/PreferencePanes
  2. Right click on the pane you want to inspect choose Inspect Package Contents
  3. Open the Contents > Info.plist. If it supports url scheme you’ll see a NSPrefPaneAllowsXAppleSystemPreferencesURLScheme=1
System Preferences Pane URLScheme support

If the pane DOES support a url scheme, then you can use the open command + URLschemes listed here. If it does not, and you still want to open the pane via script, you could do so using Applescript.

Hope this was helpful! Happy scripting!

Scripting System Preferences Panes

Join me on an adventure in discovering how to use scripts to open nearly every single aspect of the macOS System Preferences Pane!

Mac admins and developers may at some point in their careers find themselves needing to script the opening of macOS System Preferences panes, either for automation or other tasks like presenting a specific pane to a user to click or configure.

The URL Scheme introduced in 10.10 (and refined/restricted in 10.11) makes it easy to not only open specific System Preference Panes, but to deep link to specific sections of those panes with precision. Apple seems to be adding new urls and anchors to System Preferences with each macOS release, so this will continue to be a useful tool to have in your macadmin tool belt.

So how can you automatically open specific System Preferences panes in your scripts? I’m glad you asked! Let’s dive in…

Continue reading Scripting System Preferences Panes