SpamSieve 3.0.5
SpamSieve 3.0.5 is a maintenance release for my Mac e-mail spam filter. It seems to work great with the current macOS Sequoia beta, though I expect another update will be required when Apple releases the AI-enabled beta of Mail later this summer. Unfortunately, Apple tends to make big changes to Mail through August, so we never quite know where we stand until the GM, and a couple times there were even significant changes after that.
Some interesting issues were:
Xcode 15 still has a bug where Swift apps crash at launch prior to macOS 14 when using a macOS 10.13 deployment target, in this case triggered by accessing libswiftNetwork.dylib, which SpamSieve is now using for reachability checks. I describe a workaround here.
Apple Mail’s support for Mail App Extensions continues to be unreliable, to the point where some customers are finding that it works best to turn off the extension entirely. This can avoid a bug where Mail ignores (and possibly even clears) the cached data for a message, leading to unnecessary redownloads and slowness. Mail already has issues with not sending all the new messages to the extension for filtering, and so SpamSieve already has workarounds to filter the new messages without needing the extension. Of course, things would smoother with extensions working properly, but my Radars and DTS incidents do not seem to have affected that over the last year.
Separate from the extension issues, SpamSieve is better at detecting when Mail is busy downloading messages, as during that time it can block the user interface and starve its other threads, so SpamSieve will back off its requests until Mail is less busy.
Xcode 16 has a regression where tests will fail to access the Contacts database and take a very long time as they wait for 8 failed attempts to contact the XPC server. It’s not clear how to give Xcode TCC access as it doesn’t prompt.
With Xcode 16, the responder chain no longer seems to work properly when running tests. I updated various toolbar validation and undo tests to use hard-coded targets.
NSStringin macOS Sequoia is more strict about not accepting data that doesn’t conform to the specified encoding. Previously, it would make a “best effort,” but now it will just fail outright, which is probably a good thing.Swift 6 doesn’t like my adding
ExpressibleByUnicodeScalarLiteralto theFourCharCodetype (since Apple owns it). The warning can be silenced using the@retroactiveattribute, but that won’t compile with Xcode 15.macOS Sequoia has made significant changes to how text is extracted from PDFs.
macOS Sequoia has changed the way Thai text is tokenized.
Core Data can crash when resolving uniqueness conflicts if the database file is damaged. This is not because SQLite is crashing, but rather that the corruption seems to be getting Core Data into a state that it didn’t expect.
SQLite
UNIQUEconstraints really cannot be relied upon. I’ve now seen multiple cases of duplicates (sometimes dozens of the same row) because the database was damaged and so the index enforcing the constraint didn’t work. Recovering such databases is not straightforward because building a new database will fail due to constraint violations.I had only anticipated disk full errors to occur when saving a database, but they can also occur in other situations and get reported as
NSFileReadUnknownError.
Previously:
5 Comments RSS · Twitter · Mastodon
What Apple should do with future versions is use the Blocked file that people have been creating since they introduced it and have it write rules when some enters when blocking the email address. It should also work across the Apple ecosystem on a Mac, iPhone and a iPad, though my thinking right now Apple is having problems with their ecosystem and not really saying anything about it since everything from iCloud to Messages and Photos have come to almost a grinding halt.
SQLite UNIQUE constraints really cannot be relied upon. I’ve now seen multiple cases of duplicates (sometimes dozens of the same row) because the database was damaged and so the index enforcing the constraint didn’t work. Recovering such databases is not straightforward because building a new database will fail due to constraint violations.
This occurs regularly? Is this new? Did the version of SQLite change?
That this would be common enough to include in release notes is amazing and amazingly depressing.
@Ruffin It’s not common or new. I’ve been seeing this now and then since SQLite 2. I presume it’s because the drive/SSD is not fully reliable rather than anything to do with SQLite. I also used to see customers with damaged plist files all the time, even when using atomic writes. It’s depressing, and I’m not sure why these issues aren’t discussed more. But, context: the posts here are my development notes, not the release notes.
Regarding @retroactive, in the Swift Evolution proposal related to that, it mentions that you can suppress the warning in a backwards-compatible way by fully-qualifying all the type names in the extension declaration.
@Wes Thanks! That’s kind of obscure, like suppressing GCC warnings by adding extra redundant parens. I wish Swift had a real preprocessor so that we could, e.g., conditionally compile out stuff that the old compiler doesn’t understand.
