❌

Normal view

McKinley 1.0

7 September 2026 at 19:18

Amy Worrall (Mastodon):

McKinley is an all-in-one studio for drawing and annotating SF Symbols. It bundles vector tools with knowledge of the SF Symbols structure, so you can edit one set of objects across multiple weights, sizes and colours. Import SVG or start from scratch, live preview your work using Apple’s own renderer, and export directly to Xcode, so you never need touch the SF Symbols app again!

[…]

Gone are the days of converting your strokes and shapes to outlined paths before export. Keep everything how you drew it, and let McKinley handle the output.

[…]

Link your project’s asset catalog to your McKinley document. Then when you make a change, hit the Sync keyboard shortcut and it’s immediately populated with your latest version.

[…]

McKinley is a Mac-assed Mac app: a native AppKit UI, Quick Look previews and thumbnails for your documents, a full AppleScript dictionary for batch work, and the whole user guide offline in Help.

$60, no subscription. It’s been a while since I had to deal with custom SF Symbols, but I remember it being a major pain. I haven’t had the chance to try McKinley with a real project yet, but it looks very well done. I love seeing a new app ship with documentation and extensive AppleScript support, including sample scripts that you can install right from its script menu.

Mario Guzmán:

The icon isn’t just a symbol but a whole artistic creation on a canvas.

Look at how your tools are on panels that could be individually opened on their own auxiliary window. I can’t stand the single-window, everything buried into a single-sidebar design we get these days.

Amy Worrall:

SF Symbols rendering does a surprising amount behind your back: it interpolates nine weights from three masters, applies optical size adjustments, resolves hierarchical opacity ladders, and changes some of this between OS releases. Any preview I rendered myself might diverge from the real thing in ways nobody would notice until the symbol was in an app looking subtly wrong. (Obviously I aim to get my canvas rendering with the exact same nuance as Apple’s renderer, but programmers are fallible and the fewer ways things can diverge, the better.)

Apple provides no API for “here’s my SVG, render it as a symbol”. For a normal app using a custom SF Symbol, the symbol is compiled from an Asset Catalog in Xcode into a .car file (a compiled asset catalog) at build time. But there’s no ‘build time’ when I want to update a preview in McKinley.

My workaround involves compiling your symbol into a .car file at runtime, on every edit, by patching bytes into a template, then loading that temporary .car file into McKinley via NSBundle.

Previously:

Update (2026-09-08): John Gruber:

I mean just look at McKinley. It’s both beautiful and quite obviously a serious professional tool.

Update (2026-09-11): Amy Worrall:

Anyone used any great implementations of dockable palettes? (Adobe’s don’t count, I don’t think they’re great!)

I’m not going to go back to sidebars, but some kind of options/flexibility might work, if it doesn’t get in the way!

The Best Worst E-mail Client

21 August 2026 at 19:19

Rui Carmo:

Apple Mail is the first app open every day and the one I find hardest to defend, and I’ve been defending it for twenty years (longer if you remember the original NeXT mail client).

The broader story is one of abandonment.

[…]

Apple deprecated that API, replaced it with a (much more restrictive) MailKit surface in 2021, and proceeded to lock MailKit down so hard that barely anyone shipped an extension.

[…]

In particular, in this age of desktop AI agents, I come time and again across the fact that AppleScript support in Mail has been left to rot.

[…]

And searching for messages is such a mockery of a user experience that I’m not even sure how to describe it[…]

Watts Martin:

The last email program I truly loved was Bare Bones’ Mailsmith.

[…]

Now, I’ve tried a lot, like, a lot, of “modern” email clients. The built-in Apple email client is extremely straightforward, but underpowered. Thunderbird is too lumbering and heavyweight for what I want. Hipster ones like Spark are pretty, but focus on things I don’t care about. Mimestream is solid, but it’s Gmail-only. Microsoft Outlook is, unfortunately, Microsoft Outlook. MailMate is nerdy and, in some ways, the most obvious spiritual descendant of Mailsmith, but I find some of its UX inscrutable. Yes, I am aware of the irony of saying this just before describing an Emacs-based client.

And increasingly, commercial email clients are expensive and/or subscription-only.

Nick Heer:

I almost never use Mail on iOS 26. I just tried to insert an image from my photo library, and I could not figure out how to get back to seeing a keyboard. What a bizarre workflow. Still shocked some of this stuff shipped.

Rosyna Keller:

I haven’t been able to use Mail on macOS since macOS 15.4. It hangs on launch if any accounts are enabled. It feels like it’s been so many years since I filed feedback with sample logs and still Apple hasn’t fixed the hang.

Helge Heß:

I wonder whether I will ever see a time where Mail clients report accurate unread counts (spoiler: clicking on Inbox shows no new mall)

Well, I guess most other mail clients, Thunderbird or Outlook, get this right. But it never worked in any of the Apple mail clients. Like for decades now 🙃

Rishi Ó summarizes the promises for Mail later this year:

  • Improved Top Results

  • More reliable search indexing

  • Improved unread badge accuracy

  • Improved list formatting

Juli Clover:

iOS 27 has an overhauled search system that extends to the Mail app. Instead of surfacing results based on keywords and recency, Mail app search ranks results by relevance and intent.

I never found the problem to be relevance ranking but rather that it simply didn’t find certain messages at all.

Long press on any email and you can ask Siri to summarize, find an item in the email, track a package, get a flight number, save a photo, and more.

I guess that’s fine, but as Carmo notes there’s just a whole list of basics that need attention in iOS Mail.

Messages in Mail load faster, search indexing is more reliable, and unread badges between platforms like iOS and macOS sync more reliably.

Rayn Jones:

Mail search is still garbage in iOS 27. 😞 It’s just not better like they claim.

Previously:

The End of EWS in Mail and AppleScript in Outlook

20 August 2026 at 18:39

Microsoft:

Exchange Web Services (EWS) is approaching end of service in Exchange Online. We first announced this change was coming in 2018, when we announced that Exchange Web Services (EWS) will no longer receive functionality updates. In 2023, we announced that EWS will be disabled in Exchange Online in October 2026.

Today we’re announcing we will use a phased, admin controllable disablement plan that starts in October 2026 and concludes with a complete shutdown of EWS in 2027.

Apple:

Microsoft announced the upcoming end of service for Exchange Web Services (EWS) in Exchange Online. Apple is actively working with Microsoft to update Mail, Calendar, Contacts, Notes, and Reminders to use the Graph API in a future update to macOS 27, including a declarative configuration for device management services.

I’ve been eagerly awaiting Apple’s migration to Microsoft’s newer Graph API because EWS support in Apple Mail has long been buggy. It seems to have gotten worse in recent months, presumably due to server side changes as Microsoft prepares to shut it all down. Unfortunately, Apple is not as far along in the transition as I’d expected.

Jonathan Harbourne (and, alas, Claude):

What made a Mac feel like a Mac at work was the software that came with it. Mail that you could actually scan. A Calendar that was a separate application, so it could live permanently on a second screen instead of hiding behind a tab. Quick Look. Smart mailboxes. Spotlight that found things. Share sheets that worked everywhere. The system behaving as one coherent thing rather than a collection of vendor silos.

[…]

iOS and iPadOS Mail no longer depend on EWS. macOS Mail still does. Same company, same deadline, same protocol, and only one of the two platforms got the work done in time. Microsoft ended up writing the guidance Apple should have written, telling administrators in February that Apple Mail for Mac users would have to switch to Outlook until the applications were updated. […] Apple had years. It had a public deadline. It had, by Microsoft’s own account, one of the most widely used EWS applications in existence. And it let the clock run out.

[…]

Somewhere in every one of these migrations is a line in a change log that reads “users to move to Outlook”, as though a mail client were a fungible commodity, like swapping a stapler. […] This is not the death of the Mac at work. […] It is the death of the Mac experience at work.

Outlook for Mac feels very different from Apple Mail, and users are being squeezed from the Microsoft side, too. Microsoft will be ending the transition to New Outlook in October, but the new version is still missing many features that were present in Legacy Outlook (as well as Apple Mail). Microsoft had long promised that it would implement AppleScript in New Outlook before dropping support for the old version, but last week it changed course:

AppleScript workflows vary widely across organizations and often depend on behaviors from the classic app that don’t exist in the New Outlook. Because these patterns can’t be standardized, full compatibility isn’t feasible. We have decided not to move forward with this feature. We apologize for the inconvenience.

Back to Harbourne:

Access only ratchets one way. Mail was allowed because it worked, quietly, for years, over a protocol nobody was auditing. It has now been formally removed under a named cybersecurity policy. Getting it back would require someone in a security function to write a positive case for re-admitting a broad-permission third-party client to the corporate mail estate, and then put their name on it. Nobody’s career improves by doing that. Saying no costs nothing and is never wrong in hindsight.

So if Apple ships Graph support in Mail next year, the people who lost it will not get it back. The door didn’t swing shut. It was bolted, and the reason it was bolted is now written down in a policy document that will outlive the protocol that prompted it.

Apple has no leverage to change that, either. The organisations deploying Macs by the tens of thousands are not Apple partners in any meaningful sense. They are customers who buy boxes. There is no relationship to call on, no joint roadmap, no account team, nobody at Apple whose job it is to notice that a hundred thousand people just lost Mail.

October is when administrators will have to opt back into allowing EWS for a few more months, but some (like Harbourne’s) will be switching off support sooner.

Apple Mail and Outlook aren’t the only options, though. MailMaven supports both Graph and AppleScript.

Previously:

Update (2026-08-21): See also: Reddit and Mac Power Users.

Update (2026-08-24): See also: Mac Power Users.

Previously:

SuperDuper 4

13 August 2026 at 20:10

Dave Nanian:

The new version of SuperDuper is a ground-up rewrite, a tip-to-tail reinvention of what SuperDuper looks like, how it works, what it can do, and where I can take it in the future.

[…]

Documents have been retired and replaced with Copy Jobs, which are stored internally and organized by source. If you want to copy Macintosh HD, that’s where you start. Click, and you’re presented with one or more template copy operations, or you can start from scratch.

Configuration is done right inline by clicking bold, underlined link elements and selecting options from pop-ups. The effect of your choices is immediately reflected in What’s going to happen?, ensuring you know what to expect when you click Copy Now.

SuperDuper has been around for 22 years, and I’ve been using it since version 2 in 2006. Shirt Pocket had always been great about keeping the copy engine up-to-date with all the changes in macOS and its increasingly baroque file system structures. But the outward appearance of the app hadn’t changed much, aside from losing the brushed metal, and neither had the feature set. I know all too well how much work it can be as a solo developer just to keep an app working. Ironically, the better you are at adapting to the changing OS, hiding the complexity, and presenting a simple interface, the more it looks like you aren’t doing much. Actually, if you follow Nanian’s blog, you can see a fraction of all the stuff going on under the hood—tricky edge cases, macOS bugs, and undocumented behaviors that must be handled so that you can essentially just press a button and get a proper bootable backup.

Eventually, he found the time to rewrite the app, both the engine (which is faster and more robust) and the user interface (which is greatly expanded). My first reaction was: this is SwiftUI, isn’t it? And it is. You can just tell by the way the text reflows, all the different colored buttons and blobs, the hover effects, and how the design heavily emphasizes scrolling. (Like System Settings, it doesn’t remember scroll positions. Nor does it remember which disclosure triangles are expanded.) The keyboard navigation and focus behavior are off in places. For reasons I don’t understand, SwiftUI gets a lot of this wrong out of the box. In some cases, like the outline view for creating a copy rule, keyboard support was manually added and works as expected. But there are other places where arrow keys and type-selection don’t work. Sometimes I need extra clicks to get the proper focus. Sometimes the arrow keys scroll the window instead of changing the selection.

That said, this is one of the best SwiftUI interfaces I’ve seen. I think it successfully preserves the spirit of the app, making it really easy to configure things and see what’s going to happen, while streamlining the way documents/jobs are managed and expanding what you can do. It’s still essentially one window (plus a Settings with one checkbox), and you can still use it in the old way, but now you can also run multiple jobs at once and inspect their histories.

Click the Preview button and SuperDuper will run the copy without making changes and present you with a report that shows exactly what would have been updated, added, deleted, etc., had this been a real run.

This is great to have. If there are particular folders or files you want to check, you can browse the source tab of the preview to see what’s excluded or find them in the destination tab to see whether they would be added, updated, removed, or kept. The interface to browse this is a sort of columns view with only one column. It’s fast and easy enough to use, but keyboard navigation doesn’t work properly. I longed for it to be an outline view so that I could quickly expand an entire subtree and see at a glance which files would be changed. I also wished that it would show how much data would be copied.

SuperDuper 4 is much faster than before. And I’m not just talking 20% or 30% faster. Smart Updates are between 2x and, with the new Turbo feature, an order of magnitude faster.

It’s hard to benchmark such things, but my general impression is that this is true. The longstanding Smart Update feature copies only the files that have changed. This seems quite a bit faster than before and slightly faster than Carbon Copy Cloner. The new Turbo feature uses the FSEvents log to optimize finding such files. If macOS knows which folders might contain changes, SuperDuper can focus on those and not waste time scanning ones that are identical. When this works, it feels almost impossibly fast. SSD-to-SSD backups of my Mac’s boot drive will take 1–3 minutes instead of more like 20 minutes. This also seems to be faster than Carbon Copy Cloner’s similar Quick Update feature.

Unfortunately, for reasons seemingly out of the app’s control, sometimes Turbo isn’t possible. This can happen if you’ve modified the copy job or if there’s been a huge amount of file system activity since the last backup so that FSEvents doesn’t contain the necessary information. In such cases, SuperDuper will fall back on doing an old-school Smart Update. I found that excluding my destination drive from Spotlight made it much more likely that Turbo would work.

As much as I like Turbo, I don’t end up using it except for the daily scheduled backup of my boot drive to an always-connected SSD. For my other backups, I have multiple destination drives for each source, and I find that the user interface doesn’t scale so well to configuring a separate job for each. That leads to lots of scrolling. So, instead, I use just one job per source and select the destination I want before starting each backup. This counts as editing the job, so it won’t be able to Turbo, but I find that backups to slow spinning hard drives take a long time either way and are dominated by the copying speed rather than the scanning speed.

Successful and failed runs are shown at the bottom of the copy job, with color-coded dots that can be clicked to display details.

This is my favorite bit of interface design in the new version. It very compactly shows you the recent history for that copy job using the same format that’s used for showing the completion status of the most recent run. I can quickly see all the information I usually care about, and you can click a button to see more detailed information if necessary. The downside is that you can’t see as much information at once—or across multiple jobs—as if there were a dedicated log window, and it only shows the most recent 7 runs. But I think this tradeoff is well in keeping with the app’s spirit of making things simple and clear rather than offering every possible option.

The most baffling part of the interface is that after each backup completes or fails it shows an “Apple Intelligence Summary”. Much space is devoted to labeling this and to assuring you that none of your data went into the cloud. I just don’t see what the point of this is. 99+% of the time, my backup either succeeded or failed for a very predictable reason like running out of space. Why do we need AI for this? I trust the AI summary less than I would a hard-coded string from the developer. Perhaps in an obscure situation that the developer didn’t anticipate Apple Intelligence would be able to offer a useful interpretation, but I have yet to see that.

At a technical level, SuperDuper has been split into a “helper” or “server”, which runs the copy, and an interface, which is the part you interact with. That means that, once registered, you can quit the SuperDuper application and your backups will still run. They’ll even run if you log out!

It doesn’t much matter to me that it can back up without launching the app—I like to see its progress—but I appreciate the new architecture for scheduled copies. Schedules are now much better integrated into the app proper rather than being driven through AppleScript.

You can run any number of copies at the same time. If you have four backups you need to do, just click Copy Now for each, and they’ll all run simultaneously.

This is the most important new feature for me. I used to do all my clone backups with SuperDuper. But, over years, my backup needs grew. I now have five main source drives to back up. They are much larger than before, and APFS on spinning hard drives is really slow. Thus, the backups, even with Smart Update, can take a long time. That was a lot to manage with old versions of SuperDuper. Carbon Copy Cloner has long supported multiple simultaneous backups so that I could connect a bunch of destination drives, tell it to start, and when I came back they’d all be done. I didn’t have to be there to wait for each backup to finish and then start the next.

It was just so much easier, so I started using Carbon Copy Cloner for most of my backups. But I still liked SuperDuper and trusted its copy engine, so I continued to use it to do some of the backups of my most important drive (the internal SSD). I think it’s good backup practice to have redundancies, not just in terms of multiple physical drives and storage locations but also for the software creating the backups. Both are quality apps, but it’s possible that there’s a bug or a misconfiguration on my part that might prevent the copying of a file that I need. Why put all my eggs in one basket? Now that SuperDuper also supports multiple simultaneous backups, I’m using it for half the backups of all my drives. On one backup day I’ll do all SuperDuper backups, then the next time I’ll do all Carbon Copy Cloner backups. (I continue to use Time Machine and Arq for additional redundancy.)

If you try this, I strongly recommend writing down which app you used for each destination drive and then doing all future backups to that drive using that same app. And it works better to do the first SuperDuper backup with Erase and Copy rather than trying to Smart Update a Carbon Copy Cloner backup.

There are a variety of reasons for this, but the main one is the different ways that the apps deal with APFS snapshots. Both use snapshots on the source to ensure they’re copying from a consistent state. And both mark completed copies with snapshots on the destination. But the retention of the destination snapshots is very different.

Carbon Copy Cloner can keep them around essentially as long as you have enough free space. It can also prune them out of order, so that you have daily snapshots for the last month and weekly ones going back further. This is managed by the app, though you can also manually delete snapshots yourself using Disk Utility.

SuperDuper’s snapshots are automatically managed by the macOS. I’m personally less fond of this design because in practice the system will choose to clean up old snapshots almost right away. I can’t count on being able to restore from any backup but the most recent. To me, this is a shame because APFS supports multiple snapshots, and there’s plenty of space on the drive to store them, but I can’t use them. It’s just not a design goal of the app.

Again, this ties back to how SuperDuper values simplicity. If it made longer-lived snapshots that weren’t cleaned up automatically, you might get into a situation where you (or another app) wanted to add files to a drive and couldn’t because it seemed to be full. You’d have to understand snapshots or have an app that could delete the SuperDuper snapshots to free up space. Third-party apps aren’t supposed to delete snapshots belonging to other apps, which is why you don’t want to mix SuperDuper and Carbon Copy Cloner on the same destination. If the former needs more space to complete a backup, it won’t be able to purge snapshots created by the latter.

The status information for the backups that are in progress is shown right in the Sources section of the main window. You can see at a glance which drives are being copied and when they’re all estimated to finish. I haven’t found the estimates very accurate, so I’d prefer to see the start time and the percent complete. Flipping between multiple active jobs to check their detailed progress is kind of a chore, but if all you need is the summary information you can close the app and monitor it from the new menu bar icon.

SuperDuper 4 now supports copying to and from any file system the Mac supports. Using a “Photos” drive with both Windows and Mac that’s formatted as exFAT? No problem: you can copy it.

It can also copy individual folders rather than just entire volumes, if you drag them into the sidebar.

I’ve added Shortcuts support, so you can create a shortcut that runs before or after a copy, on success, or on error. Want to send an email on success or failure? Beep when copies are done?

[…]

Not only does SuperDuper let you call a shortcut from a copy—you can create, run, and check on a copy job from a shortcut!

There’s a lot of potential here, and the completion shortcut receives a bunch of JSON describing what happened so that it can make decisions about what to do. On the other hand, I would rather see AppleScript support, as I find Shortcuts confusing and inconvenient. I wish that common completion actions like sending e-mails were built into the app so that they were easier to set up. (You can choose to eject the drive, post a notification, or sleep the Mac without having to write a shortcut.)

In all the years SuperDuper has been on the market, we’ve never charged for updates and never even raised the price. That’s 22 years of free updates.

The Apple Silicon version was a paid upgrade, but you could run SuperDuper 3 in Rosetta with an old license and still get all the features.

Version 4 costs $43.95, with various upgrade discounts based on the purchase date. There’s no discount if you purchased before July 2020, but us old timers got so many years of free updates it was one of the best deals ever in Mac software. Regardless, it’s not a high price for peace of mind. The new version is, I think, a massive improvement, maintaining the spirit of the original while modernizing and expanding it.

I’ve already said that I use both SuperDuper and Carbon Copy Cloner. I think both are excellent—great apps with great customer support. With SuperDuper 4 they’re more similar than in the past, but they remain very different. If you must pick one, I would say that Carbon Copy Cloner is better if you want lots of options and control; if you want persistent snapshots, verification, copying of cloud-only files, or detailed logging; or if you have a very large number of backups. (It does have a Simple Mode, but it’s arguably too simple and limiting.)

SuperDuper is better if you care about bootable backups or want something simple but not too simple. There’s documentation, but you probably won’t need it because so much is explained within the app’s interface. It’s just really easy to set up a backup, see what it’s going to do, see what it’s currently doing, and see what it did before. Pretty much everything happens in a single window, without tabs or separate modes. SuperDuper is all about striking a good balance for most people, doing the right thing with a minimum of fuss.

See also: Adam Engst and Accidental Tech Podcast.

Previously:

Update (2026-08-14): The developer wrote in to say that SuperDuper does try to remember the scroll position in the main window, just not across launches. With the current version, 4.0.2, I find that this mostly works but that it gets thrown off if I’ve expanded any of the triangles to see more details about the currently running job. Then my carefully positioned view will be shifted a bit when I come back to it. It’s hard to get this exactly right.

He also had a great tip about a hidden feature that can relieve some of the scrolling issues I encountered: you can click multiple times on a drive in the list of sources to have it jump to the next active job for that drive, scrolling it to exactly the right spot. When the sidebar has keyboard focus, you can also do this by pressing the Spacebar.

See also: Dan Moren.

Update (2026-08-20): SuperDuper 4.0.3:

For those with a lot of volumes, there’s now a sort control for the source list: you can alphabetically by type, or purely alphabetically.

There’s now an option in the sort pop-up that adds a few sections to the source list.

I like being able to separate the source drives from the destination drives. The update also improves VoiceOver support.

Update (2026-09-09): See also: John Gruber.

Previously:

Update (2026-09-16): SuperDuper 4.0.6:

Click the n copies running pill to filter to just those jobs. If you have a lot of copy jobs for a given source, you can filter the list with a click.

[…]

SuperDuper now picks a band size that suits the image’s size, balancing the number of bands with their size.

[…]

There’s now a third-party application, Open Backup, that can notify mobile devices (iPhone and Android) when backups run.

AppBITS: TerminalWidget Turns Scripted Output into Visual Widgets

9 August 2026 at 23:04
Tired of checking Terminal to see if your script finished? TerminalWidget displays command line output, Shortcuts results, and AppleScript data as customizable widgets that sync across your Apple devices, giving power users a visual dashboard for their automations.

macOS Hidden Treasures: Copy and Paste

Pasting Quoted Paths and Escaped Terminal Text

3 August 2026 at 21:35

Anthony Reimer:

When you are shell scripting or working in Terminal, sometimes you want a quicker way to enter the path to a file or folder, particularly if you have already navigated to it in the Finder. One way that works in Terminal is to drag the file or folder from the Finder onto the Terminal window, which then types the path into the current command. However, another method was introduced in El Capitan (OS X 10.11) that allows you to copy the full path onto the clipboard.

In Finder, you can hold down Option and choose Edit ‣ Copy Pathname.

Starting in macOS Sequoia, copying the path to the clipboard using the method described generates a path that can be directly pasted into the Terminal or a script and be interpreted as that path without further manipulation.

It adds single quotes and or escapes characters, but only if necessary.

There are certainly some people who are unhappy with this change in behaviour but most Mac Admins will not be among them.

You can get the unescaped path via AppleScript.

Anthony Reimer (via Miles Wolbe):

Graham Pugh pointed out that if you have text on the clipboard, you have the option of pasting that text “escaped” in Terminal. Simply copy the text from whatever source you choose (e.g., the output of an AutoPkg run, where paths are not escaped), then in Terminal choose Edit > Pasted Escaped Text or use the shortcut Command-Control-V.

[…]

As a bonus, this concept can be applied to a tip I learned from Armin Briegel a few years ago, namely that if you select something in Terminal that you want to then paste into the current shell command, you can skip the copy-paste dance and instead just press Command-Shift-V to do it in one step (or if you prefer menus, Edit > Paste Selection). If you add the Control key to that sequence, the text pasted is escaped (Edit > Paste Escaped Selection or Command-Control-Shift-V).

MailMaven 1.2

27 July 2026 at 21:11

SmallCubed:

AppleScript support makes it possible to automate message processing and connect Maven with other applications such as Hookmark, EagleFiler, Filemaker, and DEVONthink. Almost anything you normally do by interacting with MailMaven’s interface, such as searching for messages, tagging, filing, flagging, and composing, can now be automated.

[…]

AppleScript makes it possible to control Maven using the natural language capabilities of AI assistants such as Claude and ChatGPT via a MCP server. […] To connect AI assistants to Maven, we have developed a basic MCP server that implements over 25 end points. This can be downloaded and installed from our MailMavenMCP repository on GitHub. With the MailMavenMCP you can instruct your assistant to access and process messages without the need to write any AppleScript. For example, if you want a summary of the conversation you are reading, simply instruct the assistant to “Summarize the conversation of the currently selected message in MailMaven”.

The AppleScript support is really impressive. It’s extensive and thoughtfully designed and implemented, with performance in mind:

A query is a temporary AppleScript-based smart mailbox that can are used to locate and examine/manage messages.

Using queries is much faster than iterating through messages in mailboxes because it uses Maven’s internal mechanism for locating messages that smart mailboxes use.

Depending on the scope and nature of an iterative search which can take seconds, if not minutes to process, queries are almost instantaneous. Moreover, queries have the ability to sort messages and filter duplicates.

[…]

Scripts can be performed from Maven’s inbox, outbox, and keystroke rules via the Run AppleScript Rule action.

I’m excited to see a new app leaning into this old technology, which remains unsurpassed. EagleFiler is already taking advantage of the AppleScript support to enable importing messages (with all their metadata) just by pressing a hotkey. I also expect it to enable some great new features in future versions of SpamSieve.

Previously:

SpamSieve 3.3.1

15 July 2026 at 19:53

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:

AI-Generated Shortcuts

16 June 2026 at 20:34

Hartley Charlton:

Apple today announced that users can now describe a shortcut in natural language, with Apple Intelligence automatically building the automation in the background.

Marcus Mendes:

Users can simply describe what they want, such as “when I’m leaving work, text my wife with my expected ETA,” and Shortcuts will actually build the shortcut to make it work.

This sounds great in that I find creating shortcuts annoying. It’s not always clear which building blocks I should be using, and stringing them together properly seems tedious and fiddly. On the other hand, I dislike how AppleScript doesn’t get first-class support for the functionality and triggers that are available to Shortcuts.

Simon B. Støvring:

Data Jar got sherlocked, and that genuinely makes me happy.

Simon B. Støvring:

Apple should let users filter out and maybe even rewrite notifications from any app using Shortcuts.

[…]

The new notification automation trigger in Shortcuts is super cool. As far as I can tell, it won’t let me modify the notification content or filter out notifications based on the content, but it’s still a quite powerful addition.

[…]

Third-party automation triggers in Shortcuts are now possible. Sort of.

Just send a notification containing data meant for the new notification trigger to consume.

Anders Borum:

iOS 27 allows 3rd party shortcuts actions to run for longer than 30 seconds making me publish 2 actions that have been hidden behind feature flags for years.

Create cloud servers, run commands and destroy them again right from Shortcuts.

Previously:

Update (2026-06-26): Jason Snell:

This is as close as we’ve come, across 40 years, to the original dream of putting computer power in the hands of everyone. You can literally tell your device what you want it to do, and when—”every morning show me my to-dos and calendar events for the day”—and it will generate a program to do it and a schedule to run it.

[…]

Yes, there are lots of limitations. Describe a Shortcut doesn’t work with third-party apps, only Apple’s own stuff (at least, for now). It can sometimes get confused, especially with complex queries. And it has an interesting tendency to kick things to the Use Model action—why am I not surprised that an AI model likes to build Shortcuts that themselves use AI models?

But when it works, which is most of the time, it’s magical.

Simon B. Støvring:

Shortcuts on macOS Golden Gate is… Something.

Dedicating that much window space to a larger shortcut tile and a text field feels incredibly wasteful.

❌