Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

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.

Install from Ubuntu Store

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.

Related posts


gbeuzeboc
25 September 2024

TurtleBot3 OpenCR firmware update from a snap

IoT Article

The TurtleBot3 robot is a standard platform robot in the ROS community, and it’s a reference that Canonical knows well, since we’ve used it in our tutorials. As a matter of fact, we use it to demonstrate some of our work, such as distributing a ROS stack through snaps. This robot embeds two boards, a ...


Holly Hall
15 January 2024

Managing software in complex network environments: the Snap Store Proxy

Internet of Things Article

As enterprises grapple with the evolving landscape of security threats, the need to safeguard internal networks from the broader internet is increasingly important. In environments with restricted internet access, it can be difficult to manage software updates in an easy, reliable way. When managing devices in the field, change management ...


Igor Ljubuncic
21 December 2023

We wish you RISC-V holidays!

HPC Article

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found themselves in the last group at some point or another; you sit down to perform a task relevant to your needs or duties, but suddenly the machine does not work as ...