Guide to Distributing Electron Apps For Linux

Linux is a weird and wonderful operating system. I use Linux full time, but not gonna lie, I’ve had a love hate relationship with it since I first tried Ubuntu in 2006.

As an Electron application developer it’s better to think of Linux as similar to how we think about all the different flavors of Android. What I mean is there are many different flavors of Linux (called distributions) which are all different, but all Linux under the hood.

Unlike Android, the distribution diversity has also created variation in how software is installed.

However, from an Electron developer perspective, Ubuntu is still by far the most popular version of linux for Laptop and Desktop computers. For example the Steam game store only officially supports Ubuntu.

The diffent package formats of Linux

Back in 2006 when I first used Linux there were three ways to install software for Linux:

1. DEB files via an APT repository - For users of Debian and Debian derivatives, like Ubuntu.
2. RPM files via a YUM repository - For users of RedHat and CentOS derived systems, like Fedora
3. From Source - For any Linux distribution you can download the source code of the software, then compile and install it yourself.

This is still true today, deb and rpm packages are still the primary way in which system packages are distributed in Linux. However recently several other package formats have been introduced, as a way to try and sandbox third party software.

1. SNAP Images - Created by Ubuntu developers, Canonical, snap packages are sandboxed (in theory) for better security. Most Snaps are distributed through a central (and closed source) Snap store
2. FlatPak Images - Similar to Snap packages, Flatpak provides an isolated environment for software, but has a more community-focused distribution model, although most packages are distributed through Flathub
3. AppImage - AppImages are totally standalone files that can be downloaded and executed like a regular binary. They also sandbox the application being run (somewhat), but unlike Snap and Flatpak there is no real centralized ‘store’.
4. Arch User Repository (AUR) - For users of the Arch Linux distribution, the AUR is the primary source of third party packages, it is most similar to Apt and Yum.

If you have to pick a single format

If you are already getting overwhelmed and you need to just make a quick decision and go back to work, the answer is that you should use the AppImage format.

If you build your Electron apps with Electron Builder (which you 100% should be), AppImages are super easy to build, don’t require you to sign up for an online developer account anywhere, don’t require you to do any fancy signing, they auto-update with electron-updater, and can just be hosted on your website like a regular file.

# It's so easy!
electron-builder build --linux AppImage

Every distribution has the ability to run AppImage files, so you can cover every distribution with this one build.

The best mix of packages

My recommendation is that you build at least 2 packages, but up to 4 packages in this priority order:

1. AppImage
2. Snap
3. DEB
4. RPM

Why build so many? Well Linux users are very particular, and there are a bunch of heated arguments discussions in the Linux community about which package formats are “good”, and should be invested in.

Personally, I use Ubuntu so I prefer to install DEB files whenever I get the chance, but will use an AppImage or a Snap if I need to.

Why prioritize AppImage and Snap Packages

Both formats (in theory) run on all distributions, and if we ignore the drama over Snap packages, provide you with great coverage for the major distribution, Ubuntu.

Stick the AppImage on your website along side your exe and dmg files, and upload your snap to the Snapcraft store.

Be warned, for Snap distribution you will have to figure out which interfaces your Snap needs in advance (eg home directory access, ssh key access, network access, usb device access).

Why DEB and RPM are last on my list

A key part of distributing an Electron app is automatic updating. Well with DEB and RPM packages to provide a way for them to automatically update you’ll need to set up and host your own APT or YUM repository.

Plus, each version of each distribution can have a different mix of system packages and libraries, so thee’s no way to know for sure that your app will work right.

At the time of writing, Beekeeper Studio still doesn’t provide an RPM file, but it has provided a DEB file since inception, as Ubuntu uses DEB, and that is a large part of the user base.

Setting up APT and YUM repos is a bunch of extra work that isn’t really worth it unless you really care about linux users. If you have to pick one it should be an APT repository so you can distribute DEB packages.

I’ll follow up this post with another article on using S3 to distribute DEB and RPM packages.