Technology is a medium that enables us to achieve things in life, ideally in a pleasant way. In the software world, operating systems, programming languages and application frameworks are the tools of the trade. But you need the right tool for the right job. If you’re thinking about writing or porting your code to snaps, there are some interesting things you should consider before you commit yourself.

Strictly Come Snapping

The reason why this article should be useful stems from the fundamental differences in how snaps behave compared to classic Linux applications. Creating a snap isn’t just a matter of declaring instructions in the snapcraft.yaml file (recipe), which will be used to create the final artifact, the snap, which users can then install and run. It also requires some understanding of the new paradigms and concepts that snaps introduce. These could pose a hurdle, especially if you are already used to working and developing code in a certain way.

The primary one: security confinement. Snaps are designed to be self-contained applications that run in an isolated, consistent manner. The underlying service, snapd, provides the necessary abstraction mechanism between the operating system (one of 40+ distros) and the application code, so the same snap can run reliably, without the developer or the user having to think or account for many subtle differences between these 40+ distros.

The snapd service also provides security – a set of allow/deny rules, governed by AppArmor (and other security tools). By default, snaps are strictly confined, and that means no access outside their private world. Then again, such snaps aren’t really useful, as they cannot access system resources, like the filesystem, camera, network, etc.

To that end, you can use interfaces, which allow you to punch granular, very controlled holes through the confinement and provide useful functionality to your applications. For example, a browser will need access to the network, to the disk to read and write the user profile, possibly the video devices, audio so it can play sound, and more.

Therefore, as a developer, you need to consider the capabilities of your applications and possible limitations they may have if they were to run in a contained manner where access to any resource normally available to your user isn’t automatically granted. Sometimes though, even a liberal use of interfaces won’t be enough.

Snaps can also be put under classic confinement – a security level equivalent to what your application would have on the host running from a DEB or a RPM file. However, it’s only intended as a stopgap measure in most cases, and it re-introduces the problems that the classic Linux systems have – possible library dependency issues and host-wide access. That said, in some situations, you will have to use classic (or choose not to use snaps). For instance, archive managers and IDE often have to access arbitrary locations on the system or run arbitrary binaries (like external editors, browsers, etc). Then, classic confinement is the only method that will work reliably for your applications.

Find the source, Luke

The Snap Store does not limit its developers to open-source or free software only. You can also upload snaps created from closed-source code. Most of the time, this will work seamlessly. However, in some cases, if you do use closed-source software, you need to be aware that some components of the snap development ecosystems aren’t suitable for your use. We will address some of these shortly.

The Grand Design

The Snap Store supports six hardware architectures. Not only can you build your snaps for 40+ distros, you can also build for different platforms, which is quite handy. Furthermore, you can use Launchpad and the integrated Build Service (in the Snap Store) to build for these different architectures. This can be extremely useful if you don’t have the necessary hardware to compile locally.

In fact, snapcraft, the command-line tool used to develop snaps, allows you to dispatch remote build jobs to Launchpad, without ever leaving your terminal. However, such tasks are sent with all the code in the open, so if you’re building from source, you probably shouldn’t use the remote build feature. On the other hand, since snapcraft can (also) use binary assets as its source, you may be able to use the remote build option without opening up your sources.

License to Snap

Another aspect of software distribution worth considering is licensing. You can set different licenses in the Snap Store, but this is a finite list, based on the SPDX License List. If you require a different one, you may want to contact the Store team, to see whether it can be included and displayed next to your snap.

Moreover, if your applications are designed to display an interactive license agreement during the installation or runtime, whereby the user needs to accept/reject the terms, at the moment, the Snap Store does not support such functionality. You could choose not to display the license, or add a new step in your software behavior, such as a first-launch trigger that shows the license, but this may also introduce divergence in how you build your software (for different packaging formats).

A Fistful of Snaps

The Snap Store does not have a payment mechanism right now. If your software costs money, you can publish snaps that allow users to input license keys, can redirect to an online store, or has a built-in payment gateway. However, there is currently no functionality to let you collect payment from the user before they are allowed to download and install the application.

App to app

Your software may rely on inter-application communication, i.e. it can receive or pass on information to other programs. If you use strict confinement, you may want to consider the possible use cases and implications in how you achieve the desired functionality.

With snaps, the simplest way is through the use of XDG desktop portals, which support a range of common features like opening URIs in other applications, device power management inhibition, emails, showing notifications, screenshots, and more.

The publication

The last thing to consider is the placement of the built snap in the Snap Store. The process comes with an automatic (and sometimes manual) security review of your application to make sure it is packaged in a secure, user-friendly way, that there are no glaring security holes in your setup, or that your software is not trying to do things that would break the confinement.

The Snap Store also uses a fairly granular mechanism of channels, which allow developers to support multiple major versions of their software in parallel, offer stability-based revisions, and publish testing-only short-lived branches. Snaps can also be private, so they are only accessible to the developer and their collaborators.

The store concept may be new to many Linux developers, as they would traditionally have their code hosted in software repositories. The store provides a friendly visual frontend to users, complete with rich descriptions, screenshots and videos, all of which are designed to make your application stand out. A good snap page can help entice users to install your software. Similarly, a barren snap page can deter users. You should invest time in making sure that everyone has the best possible experience. The Snap Store also offers developers some metrics on their snap usage (weekly stats based on distro, version, architecture, and other attributes). You can use these to understand how your application is trending, and make adjustments if needed.

Summary

This article should help you get started building snaps with the right expectations and awareness of the platform’s current capabilities and the differences from traditional Linux software development. That way, you should have a faster, more pleasant experience. If you have any questions or comments, please join our forum for a discussion.

Article preview thumbnail, Photo by Dan Gold on Unsplash.