As part of WWDC this week, Apple introduced a new MailKit framework for macOS Monterey that enables developers to create Mail app extensions that block content, perform message and composing actions, and help with security.
/article-new/2021/06/mail-app-extensions-macos-monterey.jpg?lossy)
There will be four main categories of Mail app extensions, according to Apple:
- Compose: Extensions that provide new workflows when composing emails
- Actions: Extensions that apply custom rules to incoming emails, such as an email being color coded, moved to a separate inbox, marked as read, or flagged
- Content Blocking: Extensions that serve as WebKit content blockers for emails based on specific criteria in an email's HTML code
- Message Security: Extensions that sign, encrypt, and decrypt emails when sending and receiving mail, with signed and encrypted icons below emails
Xcode 13, available in beta, includes a template for developers looking to create Mail app extensions on the Mac. The extensions can be built into existing Mac apps and can also be distributed through the Mac App Store, according to a WWDC session about MailKit, which is available on macOS only and not iOS or iPadOS.
In the WWDC session, Apple indicated that older Mail app plug-ins will stop functioning in an unspecified future macOS release.
macOS Monterey is available now in beta for developers, with a public beta to follow in July.
Top Rated Comments
As for the mail plug-ins, they were never a great solution. Apple will continually move away from systems like mail plug-ins that live in the memory space of another application to inter-application communication systems like extensions that allow an application to extend another application visually without sharing memory space MacOS Classic style. I, for one, am looking forward to having a mail extension system that provides a stable API and that doesn’t break with each point release.
But this is also a change that needed to occur. Previously, mail bundles would break between point releases. Not major releases, mere patches. Every time Mail.app got updated, these bundles needed to get updated, too, and, until they did, the bundles wouldn’t work. Now we have a stable API guaranteed not to break on point releases and that will likely be stable across multiple major releases. We’ll probably see more mail extensions as a result of this, while previously, it was only worth the effort to devs who were absolutely serious about email extensibility. This API could also be ported to MobileMail.app, which, until now, hasn’t had any extensibility (except maybe for jailbreaking, but even then, I don’t think Mail was a common target for jailbreakers looking to tweak the system).