Instead of writing blog posts about individual package updates, I think I’ll be changing things up a bit. My agents do a better job than me in summarizing the changes for individual releases, so I will from now on group them together, referencing the release notes on GitHub.
I am working a lot on a private project for a client at this moment where I am making MCP for all communication. Previously I would have hand-rolled REST API calls with URL sessions and JSON decoding for talking to Google Drive or Parse platform.
SwiftMCP
But for this new project I figured I wanted to up the game and use MCP wherever possible. The main advantage is that you have static types and also a back channel that allows me to stream notifications and log events to clients. Also as I explained earlier since I am owning both sides of the MCP communication, all I need to do is to seat up my @MCPServer properly, and the client part gets automatically generated for me.
Long story short, this forced me to address a couple of shortcomings in SwiftMCP. One such problem was how the Bojour+TCP transport would resolve the server. This was only looking for _mcp._tcp and while I had only a single one that was fine. But then I started having multiple MCP servers on my local machine – my client project daemon as well as the Post daemon – and suddenly my mail room stopped being able to trash processed emails.
Then I realized that it was connecting to the wrong server. So I enhanced the bonjour advertising to include the server name as well.
There was another shortcoming of Linux. The only way how I can know if my components would work on Linux are the GitHub actions that compile them for this platform. SwiftMCP on Linux was missing SSE communication for the client side. That’s now been remedied. I’m looking for a time when I will be able to actually deploy my Swift code on Linux platforms.
And I needed to broadcast log events to all connected MCP clients. So we fixed a problem where each session needed to be made current so that the sending wouldn’t crash with a precondition failure. See the full SwiftMCP 1.1.0 change log for details.
SwiftMail
SwiftMail seems to have sparked more interest as I can see from fixes and enhancements being contributed. This component has seen a lot of use on my part as well because it is the core enabler for my Post CLI, which my mail-room agent is using to keep abreast my emails.
We had completed the capability matrix for the major email servers Gmail, iCloud, Exchange, and Dovecot. And on the software side NIOIMAP and SwiftMail. The features which were in NIOIMAP and most servers, but not yet in SwiftMail very obvious candidates for inclusion.
A lot of tinkering went into figuring out to observe mail servers over a long time and deal with server-side disconnects and other ways how the postd might crash. Unresolved promises and what not. Thanks to other people’s testing we found quite a few places that needed stabilizing.
The latest change was to use the primary connection for IDLE and to spin up – and connect – a new connection when a new email comes in. It turns out that establishing such ephermeral connections is actually quick and pain less anyway. See the full SwiftMail 1.2.0 change log for details.
SwiftText
One of the functions of SwiftText is the ability to generate HTML and PDFs from markdown. This is also exposed via the swifttest CLI via the render subcommand. HTML is not really editable for humans and PDFs are essentially static printouts also net meant to be edited by mere mortals. Lately I’ve been warming to DOCX – vulgo “Word format”.
When communicating editable documents with the non-Apple world it is very beneficial to do so with DOCX files. Behind the scenes those are like a strict XML dialect with many parallels to HTML. Because of this I implemented conversion of DOCX to markdown a while ago.
In the latest version I closed the loop and now you can turn markdown back into DOCX. The ideas is that if you have markdown output from an agent, you can just run it through swifttext and you have a format that the “outside world” can reuse and edit.
There remains a small area where Linux is behind the world of Apple: the use of WebKit. I am using WebKit to read web pages that have some JavaScript loading or rendering, to wait until the final DOM has been created and then I can pull the HTML and convert it to markdown.
Another area is that for some invoices that I get by email – looking at you Apple! – I need to save the email as PDF for my accountant. WebKit has a function to “print” a web page into PDF. So there are some availability gates around this code so that SwiftText still builds on Linux.
The good news for DTCoreText – which is stuck in ancient Objective-C history – is that my agents were able to figure out how to build for Linux and use libxml2 for parsing HTML. With the help of a contributor this part is now fully Swift. It now becomes possible to finally upgrade DTCoreText to full Swift as well. SwiftText has a HTML parser using libxml2 to build a DOM which then is converted to markdown.
DTCoreText works somewhat differently though. It keeps a stack of elements, but flushes pieces of NSAttributedString into a mutable attributed string. And modern code might want to generated SwiftUI AttributedString from HTML. So would I add this functionality to SwiftText and gate it for Apple platforms? Or would I make a DTCoreText 2 branch that implements those?
I am leaning towards the latter. The advantage might be that we can migrate the great number of unit tests we have in DTCoreText to Swift Testing and then replacing all with Swift should be an easy exercise … for an agent.
See the full SwiftText 1.1.0 change log for details.
Post
As I have alluded to above the second big driver for updates is my refining and enhacing of Post. For a few days now I am enjoying a more or less Inbox Zero with the mail-room skill I am working on. This archives markdown version of all newsletters I get, marks spam emails that were missed by my server-side spam filter and sorts out invoices for my business or private.
The emails from GitLab or GitHub concerning certain projects of mine get reported to Discord threads of the same name. So if a CI action on GitHub fails, I see it in the main thread about it. Same goes for comments to PRs and all other kinds of notifications.
The main function that enables this is that Post can call a script whenever a new mail arrives. This script gets a JSON representation of the most important meta info about the email as well as a markdown representation…. I’ll stop myself here from revealing too much more, because this warrants a blog post of its own when I am ready to release the OpenClaw skill to the public.
Back to Post now. My accountant managed to crash Post by sending me an email that had a single
libxml2 causing messed up german special characters.
Agents are able to create draft emails from markdown. Post turns the markdown into nice HTML for the main body and keeps the markdown as the plain text version. That needed some improvements. There’s also support for replying to – and quoting – a message. That’s been there for a while but it’s maturing nicely. Soon you will be able to say: “draft a reply to this new email from x, comment on the individual points and attach the latest PR as PDF”
And finally, most of the changes were ease-of-use improvements. Like for example I wanted to store invoice with a certain format like Apple_123123123123_20260513.pdf. Previously I had to download the file with its original name to a temp folder, find the file and then rename it. Now uniformly you can use the --output option for specifying a folder or file name. In the former case the original file name is used, in the latter the specified file name.
Read more in the full Post 1.2.0 release notes.
Conclusion
Me and my agent team are very busy these days, but – honestly – the greatest reward is to get questions, bug reports or even full pull requests from people who like to build on my OSS. It feels incredibly validating to feel some interest for a labor of love.
On the OpenClaw front, I have nothing new to report, Peter Steinberger stubbornly ignored an X DM, a personal email, my email to the OpenClaw contributor address, another X DM and me publicly venting. This level of ignoring me can no longer be accidental. What have I done wrong to not even get any response?
A little pick-me-up came – how would have ever expected that – via LinkedIn…
Their loss is your gain! So on a positive note, I have a lot to do these days anyways, and OpenClaw doesn’t want my help, then I’ll put my energy into more rewarding areas, like the ones I mentioned in this here article.
Related
Categories: Updates
