Tag: MacAdmins

Apple 26.5 Platform Updates — May 2026

macOS

iOS and iPadOS

Other Platforms

Applications

Apple 26.4 Platform Updates — March 2026

macOS

Also see my post on the changes in macOS 26.4 when changing default apps.

iOS and iPadOS

Other Platforms

Applications

Guides

macOS 26.4 brings more default app confirmation prompts

The 26.4 updates have been released and among the many documented changes, there is one that the Apple documentation team seems to have missed to tell us about. Changing the default app to open any file type will prompt for user confirmation.

What happened so far

Some years ago—I believe it was in macOS High Sierra 10.13—Apple added a prompt for the user when an app or process changed the default application for http url scheme, i.e. the default web browser.

This was presumably implemented to prevent malware sneakily switching out default browsers to capture web traffic and passwords.

Since the prompt allows the user to keep the current browser, management scripts have to consider that the user might reject the new browser, or not notice the prompt, or notice the prompt and move it to the side and ignore it. This made managing the default browser quite difficult. I have written about this.

Until 26.3, default apps for file types and other url schemes could still be changed using the proper APIs without user interaction.

What changes in macOS 26.4

In macOS 26.4 Apple has added user confirmation prompts to all file type/UTI default app changes.

Note: exactly which kind of default app changes causes the prompt to appear has changed during the beta phase of macOS 26.4. There might be changes to this in later updates. If so, I will update this article accordingly.

Note 2: users can still change default apps for file types in the Finder Info window without an additional prompt.

This is really annoying when you want to pre-set default apps in a managed environment

Yes.

If you have scripts or automations that are changing the default apps for any of these URL schemes, and they run on a Mac with macOS 26.4, they will prompt the user and wait until the user either clicks the “Use” or “Keep” button.

In the best case, the user will click the “use” button and your script will continue as before. A worse scenario is that the user clicks the “Keep” button and the change will not be applied. Scripts will have to be updated to account for this case. At the very worst, a user can ignore the prompt and move it to the side, stalling your script or automation and the process or management service that started it indefinitely.

When your script or automation was setting a list of default apps for many file types, an operation that is very common in development environments, then the user will have to confirm each single change. A horrible user experience.

My command line tool utiluti has an option to change multiple default apps for file types read from a plist file which is now rendered pretty much useless.

Apple has not provided a means to manage default app assignment using a configuration profile or declaration on macOS. (There is a MDM command, which can set the default browser, calling, and messaging app—but only for iOS and visionOS.)

Please file feedback with Apple for this through your AppleSeed for IT accounts.

Management with a configuration profile or declaration would set and lock the default application, which is often not a desireable configuration. In managed environments, admins often want to set a reasonable default (say, Xcode or Visual Studio Code for scripts and code files) but let the user change that later, should they want.

I have built desktoppr and utiluti for exactly these kinds of “set-once” workflow, but the user prompt limits utiluti‘s functionality severely.

What can we do?

First, Mac Admins will have to identify any scripts that set default apps for file types which will now show (and wait for) a user prompt. You will have to determine how to adapt that script.

For scripts which are initiated by the user, for example from a self service application, the prompt should not interfere with the workflow too much, as long as the script is not setting many defaults and creating many prompts. You may still have to update the script to be able to react to the user rejecting the change.

For script that set defaults in automated, silent way, commonly, but not exclusively, as part of an enrollment workflow, you will have to find a different solution. There are some script available, which bypass the prompts by changing the Launch Services property list setting directly, but they are generally only reliable when applied early in the enrollment process and are followed by a logout or restart.

Use the User Template

Recently, Christopher Smith shared an approach on Mac Admins Slack which is detailed a bit more in this blog post of his.

This approach has the advantage of placing the configuration before the user is created and the LaunchServices daemon is running. When a new user account is created, the system copies the plist from the User Template to the new home directory and the LS daemon loads it when it launches.

I have a sample project that builds a pkg to install the proper file in the user template.

Work with the user: Setup Checklist

If you need to change default app settings for file types on a “running” system, any time after the user account creation, you will have to find a way to deal with the user interaction.

We have recently published a public beta of “Setup Checklist” for Jamf Pro and Jamf School. Setup Checklist is a tool that can guide the user through some important configuration that the IT and/or security department want configured, where Apple does not give us the option to manage without user approval.

This app can (among other things) ask a user to confirm a default app, wait until the prompt is confirmed. Should the user choose the “keep” option, the prompt will be presented again (and again…). Setup Checklist can also present a list of apps that the user can choose from.

We designed this step to “manage” setting the default web browser without manipulating undocumented plist files. It now also works for changing default apps for file types. If you need to change the default app for many different file types, then this will still be tedious, since it will generate a prompt for every single change.

Please file feedback

I have said it before: while I hope this article will help you to understand what is going and give you some idea of what you can and need to do, we need to let Apple know that this change is very detrimental to managed environments. Please file feedback with Apple through your AppleSeed for IT accounts that Mac Admins require a means to manage default apps without user interaction.

Apple 26.3 Platform Updates – February 2026

macOS

iOS and iPadOS

Other Platforms

Deployment Guides

Applications

Managing iWork in 2026, the Creator Studio update

The apps formerly known as iWork: Keynote, Pages, and Numbers received an update this week. Generally these updates aren’t that big of a deal, but this one is different, especially for macOS administrators.

The three apps formerly known as iWork have been available as standalone apps on macOS for a long time. First, as standalone paid apps, then in a bundle and then in the App Store as a one-time-purchase, later for free. They also come pre-installed on all Macs out of the box, but not after a system wipe.

Now, these three apps are joining the Apple Creator Studio bundle which includes the “Pro” apps. The existing functionality will remain free, but there are new additional features that you can unlock by purchasing the Creator Studio subscription.

The new apps bundled with the Creator Studio have the version number 15.1. Why Apple didn’t change these to the ’26’ version numbering is a mystery, as is what happened to the 15.0 release.

The update from 14.x to 15.1

There are a lot of changes for the macOS versions of these three apps. These are especially relevant to Mac admins with managed app deployments, but they will also explain some issues you may be encountering on a personally managed Mac.

While this is a standard update for the iOS, iPadOS and visionOS apps, it is actually an entirely new app for the macOS versions. To be even more precise, the upgrade process consists of an update and a new different app. Apple has published a support article explaining the process.

(The examples will be mostly for Keynote, but Pages and Numbers behave in the exact same way.)

If you had the latest version of Keynote before this Wednesday (14.4), you would see a 14.5 update in the Mac App Store with the release notes: “This update contains bug fixes and performance improvements.”

Not sure about the bug fixes and improvements, and Apple certainly doesn’t go into detail on these. Apple states that you should upgrade to 14.5 before installing and launching the 15.1 apps, so that saved passwords for protected documents are preserved correctly.

After updating to 14.5, there will also be a dialog stating that a “New Verision of Keynote Available” [sic] with a button that links to the new Keynote app in the App Store and a second button “Not Now” which allows you to ignore this for now, because, presumably you opened the app to do some work.

Fellow Mac Admin Neil Martin found a way to suppress this dialog with a configuration profile.

There is one big limitation with staying on the old version that I have encountered so far: you cannot collaborate on shared documents when one or more of the collaborators are using the 15.1 version, which is very likely when they are using iOS, iPadOS, or visionOS.

When you follow the button to download the new app from the app store, you can download the new Creator Studio version (15.1) for free. You will see a second, new app with the new icon in the Applications folder.

Differences between the apps

In the Finder the two apps look the same, except for the icon. But when you look at them in detail, there are two important differences. The new apps have a different name in the file system, which you can see in Terminal. The name in the file system is /Applications/Keynote Creator Studio.app.

This may seem cosmetic, but it will lead to broken dock items when the old version is removed. A user might be confused why Keynote is suddenly a question mark in the dock. When you are a Mac Admin who manages or even just pre-sets the dock, you may want to consider updating any dock items they might have. At the very least you will need to update scripts or profiles that set the default dock at enrollment.

When you further inspect the application bundle by looking at the Info.plist or with a tool like Apparency, you will see that the bundle identifier of the new app is com.apple.Keynote vs. com.apple.iWork.Keynote for the old one. This also has some side effects. In their support article, Apple calls out that the “Open Recent” menu will not be populated. Other customizations such as a customized toolbar may not transfer either.

Why?

The main change is that these apps now appear as a single entry across all the App Stores. You “purchase” the app once and get the app for all platforms. This has already been true for the iOS, iPadOS, and visionOS apps and now the macOS versions join that. This might simplify some things going forward.

This does not mean each platform gets the same app bundle, the actual downloaded apps are still specific and different for each platform. It is also important to point out that the 15.1 version still runs on Intel macOS.

To unify the apps into a single universal entry, Apple had to use the bundle identifier across all platforms.

Well, either that, or Apple could have updated the App Store backend to be more flexible here Apple always claims that their control over the hardware, software and services lead to a much better consumer experience. This would have been a chance to prove that.

I find it absolutely incomprehensible that Apple considers the App Store architecture, which is based on a store designed to sell songs for 99 cents more than 20 years ago, so inflexible that they would rather have their customers, administrators, and their own in-house developers jump through all these hoops.

But more on that later.

The Upsell

The apps are now part of the Creator Studio subscription bundle, so of course, there is upsell in the apps. There are big areas advertising the new themes that only come with the subscription in the dialog to create a new document. In Keynote, there is a big blue notice to “Elevate Your Presentations” in the slide inspector side bar, which thankfully does not appear in other inspectors. There are also purple toolbar items with the new features that are gated behind the subscription.

This enshittification of the app is annoying enough for consumers, but it is worse for managed deployments. Apple provides no means to purchase subscriptions for an organization. Even if you wanted to purchase the subscription for all your employees, you cannot. Instead, everyone is stuck with these garish ads and purple buttons.

Mac Admins have been asking for a way to purchase, manage, and deploy App Store subscriptions and in-App purchases for years. But again, the architecture of the App Store seems to be so inflexible, that Apple cannot provide this. Instead, they are “innovating” by placing more ads.

The Solution that misses

In their Apple Platform Deployment Guide, which was also updated this week, Apple mentions not one, but two solutions.

While the new versions of Keynote, Numbers, and Pages automatically hide these features when the Managed Apple Account appears in Settings, an additional Managed App configuration payload can be deployed using your device management service to provide the same experience for devices without a Managed Apple Account.

When the device has a Managed Apple Account signed in, the upsell ads should not show. While managed Apple Accounts (MAA) are certainly an interesting technology, their adoption among organisations has been slow, as they have very limited use cases, especially on macOS.

The other option is to add “an additional Managed App configuration payload” (also known as AppConfig) the the app deployment. This is actually a nice solution for iOS, but has one problem: while Apple’s MDM specs does allow for AppConfig when deploying Mac App Store apps to macOS, many device management systems do not implement this.

It is fair to ask why many device management services don’t offer this? Until this week, there were no important Mac Apps that used AppConfig for their configuration.

On macOS, configuration profiles have been used to configure the system and apps for more than a decade. This is familiar to admins and (most) developers. Configuration profiles have the advantage that they work for apps distributed outside the App Store, as well as App Store apps, so implementing AppConfig for macOS didn’t seem necessary, since it will not benefit most or any of the apps an admin needs to manage.

Device management service developers are focusing their resources on implementing the new modern DDM specs. It is sad that something like iOS apps on macOS and AppConfig for Mac App Store apps aren’t implemented, but the reality was, that Mac admins, their customers, weren’t asking for it. Until now, there was no need for it.

Apple ignores the reality on the ground. Instead of using an established and proven configuration method, they are using something that should work in theory. This is the cross section of managed deployments and the Mac platform, both regularly blind spots for current Apple.

Where was the beta?

If Apple had done a beta phase for the Creator Studio in AppleSeed for IT, these issues would have come up, been discussed and some of them could have been fixed. Mac admins would have had some time to prepare for the systemic issues that couldn’t be fixed and prepare and test workflows, or at the very least have support documents and communication available for the end users and support techs.

AppleSeed for IT has been successful at this for years now, providing administrators and developers early access to platform upgrades and updates with a dedicated feedback channel. But apparently, the app development teams at Apple haven’t heard of it. Or, if I may hazard a guess, the architecture of the App Store doesn’t allow for a beta deployment test phase. (There is TestFlight, but you cannot perform or test managed deployments through TestFlight.)

What should Mac Admins do?

If you are deploying the apps formerly known as iWork (Keynote, Pages, Numbers), you need to do the following:

  • ensure that the clients receive the 14.5 update, so that the settings that are transferred, can be transferred properly, when the new version is launched
  • once all clients have the 14.5 version, disable the deployment of the old versions
  • add licenses for the new apps to your volume purchasing in Apple Business or School Manager
  • configure your device management service to deploy the new apps, if your management service allows this, you may have to search for the new apps using the full app store link, as these are not Mac apps, but universal app entries in the App Store
  • scope the deployment to those clients that have the 14.5 version
  • if your device management service can add an AppConfig or Managed Application Configuration to a Mac App Store app deployment, add the suppressPrompts key with a value of true.
  • once the new version is installed, remove the old applications from the client
  • if you are managing the dock, replace any items in the dock to match the new app file paths

Going forward

Most importantly, please file feedback through the AppleSeed channel and your AppleCare contacts on this, and what could have been done better. This is my list, but feel free to add more:

  • earlier communication and a beta phase for App Store applications and bundles
  • management of Creator Studio subscription nags with configuration profiles on macOS
  • a better upgrade experience for macOS
  • volume purchasing, deployment, and management for App Store subscriptions and in-App purchases

You also want to file feedback to your device management service, they may be able update their interfaces and workflows to make these “updates” easier in the future.

Apple may have unified nearly all of their paid apps in one subscription, and believe they are done for now. No changes to the App Store needed. But third party developers may also want to unify their app offerings and are facing the same challenges. They will model their “upgrades” after the approach Apple has taken here.

Pro apps

Thre are more apps that are a part of the Creator Studio bundle. Apple acknowledges the problems by keeping the one-time purchase versions of (most of) the apps in the App Store. For the apps that have so far been free, Apple didn’t deem this necessary.

There may be issues regarding upgrading the Pro apps, as well. There may be issues with maintaining the one-time-purchase versions going forward. I have not yet had time to dive into these. I am sure other Mac Admins will share their experiences, and I will be sure to share their posts in my MacAdmins.news weekly summary!

Apple Platform Updates: 26.2

Unusual Friday night release of the Apple platform updates. Might be because Apple was pushing close to the 90-day deferral limit for 26.0, as I speculated in MacAdmins.news yesterday. Either that or Apple developers are just eager to go on their holiday breaks. (Can’t blame them…)

macOS

iOS and iPadOS

Other Platforms

Apple Platform updates for September 2025

macOS

iOS and iPadOS

Other Platforms

Applications

Another Simple Package: Policy Banner

Previous articles in this series:

When you place a text file named PolicyBanner in the /Library/Security directory, macOS will display this file before the Login Window. The user will have to accept the banner before they can log in.

The PolicyBanner file can be plain or rich text (txt, rtf, or rtfd file extensions). You can find a very simple PolicyBanner.rtf in the sample files, or create or provide your own.

The support article notes that the PolicyBanner file needs to be readable by every user in order to be displayed.

To build a package that installs your policy banner file, create a new project folder with a payload subdirectory:

> mkdir -p PolicyBanner/payload/Library/Security
> cd PolicyBanner

Then copy the PolicyBanner file to the payload directory, and ensure that the read mode is enabled:

> cp /path/to/PolicyBanner.rtf payload/Library/Security
> chmod 644 payload/Library/Security/PolicyBanner.rtf

Then create a new buildPolicyBannerPkg.sh script file in your favored text editor:

#!/bin/sh

pkgname="PolicyBanner"
version="1.0"
install_location="/"
identifier="com.example.${pkgname}"

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

projectfolder=$(dirname "$0")

# recursively clear all extended attributes
xattr -cr "${payloadfolder}"

# ensure banner file is world readable
chmod 644 "${payloadfolder}/Library/Security/PolicyBanner.rtf"

# build the component
pkgbuild --root "${payloadfolder}/payload" \
         --identifier "${identifier}" \
         --version "${version}" \
         --install-location "${install_location}" \
         "${projectfolder}/${pkgname}-${version}.pkg"

This script is very similar to the buildBoringWallpaperPkg.sh script from the previous post. You could easily copy that script and modify the pkgname variable, and add the lines that ensure the correct file mode.

Your folder structure should look like this:

📁 PolicyBanner-1.0
   ⚙️ buildPolicyBannerPkg.sh
   📁 payload
      📁 Library
         📁 Security
            📄 PolicyBanner.rtf

When you run the build script it will generate a package named PolicyBanner-1.0.pkg. Inspect the package with pkgutil or Suspicious Package and verify that it contains the PolicyBanner.rtf file as its payload with the correct install location.

You should always verify your self-built packages with an inspection tool after building and before the first test installation. This step can quickly catch several frequent errors.

Once you have inspected the pkg file to your satisfaction, you can install it on a test client. After running the installation, verify that you can find the PolicyBanner file in the /Library/Security folder and then logout to see if it works.

While the use cases for this kind of simple policy display are limited, this example demonstrates how system administrators use pkg installers to modify settings and behavior in macOS.

Uninstall Policy Banner

In the previous post, we said it makes sense to build an uninstall script alongside the package itself. To uninstall this pkg, you can use the following script:

#!/bin/sh

# uninstall Policy Banner

# reverts the installation of com.example.PolicyBanner

# check for root
if [ "$(whoami)" != "root" ]; then
  echo "requires root privileges..."
  exit 1
fi

# remove the file
rm -v "/Library/Security/PolicyBanner.rtf"

# forget the pkg receipt
pkgutil --forget com.example.PolicyBanner

A Simple Postinstall Script

Apple’s support article on policy banners mentions:

If the policy banner still doesn’t appear, update the Preboot volume:
diskutil apfs updatePreboot /

To be honest, I have never (so far) encountered this problem and had to apply this fix, but, for the sake of example, we will be extra paranoid… er… thorough and apply this command after installation, just to be sure.

macOS installation packages allow for scripts or binaries to run before or after the payload is laid down on the target volume. We will go into much more detail later. For now, we will create a postinstall script which runs the command above and add it to the package.

In the PolicyBanner project folder, create a new sub-directory called scripts on the same level as the payload directory.

> cd PolicyBanner
> mkdir scripts

Then create a script file named postinstall (no file extension!) in the scripts directory with the following code:

#!/bin/sh

## run update preboot

# extra paranoid interpretation of
# https://support.apple.com/en-us/119845

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

# only run when installing on System Volume
if [ "$3" != "/" ]; then
    echo "Not installing on /, exiting"
    exit 0
fi

echo "running updatePreboot"
diskutil apfs updatePreboot /

After creating the file, ensure its executable bit is set:

> chmod +x scripts/postinstall

Your PolicyBanner project folder should look like this:

⚙️ buildPolicyBannerPkg.sh
📁 payload
   📁 Library
      📁 Security
         📄 PolicyBanner.rtf
📁 scripts
   ⚙️ postinstall
⚙️ uninstallPolicyBanner.sh

The diskutil man page mentions that you might break login when running the updatePreboot command against a user database that does not match the system, so we are going to avoid doing that.

The script checks if the third argument $3 matches “/” and exits the script when it does not.

The installation system passes the target volume as the third argument $3, so this check ensures the postinstall will only run when the banner is installed on the current system volume.

Then, having passed that check, it will run the command. There are a few echo commands whose output will appear in the installation log. These are helpful to see what is going on.

We still have to instruct pkgbuild to include the postinstall script in the package file. Open buildPolicyBannerPkg.sh and modify it like this:

#!/bin/sh

pkgname="PolicyBanner"
version="2.0"
install_location="/"
identifier="com.example.${pkgname}"

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

projectfolder=$(dirname "$0")
payloadfolder="${projectfolder}/payload"
scriptsfolder="${projectfolder}/scripts"

# recursively clear all extended attributes
xattr -cr "${payloadfolder}"
xattr -cr "${scriptsfolder}"

# ensure banner file is world readable
chmod 644 "payload/Library/Security/PolicyBanner.rtf"

# ensure postinstall is executable
chmod 755 "${scriptsfolder}/postinstall"

# build the component
pkgbuild --root "${payloadfolder}" \
         --identifier "${identifier}" \
         --version "${version}" \
         --install-location "${install_location}" \
         --scripts "${scriptsfolder}" \
         "${projectfolder}/${pkgname}-${version}.pkg"

First, update the version of the package. You should update the package’s version every time you update its contents. This allows the installation system to distinguish a re-application of the same package from an installation of a different version.

Then we create a variable referencing the scripts folder, run the xattr command to clear extended attributes from its contents and ensure the executable bit is set on the postinstall.

Finally, we add a --scripts option referencing the scripts folder to the pkgbuild command. Take note of the trailing backslash \ in that line, that allows the command to continue to the next line. Without the backslash, the command will error.

Run the buildPolicyBannerPkg.sh script. This will create a pkg file named PolicyBanner-2.0.pkg file in the project folder. When you expand this package file with pkgutil, you will see a sub-directory named Scripts which contains the postinstall.

> pkgutil --expand PolicyBanner-2.0.pkg PolicyBanner-2.0-expanded
📁 PolicyBanner-2.0-expanded
   📄 Bom
   📄 PackageInfo
   📄 Payload
   📁 Scripts
      ⚙️ postinstall

Installation Log

Install the package file on a test Mac using the Installer.app. When the installation has completed successfully, choose “Installer Log” (command-L) from the “Window” menu and then choose “Show All Logs” (command-3) from the “Detail Level” popup in the log window.

The Installer log is always quite detailed or even noisy. Since we know we are looking for log entries regarding the postinstall script, you can enter ‘postinstall’ in the search field of the log window. This filters down the log to the entries relevant to the postinstall script:

installd[690]: PackageKit (package_script_service): Preparing to execute script "./postinstall" in /private/tmp/PKInstallSandbox.1gFziD/Scripts/com.example.PolicyBanner.rQLtIr
package_script_service[1168]: PackageKit: Preparing to execute script "postinstall" in /tmp/PKInstallSandbox.1gFziD/Scripts/com.example.PolicyBanner.rQLtIr
package_script_service[1168]: Set responsibility to pid: 13061, responsible_path: /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer
package_script_service[1168]: PackageKit: Executing script "postinstall" in /tmp/PKInstallSandbox.1gFziD/Scripts/com.example.PolicyBanner.rQLtIr
package_script_service[1168]: ./postinstall: running updatePreboot
package_script_service[1168]: ./postinstall: Started APFS operation
package_script_service[1168]: ./postinstall: UpdatePreboot: Commencing operation to update the Preboot Volume for Target Volume disk3s1 (Macintosh HD)
package_script_service[1168]: ./postinstall: UpdatePreboot: Commanded forwarding to System-role regardless of target input = InhibitAutoGroupTarget = 0; ForwardingEnabled

(I have removed some columns and text for space and clarification. The process numbers will be different in your log.)

If you do not see entries for the postinstall script in the log, you have made an error configuring the package. Most likely errors are that you named the postinstall script wrong (usually by accidentally adding a .sh or .txt file extension) or did not set the executable bit correctly.

First, we see a few entries where the installer system is preparing the postinstall script to run, then we see a line:

./postinstall: running updatePreboot

This is the output of the echo command in our postinstall script. Here we can tell that the script passed the system volume check successfully and will run the diskutil command next.

Then we see a lot more lines which are the output from the diskutil command itself. The updatePreboot verb is very verbose, which can actually be helpful when diagnosing problems.

You can also find this output in /var/log/install.log. macOS will append all installations to this log file. That includes regular runs of the software update system, so the install.log will get quite big and noisy over time. When you are debugging package installation issues it is very useful to note the time of your installation, so that you can narrow down the area of the log file you need to inspect.

This has been a very simple example for an installation script. We will re-visit this topic in more detail in a later post.

Books Update — 2025

It’s been a while since I wrote about my books. Life has been tugging me in different directions (in a good way, overall). Things are going well, overall, but there was always this nagging feeling that I really should do something about the books. They were getting a bit… well… old…

If you follow this blog, you may have noticed a few posts about packaging recently:

If you are a proud owner of my book “Packaging for Apple Administrators” (thank you very much!) these posts should seem somewhat familiar. It has been nearly nine years since I first published “Packaging” and even though it really held up well, it was in desperate need of some updates. More than merely updates, really. Many of the examples not available online anymore. Seriously, some of the examples are to inspect the iTunes and Silverlight installer pkg…

Surprisingly little has changed in the process of actually building packages, so those sections of the book hold up pretty well. But the environment in which packages are used and deployed on macOS has changed. Quite a lot. GateKeeper and Notarization were new and optional, just a few years ago, but now are a core part of Apple’s security strategy on macOS. Bundle package installers, which I covered in a “legacy” appendix in “Packaging” were completely disabled in macOS Sequoia 15. Imaging Macs with NetInstall was still a thing when I originally wrote the book and how to use and prepare installer packages for those workflows took up some space.

Distribution packages were only required in edge cases for Mac admins. Now they are often (but not always) required to work with device management servers.

On the other hand, back then I did not have any experience with the developer side of packaging. Since then I have written about building tools and apps and integrating the packaging (and signing and notarization workflows) in Xcode and Swift Package Manager. These are workflows that are useful to developers, but less so for Mac Admins.

So, I am happy to announce that I have started the work of updating “Packaging.” It’s a work in progress, and I do not want to commit to any timeline yet. However, I plan to continue to share the progress by posting sections on this blog as I update them.

What will happen to old, outdated “Packaging for Apple Administrators” you might ask? Well, I am going to remove the book from Apple Books in two weeks or so. If you really want to own a copy of this old version, this will be your last chance to purchase it. I didn’t want to remove the book without warning. But, honestly, most of you really don’t have to buy the old version anymore, since I will be posting parts as I update and rewrite.

(If you want to buy a copy to support me, don’t do that on Apple Books. The standard 30% of that revenue will go straight to Apple and honestly, they have enough money. There is now a better way, but more on that later.)

In two or three weeks time, I will remove all books, except “macOS Terminal and Shell” from Apple Books.

If you have purchased the book, it should remain available for you in your library, but maybe make a backup to be sure.

I have spent a few days updating “macOS Terminal and Shell” for the current state of macOS. Since this is my latest book and well, the command line situation hasn’t changed very much since Apple switched the default shell to zsh, there wasn’t much to change. I will keep that book on Apple Books and update it as soon as the new version passes Apple’s review. If you have already purchased “macOS Terminal and Shell” you should get the updated version as soon as I have uploaded it. You should then see a notification in the Books app.

I am also starting a new experiment: you can also purchase “macOS Terminal and Shell” on Ko-Fi. (might be more familiar as “Buy me a Coffee“) This is an experiment and new to me, so apologies if there are some rough edges. This should work if you do not want to or cannot purchase on Apple Books.

Also, I get a larger share of the proceeds. And, should you desire to, you can even pay more than the suggested price. (though, really, no-one has to)

As I said, this is a test run, and I am very curious how it goes. I am excited that this should expand the audience for whom the book is available. (Apple Books is not available in many regions, like India and China.) If the experiment works out for this update of “Terminal and Shell” then I will definitely consider this for “Packaging 2.0” and future books, as well. (I have plenty ideas, but so little time)