SpamSieve 3.3.1
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 toString.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
NSDetailedErrorsKeykey, 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 genericnilError. However, this method signals errors by returningNSNotFoundinstead ofnil. It’s annotated asswift_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 receivingNSNotFoundon 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 forNSNotFoundand usesInt.addingReportingOverflow().I reimplemented Core Data batch fetching because of two problems with the
fetchBatchSizeoption. 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:
