Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

fiod3s

macrumors newbie
Original poster
Hi everyone!

I wanted to share a new utility I built to solve a long-standing pet peeve on macOS: changing file associations quickly and effortlessly.

If you've ever tried setting default apps natively on macOS, you know the drill. You basically have to go through:

Right click → Get Info → Open with → Change All...

...for one file type at a time, over and over. It's slow, repetitive, and clunky if you need to manage multiple file types at once.

Managing associations by UTI (Uniform Type Identifier)—like .txt, .mp4, .jpg, and custom developer formats—has always needed a better solution. For years, many of us relied on RCDefaultApp, which was discontinued long ago, or SwiftDefaultApps, which unfortunately hasn't seen updates in a while and lacks a native Apple Silicon build. I created UTIdefaults to fill this exact gap.

What is UTIdefaults?

It’s a lightweight utility that lets you choose which application opens or edits specific UTIs in just a few clicks. Built from the ground up with SwiftUI and a modern multithreaded architecture, it's designed to feel responsive and natively integrated into recent macOS releases.

Key features:
  • Instant & Responsive: Fast UTI scanning and zero-lag UI.
  • Fully Native: Universal Binary (native performance on both Apple Silicon and Intel).
  • Requirements: macOS 14.6 or later.
Recent Changelog
  • 1.05: Significantly reduced the UTI list to display only entries with a preferredMIMEType, filtering out clutter and keeping only actionable entries.
  • 1.04: UTI scanning performance improved by ~10%.
  • 1.03: Added a "Do Nothing" option for specific type associations.
UTIdefaults__screenshot2en.png


Links & Feedback
I’d love to get your feedback, feature requests, or thoughts on the app. Let me know if you run into any issues or if there's anything specific you'd like to see in future updates!
 
The list of UTIs is predetermined or read from the system?
I have some zip archives that I wanted to open with another app than the default one, so I changed their extension to .zipp and assigned the app.
Searching .zipp in UTIdefaults returns only Zipped Web Archive Collection with the extension wacz.
 
The list of UTIs is predetermined or read from the system?
I have some zip archives that I wanted to open with another app than the default one, so I changed their extension to .zipp and assigned the app.
Searching .zipp in UTIdefaults returns only Zipped Web Archive Collection with the extension wacz.
The list of UTIs is read dynamically from the system's LaunchServices database, with lsregister -dump.

Simply renaming a file extension to .zipp or assigning an app to open it via the Finder ("Open With") does not create or register a system-wide UTI. macOS only registers a new UTI into LaunchServices if an installed application explicitly declares it in its Info.plist (under UTExportedTypeDeclarations or UTImportedTypeDeclarations).

If no app on your Mac declares .zipp as an extension bound to a specific UTI, macOS treats it as an unknown/dynamic type. That's why searching for .zipp only returned .wacz (where "zipp" likely matched substring metadata in that specific UTI definition).

If you want .zipp to be recognized as its own distinct UTI, an app on your system needs to declare that extension in its bundle manifest, or macOS will continue to fallback to generic dynamic identifiers.

Hope this wasn't too technical, but you should get the general idea now!
 
Last edited:
  • Like
Reactions: bogdanw
I've just rolled out version 1.1.0 of UTIdefaults! This release focuses on refining how the app handles system-level file associations, making handler detection feel much more natural on macOS, and fixing a few long-standing edge cases.
Here is what's new in this release:
  • Improved UTI Handler Detection: Open With now includes applications registered as either viewers or editors. This brings the behavior much closer to native macOS conventions while ensuring Edit With remains strictly focused on editor-capable applications.
  • Redesigned "Do Nothing" Action: The "Do Nothing" handler has been completely rebuilt from the ground up using a signed Helper App to ensure seamless, reliable execution without security prompt interruptions.
  • UI Polish: Applied minor interface fixes and visual tweaks across the main window for a cleaner user experience
Thanks for supporting UTIdefaults!
 
[ New Version ] UTIdefaults 1.1.3 brings a polished user interface and modern macOS API integrations (requires macOS 15 Sequoia or later), while version 1.1.2 remains available with Finder-style refinements for earlier macOS systems.
 
Small bug in version 1.1.3 (16): searching for the extension "docx" returns "No UTIs Found". It can be found by searching for "Office Open XML"
 
Small bug in version 1.1.3 (16): searching for the extension "docx" returns "No UTIs Found". It can be found by searching for "Office Open XML"
Thanks for reaching out! This isn't a bug: the search feature filters UTIs by their extended name/description (e.g., 'Office Open XML') and identifier string, rather than by file extension (e.g., 'docx'). Searching for the format name correctly retrieves the associated UTI.

That said, searching directly by file extension would definitely be convenient. I'll look into ways to support extension-based search in a future update, though I can't promise if or when it will be implemented!
 
That said, searching directly by file extension would definitely be convenient.
I presumed that is the default way of searching. I think most people would expect the same.🙂

Trying to change dmg (com.apple.disk-image-udif) returns "Could not update the Open With handler. LaunchServices returned -54"
 
I presumed that is the default way of searching. I think most people would expect the same.🙂

Trying to change dmg (com.apple.disk-image-udif) returns "Could not update the Open With handler. LaunchServices returned -54"
Thanks for the update!

Regarding the extension search, I agree that it makes total sense from a user perspective, and I'm definitely on it.

As for error -54, I'm unable to reproduce this on my system, where changing the handler for .dmg works as expected. Error -54 is a LaunchServices system error (kLSErrorsIllegalArgumentErr / permission lock) returned directly by macOS, indicating that the OS itself is blocking the write operation on your machine. This usually happens if:
  1. The app you are trying to set as default is not located in the main /Applications folder (e.g., it's running from Downloads, a temporary folder, or an external drive).
  2. System Integrity Protection (SIP) or local security policies are restricting changes to system-level formats like .dmg.
  3. The local LaunchServices database has permission issues.
Make sure the target application is moved to /Applications and launched at least once before setting it as the default handler."
 
Quick update: Version 1.20 is now live! By default, search now queries both format names and file extensions seamlessly (with or without the leading dot), and you can set your preferred search scope in the options. Thanks for the feedback!
 
Hi, using Version 1.2.0 (17), don't see SQL, search doesn't find SQL or .sql
Thanks for reporting this!

I've just released version 1.2.1, which fixes this issue and improves how file types (UTIs) are scanned so .sql files are properly detected.

Additionally, this update introduces a new setting for power users that allows you to display all system file types—even hidden or secondary ones that don't have standard file extensions or default apps assigned to them.

Please update to v1.2.1 and let me know if everything works as expected!
 
hi again, sorry to bother but the zip file for 1.2.1 at the website seems to be broken, can't be extracted.

Edit: itch.io one has same issue
 
Last edited:
hi again, sorry to bother but the zip file for 1.2.1 at the website seems to be broken, can't be extracted.

Edit: itch.io one has same issue
Thanks for letting me know! On my end, downloading and extracting the file worked fine, but I went ahead and re-packaged and uploaded a fresh version of the 1.2.1 .zip archive just to be safe.

Could you try downloading it again and let me know if it works now?
 
thanks, issue seems to have been on my side, I'm using The Unarchiver app, and the zip file didn't work if I tried to extract it using it
Thanks for confirming! It turns out macOS's built-in Archive Utility sometimes adds metadata/attributes that don't play nicely with The Unarchiver when packaging .app bundles.

I tested version 1.2.2 directly with The Unarchiver and confirmed it extracts smoothly. Starting with version 1.2.2 and for all future releases, I'm using BetterZip to ensure maximum compatibility across all extraction tools.
 
  • Like
Reactions: hunter2
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.