Snaps & automatic updates prove popular with email client, Mailspring
by Sarah Dickinson on 5 December 2017
In the latest interview with a snap developer, we spoke to Ben Gotow who is the lead maintainer of Mailspring, a free, modern email client for Linux, Windows, and macOS. Originally started and open-sourced by Nylas in California, Ben took on the project earlier this year after Nylas changed course and stopped development. Mailspring has more than 10k active users on Linux, and will offer the snap as the preferred install method beginning from this week.
Mailspring is free to use and brings a polished Mailbox-style UI to Linux along with modern features like unified inbox, threaded conversations and Gmail label support. A pro version can be purchased within the app, mainly aimed at sales and business users who do large amounts of outbound email and benefit from features like link tracking and read receipts.
Mailspring works with all IMAP email providers, and aims to take the best features from modern clients and deliver them across all platforms. A long-time macOS developer who only learned about Snapcraft this autumn, Ben explains in our interview why he sees Snapcraft as a step forward on Linux and prioritised shipping a snap in a matter of weeks.
How did you find out about snaps?
The Canonical team reached out to me initially and I was intrigued. Since we started shipping software on Linux in 2014, we’ve always been looking for a way to deliver automatic updates. Without an update system, we frequently get bug reports from Linux users who are many releases behind, running up against problems we’ve already fixed. It contributes to our support load quite a bit, since it takes time to classify bugs and write replies. We immediately started working on the snap once we heard about the benefits.
What was the appeal of snaps that made you decide to invest in them?
I see two main benefits to snaps. Automatic updates, as mentioned, was a big one. As far as I know, Snapcraft is the only solution that provides this across different Linux distros. Previously, we’d need to run a package repository for Fedora, an apt repository for Ubuntu, etc. to deliver updates, and we’d just ignore the smaller distros. We ship updates to Mailspring weekly, and re-downloading the app gets old fast.
The second benefit is trust. Previously we offered deb and rpm packages on our download page, but people would take those and repackage them for smaller distros like ArchLinux without our involvement. We were always a bit wary of this, and Snapcraft allows us provide these users with a direct, trusted installation method. While we could do this with Flatpak or AppImage as well, combining it with automatic updates makes a really clean solution.
How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process?
We wanted to use the sandbox containment for the security benefits so getting the app packaged was a little challenging. We had to audit our code for things that wouldn’t work in the sandbox, and ensure the plugs provided us with everything we needed. For example, outside the sandbox, the app can automatically make itself the default email client if you ask. Within the AppArmor sandbox, we can show instructions but we can’t alter your configuration ourselves. From a security standpoint, this is probably a good thing, but it did require changes to the app.
From an integration perspective, it was very easy to do. We were already using Travis to do automated builds. The Canonical team pointed me to a wiki page on how to add Snapcraft to that process and actually helped me over the phone to get it done in half an hour or so.
If so, how do you see the store changing the way users find and install your software?
We hope the store will become a discovery mechanism for software on Linux. Right now, most Linux users find Mailspring via blogs or articles and then we direct them to snapcraft.io/mailspring. In the future, we hope to see more people discover the app organically through Snapcraft. We’re also excited about the store providing a level of trust, since apps that require certain elevated permissions are reviewed prior to publishing. Linux users tend to be more adventurous, but as a macOS developer used to developer-signed applications, I’m happy to see a trust mechanism coming as part of Snapcraft.
What are your expectations or already seen savings by using snaps instead of having to package for other distros?
I expect the snap release with the automatic updates to lower the volume of support we need to provide. Partly as it is easier to install across multiple distros, and also because we won’t receive as many bug reports of using outdated copies of software. I spend a lot of time replying to emails to this effect so if that can be decreased, it will be a huge help.
What release channels (edge/beta/candidate/stable) in the store are you using or plan to use, if any?
We published to the edge channel about 2 weeks before stable – mostly for internal testing. For the most part, I see us sticking to using stable but we’ll probably use the beta channel for more significant updates, especially as the user base grows.
How would you improve the snap system?
There are two areas we would like to see. Currently, snaps don’t inherit custom desktop themes, so menus and dropdowns in the app are sort of an odd grey colour. We’re working with the Canonical team to sort that out soon. In addition, we ‘d also like to see snap pages (eg: snapcraft.io/mailspring) linked together into categories and made more browsable, so it’s easier for folks to discover Mailspring while they’re looking for another mail client, for example.