SpamSieve 3.2.1 is a maintenance release of my Mac e-mail spam filter.
This fixes the previously mentioned problem with AppleScript timeouts and POP accounts on macOS Tahoe 26. I found a workaround, but it’s still a mystery exactly what was causing the problem. First, why was AppleScript delaying and then timing out rather than just reporting an error? I still think there’s a general Tahoe issue that causes this in a variety of apps. Second, what is the underlying error and why does it only affect some POP accounts? I was not able to find any pattern in the configurations that were getting the error vs. working normally.
Oddly, with macOS 15.7, I got a few reports of errAETimeout with the Mail extension talking to SpamSieve. This had never happened before, and, again, there did not seem to be evidence that the target app was actually delayed in responding to AppleScript. It seems unlikely, but it’s almost as if whatever’s going on with AppleScript in Tahoe got backported to Sequoia.
NSStatusItem in Tahoe is sending KVO notifications that it became visible even when it’s been set to be hidden (and seemingly is correctly hidden).
I’ve been using Thread.callStackSymbols to stash some context information in my errors, but I had to reduce this practice because sometimes _NSCallStackArray (the lazy class that calculates the symbols) is many times slower than normal and was blocking real work from getting done.
I continue to receive occasional reports of Core Data crashes in _thereIsNoSadnessLikeTheDeathOfOptimism, where it seems like there’s no constraint conflict or optimistic locking failure, just a damaged database file. It’s unfortunate that Core Data can’t report this as a normal error when saving and instead takes down the whole app.
Previously:
Apple Mail AppleScript Core Data Key-Value Observing (KVO) Mac Mac App macOS Tahoe 26 Menu Bar POP SpamSieve
EagleFiler 1.9.19 is a maintenance release of my Mac digital filing cabinet and e-mail archiving app.
Importing from DEVONthink works again. They’ve changed some terminology, but EagleFiler’s import AppleScript didn’t have to change. EagleFiler just didn’t know—until now—how to recognize DEVONthink because its bundle identifier changed.
I had thought that macOS Sequoia was when opening direct Apple Help links broke, but I’ve now gotten reports that the problem also affects Sonoma. So this version of EagleFiler will use the Web browser workaround there, too.
I continue to have issues with notarization. The latest is that for the last few months I’ve gotten intermittent errors like this:
Error: No Keychain password item found for profile: AppleNotaryProfile
Run 'notarytool store-credentials' to create another credential profile.
I’m not sure whether this is the actual problem, though, because it looks like the keychain entry is still there. Nevertheless, I keep the notarytool command in PasswordWallet, and I run it when I get this error message, and then things work again—sometimes for a week or two, sometimes for just a few minutes.
Previously:
Apple Help EagleFiler Keychain Mac Mac App macOS 14 Sonoma macOS Tahoe 26 Notarization Programming
Ashley Oliver (Hacker News, MSN, The Verge, 9to5Mac):
Apple dropped ICEBlock, a widely used tracking tool, from its App Store Thursday after the Department of Justice raised concerns with the big tech giant that the app put law enforcement officers at risk.
[…]
Controversy surrounding ICE tracking apps intensified after last month’s deadly shooting at an ICE field office in Dallas, Texas, the latest in a series of attacks that appeared to be targeting immigration enforcement officers.
[…]
Apple said in a statement it removed ICEBlock and other apps like it.
“We created the App Store to be a safe and trusted place to discover apps. Based on information we’ve received from law enforcement about the safety risks associated with ICEBlock, we have removed it and similar apps from the App Store,” Apple said.
I’m surprised it lasted this long, since Apple also doesn’t allow apps for crowdsourcing DUI checkpoints, even though to my knowledge neither type of app is actually illegal. This is pretty much exactly how the HKmap Live situation played out, except that there Apple noted that the Web site could still be added to an iPhone user’s home screen. ICEBlock has no Web site (or Android app), so removing it from the App Store will eventually kill the service. I guess if you’ve already downloaded the app you can keep using it, but it won’t get any updates and can’t be transferred to new devices.
Previously:
App Store App Store Takedown Department of Justice (DOJ) ICEBlock iOS iOS 26 iOS App Law Enforcement
Jen Simmons et al. (Mastodon):
For the last 17 years, if the website had the specific meta tag or Web Application Manifest display value in it’s code, when a user added it to their Home Screen on iOS or iPadOS, tapping its icon opened it as a web app. If the website was not configured as such, tapping its icon opened the site in a browser. Users had no choice in the matter, nor visible way to understand why some sites behaved one way while others behaved another.
On Mac, we took a different approach. When introducing Web Apps on Mac in Sep 2023, we made the decision to always open websites added to the Dock as web apps. It doesn’t matter whether or not the website has a Web Application Manifest. Users get a consistent experience. Add to Dock creates a web app.
Now, we are revising the behavior on iOS 26 and iPadOS 26. By default, every website added to the Home Screen opens as a web app. If the user prefers to add a bookmark for their browser, they can disable “Open as Web App” when adding to Home Screen — even if the site is configured to be a web app. The UI is always consistent, no matter how the site’s code is configured. And the power to define the experience is in the hands of users.
Previously:
iOS iOS 26 Safari Web
