SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

• I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

• The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

• Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

• Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

• I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

• I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

• There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

• The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

• Xcode 27 Announced
• SpamSieve 3.3
• Swift Proposal: Precise Control Flags Over Compiler Warnings
• Swift at 10

Hartley Charlton:

Apple today announced that users can now describe a shortcut in natural language, with Apple Intelligence automatically building the automation in the background.

Marcus Mendes:

Users can simply describe what they want, such as “when I’m leaving work, text my wife with my expected ETA,” and Shortcuts will actually build the shortcut to make it work.

This sounds great in that I find creating shortcuts annoying. It’s not always clear which building blocks I should be using, and stringing them together properly seems tedious and fiddly. On the other hand, I dislike how AppleScript doesn’t get first-class support for the functionality and triggers that are available to Shortcuts.

Simon B. Støvring:

Data Jar got sherlocked, and that genuinely makes me happy.

Simon B. Støvring:

Apple should let users filter out and maybe even rewrite notifications from any app using Shortcuts.

[…]

The new notification automation trigger in Shortcuts is super cool. As far as I can tell, it won’t let me modify the notification content or filter out notifications based on the content, but it’s still a quite powerful addition.

[…]

Third-party automation triggers in Shortcuts are now possible. Sort of.

Just send a notification containing data meant for the new notification trigger to consume.

Anders Borum:

iOS 27 allows 3rd party shortcuts actions to run for longer than 30 seconds making me publish 2 actions that have been hidden behind feature flags for years.

Create cloud servers, run commands and destroy them again right from Shortcuts.

Previously:

• Apple Intelligence in appleOS 27

Update (2026-06-26): Jason Snell:

This is as close as we’ve come, across 40 years, to the original dream of putting computer power in the hands of everyone. You can literally tell your device what you want it to do, and when—”every morning show me my to-dos and calendar events for the day”—and it will generate a program to do it and a schedule to run it.

[…]

Yes, there are lots of limitations. Describe a Shortcut doesn’t work with third-party apps, only Apple’s own stuff (at least, for now). It can sometimes get confused, especially with complex queries. And it has an interesting tendency to kick things to the Use Model action—why am I not surprised that an AI model likes to build Shortcuts that themselves use AI models?

But when it works, which is most of the time, it’s magical.

Simon B. Støvring:

Shortcuts on macOS Golden Gate is… Something.

Dedicating that much window space to a larger shortcut tile and a text field feels incredibly wasteful.