Archive for August 26, 2025

Tuesday, August 26, 2025

The “trash” Command

Benjamin Esham:

Every iOS and Mac developer is familiar with the situation: Xcode has gotten itself wedged somehow and the only solution is to blow away the DerivedData folder in ~/Library/Developer/Xcode.

[…]

But rm needs to enumerate every file and directory within DerivedData in order to delete them. The more files there are, the longer this will take.

It’s faster to move the DerivedData folder to the Trash. You could do this from the Finder, but I prefer to install Ali Rantakari’s trash utility.

macOS 14 added a built-in /usr/bin/trash command.

Peter N Lewis:

The good: they added a unix trash command to macOS. Nice! The bad: The Finder completely wigs out when you use it - disappears a different folder from the parent folder, leaving the trashed folder showing. The Finder display is borked, if you close and reopen the window the window is correct and the command worked as expected.

Previously:

FileUtils 1.5

ZigZag:

Added script actions to execute your own custom scripts (with selected files as input arguments and optional textual output). FileUtils can execute UNIX scripts/binaries, AppleScript scripts and Automator workflows.

I’ve been using FastScripts for running scripts on the Finder selection, because I already use it for running scripts in other apps. However, one benefit of using FileUtils for this is that your script can be simpler—the selection is passed in automatically—and the same script can also be executed directly from Terminal.

There is an unfortunate limitation:

FileUtils (or any other Finder Sync extension, for what it matters) related menu commands in Finder’s contextual and toolbar item menus cannot be shown for folders, which are locations for some syncing services. These include iCloud Drive, as well as some major cloud services providers, like Dropbox, Microsoft OneDrive, Google Drive, Synology Drive and there may be others I’m not aware of. And if you decided to sync your ~/Desktop and ~/Documents folders in iCloud, this apples to them as well. The reason for this limitation is all those (Dropbox, Microsoft OneDrive and Google Drive in the recent versions of their desktop applications) use Apple’s technology/API called File Provider Extension and this technology collides with the older Finder Sync technology/API if applied to a same folder and the newer technology takes the precedence. The new technology doesn’t offer what it takes to implement FileUtils’ current feature set, but even if it had, that wouldn’t solve the problem (essentially only one File Provider Extension can operate on a particular folder).

[…]

Fortunately, you can still use FileUtils provided Finder Services with those syncing folders and execute FileUtils operations on them that way.

But the static system services don’t work with a dynamic list of user-provided scripts.

Previously:

SwiftData’s ModelActor Is Just Weird

Matt Massicotte (Mastodon):

So, no doubt there’s lots of historical stuff going on here.

But, that still doesn’t explain how much trouble people have with ModelActor. I’m not sure anyone has ever used ModelActor without at least some surprises.

[…]

Actors exist to protect mutable state. The purpose of a ModelActor is to own and isolate the ModelContext. It does that! But if we start to dig into how exactly it does it, we will discover something very bizarre.

[…]

Somehow, we are on our custom, minimal, SwiftData-defined actor and also the MainActor at the same time.

[…]

It is bad because consumers of this API have a very reasonable expectation that this will execute off the main thread. This type doesn’t do that. But worse, its relationship with the main thread isn’t visible in the type system. These things are not marked MainActor, so the compiler doesn’t know what’s going on. This means even though you are on the main thread here, you cannot access MainActor stuff.

Matt Massicotte:

Anyone know if SwiftData’s ModelActor still has weird concurrency behavior in OS 26?

[…]

Based on some limited testing, no, not fixed. ModelActor types can still ultimately execute on the main thread, depending on calling context.

Rick van Voorden:

AFAIK the legit workaround will continue to be to ensure the ModelActor is created off main. Which leads to workarounds like what we do in ImmutableData sample products when we “box” the ModelActor with a lazy property in another actor that is created on main.

Matt Massicotte:

Someone proved that init off main is insufficient. I have a theory on what’s happening, and I think this workaround you suggest will always work. But yeah I’m hoping this all just goes away.

Previously:

How PlugInKit Enables App Extensions

Howard Oakley:

App extensions or appexes perform a wide range of tasks, from providing support for file systems like ExFAT to generating thumbnails for QuickLook and enabling Spotlight to index the contents of files. Although they’re relatively old, macOS made major changes in their management in Ventura, and they’ve become popular in many third-party apps. Despite that, there’s remarkably little information about how appexes are managed. As a result, when they play up it’s not clear what you should do. This article tries to disperse that cloud of unknowing.

[…]

Although old versions are registered during discovery, PlugInKit normally only offers the most recent version and, if there are multiple copies of that, the last registered by its timestamp in the registry. It’s also more conservative about which appexes it recognises: while LaunchServices will happily add apps that aren’t stored in an Applications folder and have never been opened on that Mac, PlugInKit appears more cautious in those it registers.

[…]

Damage to or dysfunction of the LaunchServices database can therefore block or impair PlugInKit registration, in turn preventing correct function of the appex.

Resetting the LaunchServices database will inevitably delay PlugInKit’s discovery, and could lead to malfunction of appexes, such as failure to generate QuickLook thumbnails.

Howard Oakley:

Resetting the LaunchServices database will inevitably delay PlugInKit’s discovery, and could lead to malfunction of appexes, such as failure to generate QuickLook thumbnails.

Previously: