SpamSieve 3.3.2 is an update of my Mac e-mail spam filter that improves remote training, can export more rule information, and improves uninstallation, help, and more. The most significant news is that Microsoft has changed plans again. They will no longer be preventing users from continuing to use Legacy Outlook and in fact will keep it available for download as part of the combined Outlook app. This gives more time to adapt to their change in plans for AppleScript. Exchange (EWS) support remains an issue. Microsoft is still planning to cut off Legacy Outlook users, and Apple has yet to announce when Mail will support Graph. So far, I’ve not heard that it’s enabled in the macOS 27.2 beta.

We’re participating in a seasonal festival of artisanal software called SummerFest. For a limited time, you can get a 25% discount on new purchases of SpamSieve, EagleFiler, and other top Mac apps from our indie developer friends.

Some interesting engineering issues were:

• Updating NSWorkspace APIs introduced a problem because with the old launchApplication(at:options:), the .withErrorPresentation option is off by default, whereas with the newer openApplication(at:configuration:completionHandler:), the promptsUserIfNeeded option is on by default.

• Previously, Core Data would strip leading BOMs from NSStrings when saving to a SQLite database. With macOS 27, this happens for Swift Strings, too.

• I have lots of unit tests that check for memory leaks. These caught a change where addPersistentStore(type:configuration:at:options:) now seems to return an autoreleased store. Without adding a pool, it looked like there was a leak.

• Also, the tests were finding lots of “leaks” because KVO was retaining NSTabView, which retains a controller. Previously, XCTestCase.waitForExpectations(timeout:) would spin the run loop, and everything would get cleaned up. With Xcode 27 and macOS 27, I need to manually spin the run loop before waiting for the expectations.

• During a software update, macOS may decide to reload the Dock icon. The application package no longer exists because it’s been replaced with a new version. This wasn’t a problem before because SpamSieve had been drawing to an image in memory and setting that as the Dock icon. Now, with the Liquid Glass–imposed removal of custom Dock icons, macOS tries to load the icon from disk, and rather than handling errors gracefully it will crash. I fixed this by setting an image with a memory representation before starting a software update.

• SpamSieve 3.3.1 introduced a crash affecting a small but significant number of users when doing a Core Data fetch of a large number of objects. The private [_PFManagedObjectReferenceQueue _processReferenceQueue:] method was seemingly releasing an object that had already been released. What’s odd is that, as far as I can tell, none of the related app code had changed since the previous version, yet suddenly crashes started happening all the way from macOS 12 through macOS 27. If I had to guess, this was triggered by upgrading from Xcode 26.2 to Xcode 26.6. Maybe Swift’s ARC optimizations are doing something subtly different?

  The crash was triggered by an autorelease pool that I had inserted to promptly clean up any temporary objects after a fetch. (The actual fetched objects were returned and used outside of the pool.) Interestingly, both Gemini and ChatGPT were convinced that this is a well-known exception to standard memory management rules. They said it’s never safe to use managed objects outside of a pool they were fetched in because they depend on internal Core Data objects that the pool will have released. I was not able to find any basis for this “belief,” but it was easy enough to test. As expected, removing the pools (during the beta cycle) just made the same crashes happen slightly later.

  I think there’s probably something wrong in Core Data’s internal bookkeeping, but this does not seem to be a popular crash (and I’ve never seen it on any of my Macs), so my code must be doing something uncommon to trigger it. My current best guess is that it was related to calling refreshAllObjects() after saving. (I bet there’s some fancy bookkeeping to make that efficient.) I was doing this throughout the app to break retain cycles so that unused objects could be deallocated. But it wasn’t necessary in this particular case because the entity being fetched has no relationships. So far, removing the refresh seems to have stopped the crashes, but I won’t know for sure until more people have been using this version for a while.

Previously:

• The End of EWS in Mail and AppleScript in Outlook
• SpamSieve 3.3.1
• SpamSieve 3.2.2

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

SwiftData updates:

Section your query results by creating your query with a macro that takes a sectionBy parameter, as listed on the Additional query macros page.

Use types that conform to Codable in a model, including types you don’t control directly, by using the codable option for Schema.Attribute.

Receive real-time updates to models that match specified fetch criteria by using the ResultsObserver type.

Observe remote model changes with the HistoryObserver type.

What’s new in SwiftData:

Discover the latest enhancements to SwiftData. We’ll show you how to persist custom and third-party types using Codable, and group fetched data into sections in your SwiftUI app. We’ll also explore how to observe data store changes anywhere else using ResultsObserver and HistoryObserver, giving you the flexibility to drive powerful state objects and react precisely to model updates.

Again, there seems to be nothing new in Core Data this year, nor any communication about it. There’s still no interoperability for object IDs. The SwiftData changes seem fine but don’t really address the new framework’s deficiencies relative to Core Data. It seems like there are still basic problems with threading. I just don’t understand how Apple is deciding what to prioritize with this framework.

With SwiftUI, the bones seem questionable, but at least we can see that Apple is full steam ahead, with substantial progress to address limitations and pain points. SwiftData seemed to have better bones and is much less ambitious. Getting it right seemed like just a matter of follow through. But, for some inexplicable reason, it seems to lack the resources and/or urgency to reach its potential. And even though SwiftUI is clearly the chosen one, AppKit remains in development. Meanwhile, Core Data seems to be abandoned, even though SwiftData feels more like a side quest than a genuine attempt to supplant it.

The implicit message, for those who have build the core of their app on top of Apple’s old persistence framework, seems to be that Apple is not looking out for their needs. Core Data will surely get maintenance to the extent that Apple’s own apps need it, but there’s no evidence of a future or even a migration plan. The answer, I guess, is third-party frameworks, but that’s not an easy migration, either, since none is even as close a match as SwiftData.

Add persistence with SwiftData:

Experience SwiftData in action as we add persistence to an existing app. We’ll show you how to define your data models and seamlessly integrate persistent data with SwiftUI. You’ll also learn foundational skills for managing your app’s state using this expressive, declarative API.

SwiftData Group Lab:

Join us online for a deep dive into WWDC26 with Apple engineers and designers to ask questions, get advice, and follow the discussion about the week’s biggest SwiftData announcements.

macOS Golden Gate 27 Beta Release Notes:

Fixed: You might experience a deadlock for @Query when saving a ModelContext on a background actor while scheduling new async tasks for a ModelActor.

Paul Hudson:

I am so pleased to say these words: IT IS A BIG YEAR FOR SWIFTDATA! 🎉

Mohammad Azam:

SwiftData predicates can now work directly with enum values, resulting in cleaner models and simpler query code.

[…]

In iOS 27, Apple introduced support for compound predicates through the Predicate(all:) and Predicate(any:) initializers, making it easier to build queries dynamically based on user input.

I’m not sure why that took so long.

The framework is gradually moving beyond simple demos and becoming easier to use in larger, more sophisticated projects.

[…]

iOS 27 is the first release where many of the framework’s early rough edges have started to disappear.

Matt Massicotte:

Results of my now-yearly check to see if SwiftData’s ModelActor continues to sometimes run code on the main thread: yes it does

Fatbobman:

Compared with @Query gaining support for section fetches, and ResultsObserver enabling observation of query result changes outside views, I am more interested in @Attribute(.codable). It provides a clearer storage intent and gives developers a way to avoid falling into the black box of composition.

Of course, @Attribute(.codable) is not a silver bullet. It is more like a clearly defined escape hatch SwiftData provides for opaque Codable types: suitable for storing external types that you cannot model yourself, but still genuinely need to persist. The cost is that this content cannot participate in SwiftData’s predicate, sort, or migration awareness. Precisely for this reason, its value lies not in being “more powerful,” but in being “more explicit.”

However, SwiftData still does not provide cloud syncing for public / shared data, nor have I seen a clearer signal of performance improvements. These issues will continue to limit its adoption. For many developers, SwiftData this year feels more like it is filling key gaps rather than making a leap significant enough to fundamentally change confidence in it.

Helge Heß:

Codable types in SwiftData seem pretty lame given that SQLite absolutely does have JSON support and does support queries on it?

But the funnier thing in the MKMapItem.Identifier example is that MKMapItem.Identifier is a RawRepresentable==String, so it could actually be stored as a String in the store.

Previously:

• WWDC 2026 Links
• Batch Delete in SwiftData
• SwiftData’s ModelActor Is Just Weird
• SwiftData Runtime
• Ways SwiftData’s ModelContainer Can Error on Creation
• SwiftData and Core Data at WWDC25
• Returning to Core Data
• Dynamic Swift Predicates in macOS 14 and iOS 17