Mail App Extensions
Meet MailKit: the best way to build amazing experiences on top of Mail. MailKit enables apps to easily and securely interact with the Mail app for macOS. We’ll deep dive into the MailKit API, and show you how to create extensions for composing messages, message actions, secure email, and content blocking.
In the WWDC session, Apple indicated that older Mail app plug-ins will stop functioning in an unspecified future macOS release.
Plug-ins still work in Monterey, and SpamSieve’s is already in public beta.
Currently, MailKit’s functionality is very limited. Unless it’s expanded in a future version, I think a lot of plug-ins will not be able to make the transition to extensions, a loss to both their users and developers.
For SpamSieve, I’m cautiously optimistic about extensions. In theory, the current Monterey API is sufficient to implement the core SpamSieve functionality, though implementing some of the more advanced features would require API changes (FB9176051, FB9176075, FB9176097). I say, “in theory,” because MailKit in the Monterey developer beta doesn’t work as designed/documented. Extensions are supposed to be able to access the raw data of the message, but currently they receive either incomplete data (FB9175977) or none at all (FB9176011).
This takes me back to why I wrote a Mail plug-in in the first place. I had resisted doing so because I didn’t want to rely on an unsupported private API. But the reason I ended up making a plug-in is that the official API (AppleScript rule actions) was buggy. The private API ended up being more reliable and faster. And I’ve even been able to patch Mail to fix some (FB7035263) but not all (FB7145734) of Mail’s AppleScript bugs and to tweak the interface to make it more readable.
The private API has proven amazingly stable. I’ve always tried to make minimal hooks into Mail, and so the updates needed due to Mail code changes have been minor. The main hurdles have been unrelated to the API itself:
When Apple sandboxed Mail, which meant that the plug-in could no longer communicate with the SpamSieve app via AppleScript. This required developing a new communication mechanism, making it zombie-proof, and making a new way to launch the app when needed.
The compatibility UUID policy, where instead of developers testing with new versions of Mail and updating their plug-ins as necessary, each new version of Mail requires each plug-in to be updated, even though most plug-ins don’t actually break due to minor Mail updates.
All the privacy changes in macOS 10.14 and later. Each subsequent version has added more hurdles to installing and using plug-ins, making installation and updates more complicated, and various system bugs can get in the way and require obscure reset procedures.
Issues related to code signing and notarization. Some versions of Mail require that plug-ins be signed. Some require that they not be signed. In some cases, the signing and installation location depend on where the user’s home folder is located.
So, while I’m excited to be able to build on a public API, I’m more excited that these other issues could potentially all go away, so that installation could be as simple as checking a box in Mail’s preferences. This could get the user experience back to what it was like before sandboxing.
The main downside of extensions is that, as mentioned, they are limited to only the specific features that Apple has decided to open up. They are paving a naturally worn path, which is great, but they are also prohibiting anyone from walking off of the road. Secondly, since extensions run in an isolated process they are at the mercy of any bugs in Mail itself. Increased security rules out good patches along with bad ones.
My plan for SpamSieve is as follows:
Keep supporting the current plug-in, since some users will remain on Big Sur and earlier releases for a long time. It will also offer the most extensive feature set, at least on Monterey.
Develop a Mail extension to be ready for the day when plug-ins stop functioning, and to identify any (additional) issues so that they can be reported to Apple well before then.
Develop a migration path from the plug-in to the extension.
Investigate other ways of potentially integrating with Mail in case Apple removes plug-ins before the extensions API is working. I don’t expect this to happen, but I’ve learned not to assume that any bug will get fixed.
8 Comments RSS · Twitter
We've seen a transition like this before: From Xcode plugins (which apple still uses internally) to Xcode Source Extensions (or whatever they're called), which are significantly more limited. Tons of plugins that I used didn't make the transition. I assume the same thing happening in this "transition" (more like massacre of software) from mail plugins to extensions won't make it across not because the developers don't want to, it's that the extensions are too limited.
As a side note, I don't like how everything is now an app (and that mail extensions and safari extensions need an app). There are many apps that just sit in /Applications so they can provide macOS services, or are settings for headless apps. They could use an installer package and use a System Preferences Pane, but instead they clog up my Applications dir. I wish Apple made the UX for that better.
@ Linus: I'm not sure about mail extensions, but Safari App Extensions don't have to live in /Applications. You can place them in ~/Applications, or maybe make your own dir, e.g. /Applications/Safari Extensions/. I would guess the same is true for Mail.
The app wrappers are a little weird, but an argument could be made that they're user-friendly*. They do have that classic Mac feel of "if you trash the wrapper, the extension is gone; nothing to worry about", rather than hiding in some obscure path inside Library. Installer packages create a level of abstraction that I've always considered troubling — you no longer understand, as a user, where stuff is going and why.
*) definitely not developer-friendly, though.
@Linus "Tons of plugins that I used didn't make the transition. I assume the same thing happening in this "transition""
The Apple Mail plugins slaughtering already occurred a few years ago because of the compatibility UUID which was like Order 66 for unofficial Mail Plugins. Apple kept changing the UUID even when nothing had changed regarding the "private" APIs.
The sandboxing of Apple Mail was the other change that led to the end of some 3rd party plugins. If your revenues did not depend on Apple Mail Plugins, your best choice was to stop developing those plugins.
@Sören "The app wrappers are a little weird, but an argument could be made that they're user-friendly*"
As user friendly as a Trojan Horse.
@someone Yesterday, Apple released macOS 12 Developer Beta 2, which made major changes to the API but didn’t change the compatibility UUID. This is not the first time this has happened. The UUID seemed like a reasonable idea to me when it was introduced, but the way it’s actually been used makes no sense to me. It, as you say, contributed to this slaughter without even really working as designed to prevent compatibilities. And, with macOS 11, Apple sometimes kept the same UUID for maintenance updates but then incremented the version number on its key, in effect forcing an update when even Apple intended for none to be needed.
Can you provide any guidance to write a Mail Extension for macOS Monterey?
I am mainly looking for an extension that stops Mail from marking a mail message as 'Read' as soon as th email item is selected.
I only want the mail to be marked 'Read' - when it is either opened in a window (double clicked) or manually marked as Read.
It should be fairly simple, but there is no real help or guides or documentation on this.
Any help or some sample code would be much appreciated?
@Guru: If you disable the preview pane, that should stop it from being marked read? (This possibly may only work in "classic layout". I'm still running 10.14, so maybe they have removed this in 11, but hopefully not?)
Hi,
do you know if the Mail extension allows the modification of the content of an email when composing or replying?
when right clicking on the body of the mail (composer view), a contextual menu appears: is this possible to add an item in there with actions on the content of the email being composed?
if one of the is possible, would you suggest some guidance?
thanks a lot.
