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. There are now several url schemes and file types which will prompt for user confirmation when the default app is changed.
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.
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.