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:
Update (2025-10-04): John Gruber (Mastodon):
Fox, in its opening paragraph, describes Bondi as having “asked” Apple to remove ICEBlock from the App Store, but Bondi’s own statement uses the verb “demand”. The difference is not nitpicking. No one, not even Bondi, is claiming any aspect of ICEBlock is illegal.
[…]
Reporting and publishing where police are policing is free speech and fundamental to the civil rights and liberties of a free society.
[…]
We can all wish Apple had fought this “demand”. I certainly do. […] But I can also see why it’s not. Pick your battles.
You could look at this as a story about the Trump DoJ, and I don’t think that would be wrong. And you could argue that ICEBlock is more in the public interest than the DUI checkpoint apps, even though both are legal and both are free speech. But, zooming out, this is the same government-Apple pattern as before. Here, there were months of complaints from the administration about the app, then the recent shooting provided the justification for AG Bondi’s “demand,” after which Apple caved. Back in 2011, a group of Democrat senators, including the Majority Leader, “ask[ed]” Apple to remove DUI checkpoint apps from the App Store. Apple’s position at the time was that these apps were a “net positive” in terms of public safety. Then the government brought Bud Tribble before the Senate Judiciary Subcommittee, where Senator Schumer “demanded” and Senator Udall “lambaste[d],” and Apple changed its mind and banned the apps. The throughline is that Apple will stand up for customer privacy, unless that conflicts with a local law or Apple already has the requested data. But when it comes to apps that governments don’t like, it generally seems to remove them (as does Google).
dmitriid:
Imagine if there were independent stores on iOS or that users could install these apps from different sources.
Users should be able to just download and install the apps they want to run on their devices. Once, this was normal and expected, but now there’s a scary term for it: sideloading. The Web is sort of an escape hatch, but even its openness is in question, as both Apple and Google are working on attestation, which limits what users can do with their browser.
Previously:
Update (2025-10-06): Brent Simmons (Mastodon):
I can picture a future, as I bet you can, where RSS readers aren’t allowed on any app store, and we’re essentially required to use billionaire-owned social media and platform-owned news apps.
But there are issues with making NetNewsWire a web app.
[…]
A world where everything is on the web and nothing is on the machines that we own is a sad world where we’ve lost a core freedom.
[…]
What I want to see happen is for Apple to allow iPhone and iPad users to load — not sideload, a term I detest, because it assumes Apple’s side of things — whatever apps they want to. Because those devices are computers.
Cory Doctorow (Hacker News):
Apple does not permit its iPhone customers to install software unless it is delivered via their App Store. They claim they do so in order to protect their customers from their customers’ own bad choices about which apps to install. But time and again, Apple has shown that they exercise this control over their users to pursue their own ends, blocking:
- A dictionary (because it contained swear words);
A game that simulated working in an Apple sweatshop;
An informative app that cataloged civilian casualties of US drone strikes;
The Tumblr app because some Tumblr blogs contained adult content; and
Working VPN apps for the entire nation of China.
Jeff Johnson:
Should anyone in the world be able to distribute iPhone apps? Yes.
Should anyone in the world be able to distribute iPhone apps with the explicit backing of Apple? No. Absolutely not.
[…]
The only reason this totally fucking nutty situation exists is that the purpose of the iOS App Store lockdown is NOT to protect Apple users but rather to extract money from developers.
I’ve always thought it was a mix of wanting money and control. But, in a way, Apple ends up with less control because, with no alternative distribution, it can’t really make the store the highly curated experience that you’d imagine it would want. Instead, the store is missing some apps that customers (and maybe Apple) would want but that governments don’t, and the store is also full of junk apps that customers don’t really want but that don’t really violate any rules so Apple kind of has to let them through.
Update (2025-10-08): John Gruber:
The only content ICEBlock contains is the location of law enforcement activity. Waze — and more notably, Apple’s own Maps app — do the exact same thing for highway speed traps.
This gets back to my earlier point that Apple has gone down a slope of policing apps based on how people choose to use them vs. based on what the binary actually does.
Previously:
App Store App Store Takedown Department of Justice (DOJ) ICEBlock iOS iOS 26 iOS App Law Enforcement Privacy Sideloading
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
