Better snap metadata handling coming your way soon

by Igor Ljubuncic on 23 April 2021

Open the Snap Store, click on any application you like – you will now see a page full of useful tidbits – screenshots and videos, application description, last update, license, contact data, and other information. The data shown here is often the first impression the user gets about the software, and can be a deciding factor in whether they want to install and use the application.

Keeping application metadata accurate and up to date is no small task, and requires attention from the publishers. Today, some parts of the metadata update process are less than ideal, and can introduce management overhead. In today’s article, we’d like to talk about an important feature change, which will streamline metadata handling, and make the snap publication process more robust.

To meta or not to meta?

In the current implementation in the Snap Store, metadata is parsed and extracted on every snap upload until the publisher makes a manual metadata change in the Store. This means that, in some scenarios, there could be a mismatch between the snap data and the Store data, making application lifecycle management less elegant.

Since the Snap Store does not inform the snapcraft users of the mismatch, the users must then manually push or force-update the metadata from the command line (using snapcraft’s upload-metadata feature). This can be cumbersome when publishers handle a large number of snaps, manage multiple tracks and applications, or frequently update their software.

Update Metadata on Release (UMoR)

The new proposed mechanism will allow a more robust handling of metadata:

  • By default, the Snap Store will extract metadata only from the first revision of a snap.
  • When there is a release to the stable risk channel for the default track, the Snap Store will update the metadata by extracting information from the released revision.
  • Existing snaps already in the Store will have the UMoR setting enabled.

If a publisher decides to turn the feature off, then the updates will require an explicit, manual update through the store Web UI. Later on, should the user decide to enable UMoR, the Snap Store will warn the user of any potential conflicts (metadata mismatch). In this scenario, the manually edited information will then be overwritten with the next release.

On the command line, snapcraft will also inform the user of any potential conflicts for metadata uploads, and will require the use of the –force flag, to avoid any accidental deletion of metadata manually inserted into the Snap Store.

snapcraft upload-metadata kompozer_4.snap
Uploading metadata from 'kompozer_4.snap'
Metadata not uploaded!
Conflict in 'icon' field:
In snapcraft.yaml: None
In the Store:      ''
You can repeat the upload-metadata command with --force to force the local values into the Store

Any manual change of the metadata in the web UI will set UMoR to off. The reasoning behind this is that typically, a manual, interactive change suggests the publisher wants to prioritize manually-entered metadata over what might be contained in a snap revision. In order to avoid overwriting any manually-entered data, the feature is turned off in this case.


A smooth, efficient developer experience is a crucial part of any software ecosystem. This also includes metadata, as it dictates how easy it is for developers to make changes to their applications, and how easy it is for users to discover software and make educated decisions based on presented information. Good metadata can help make your snap shine, and invite people to try your tools and programs. We also invite you to take a look at our Snap Store tour, to familiarize yourself with the different settings and options available.

We hope you will find today’s announcement useful. If you have any concerns or suggestions on the Snap Store or the metadata upload functionality, please join our forum and tell us about it.

Photo by Mathew Schwartz on Unsplash.

Newsletter Signup

Related posts

How to troubleshoot application issues and crashes with snapd gdbserver

Sometimes, applications may not run well, or they could even crash. When such issues occur, it is useful to have a consistent, reproducible method of triggering the problem, so that developers can have a reliable way and sufficient data to troubleshoot the issues and produce a fix. In the software world, the GNU Debugger (gdb) […]

The snap developer’s guide on how to migrate to new bases

A couple of weeks ago, we published an article about Ubuntu 16.04 entering Extended Security Maintenance (ESM), and the implications of this change for snap publishers. We talked about the different options available to developers and publishers who still may rely on the older bases in their build process – free Ubuntu Advantage (UA) toke […]

Should you ever reinstall your Linux box? If so, how?

Broadly speaking, the Linux community can be divided into two camps – those who upgrade their operating systems in-vivo, whenever there is an option to do so in their distro of choice, and those who install from scratch. As it happens, the former group also tends to rarely reinstall their system when problems occur, while […]