Getting ready for stable

Snaps can be released in the store to one or more channels.

One byproduct of this is developers can ‘hide’ unfinished applications, or snaps which aren’t production quality from users. However, once an application hits the stable channel, users will have expectations for functionality and presentation.

This page details some tips on getting your application ready for the stable snap store channel. Consider it a checklist of best practices for landing in the stable channel.


Snaps in the stable channel must either conform to strict confinement, or with approval, classic confinement. In general applications should be using strict confinement.

In the event an application cannot be strictly confined, we recommend starting a thread on the forum to discuss a way forward. If classic is required, check the process for reviewing classic confined snaps to check if an exception can be made, and then start a request thread on the forum.

See Permission requests for more information.


When strictly confining your application, ensure you’ve specified all required interfaces. Some interfaces are not automatically connected. This means users must manually connect the interface before your application receives that access. If you believe an interface should be automatically connected for your snap, you can request an auto-connection.

Those will each be discussed and reviewed in the open. In the event they’re approved, a store assertion will be setup so users installing your snap do not need to manually snap connect those interfaces.

See Snapcraft interfaces for more information.


If the snap contains only one binary exposed to the host, and that binary has the same name as the snap, there is nothing to do here. For example the pulsemixer contains only the pulsemixer binary.

However if you want the snap to expose multiple binaries to the host system, they will by default all be prefixed with the snap name. So a snap called atom which contains two binaries - atom and apm will by default expose atom and atom.apm to the host where the snap is installed. However, it is possible to request an alias for your commands. In this case an alias for apm was requested for the atom snap so users can invoke the apm command via apm directly.

See Commands and aliases for more information.


Store Icon

The snap store supports a single icon for the application, which can be manually uploaded on the “listing” page of your published snaps or automatically by adding it to the icon key in snapcraft.yaml. This icon will show in the Snap Store and other graphical store fronts such as GNOME Software. See Store listing icon for more information.

Desktop Icon

If the application is a graphical desktop app, then the snap should ship with an icon and .desktop file so that it will appear in the desktop menu. See Desktop files for menu integration for more information on how to do this.


The snap store supports uploading multiple screenshots which will be shown in the Snap Store and other graphical store frontends such as GNOME Software. See Store listing screenshots for more information.


An optional banner may be shown in the Snap Store and GNOME Software when an application has been selected by the store admins to be featured. See Store listing banner for more information.

Uploading a banner does not guarantee the application will be featured, but if it is, the banner will improve the appearance.


The application description is shown in the Snap Store, via snap info and on other graphical store frontends such as GNOME Software. It should accurately describe the application. See Store listing metadata for more information.

Support link

The support link in the store enables users to provide feedback about your application. It should point to a support site, forum or bug tracker. This field is maintained in the store dashboard General -> Edit -> Contact URL. See Store listing metadata for more information.


Does that mean I/upstream have to always keep a copy of the upstream’s .desktop file at /snap/gui/_snap_name_.dekstop and keep syncing with the original? That doesn’t sound very sane to me…

From: Application icon doesn't work in the launcher

Also IMHO this topic’s title is quite misleading, it should be renamed to be clear on what contents it presents. For example, I never clicked into it until it appears in my search results(and it is my second attempt to find an answer to the desktop entry icon problem).

What is the filename specification of the banner icon?

Here you go, it’s covered at Getting ready for stable

I only found this one:

I suppose the banner and the banner icon are separate files?

yes, banner.png is the big one, and banner-icon.png is the smaller one.

e.g. for spotify, here’s the banner.

and here’s banner-icon

1 Like

Does this means _app_name_ or _app_command_?

name: foo

    command: bin/foo-cli

The above example shows name and app being the same, resulting in a command called foo being exposed to the host.

name: foo

    command: bin/foo-cli

The above example will result in a app exposed to the host.

Does that make it clear?

1 Like

Yes, thanks!

The issue is that I found some topics claiming the snap_name has to be the same as the command_name but not the app_name.

What about snaps with multiple apps?

Same question. Any answer? My app looks good on the website:

But the .desktop file takes precedent in the software center, which isn’t what I want. I want the metadata from

Is that still true?..

Is there a way to get the link of our snap’s banner? I cannot find a way to check that banner has been properly taken into account, once uploaded it “disappears” from the screenshot section.

The only way I got the desktop icon to work was to manually copy the .desktop and .png files using the dump plugin.

    plugin: dump
    source: snap/gui
      pynsource.png: usr/share/applications/pynsource.png
      pynsource.desktop: usr/share/applications/pynsource.desktop

I also had to “organize” the files, otherwise the two files end up in /prime not /prime/usr/share/applications/

I also had to rearrange my source code directory structure so that the snapcraft.yaml file was located in a directory snap and the .desktop and .png files were located in snap/gui. I had previously kept my snapcraft.yaml in the root of my project, and simply had a gui subdirectory containing the .desktop and .png files. This failed to create the entries


and as such, my app’s icon was blank. My .desktop file by the way looks like:

[Desktop Entry]
GenericName=UML application
Comment=Pynsource UML reverse engineer Python source into diagrams

I was also confused for many hours by the different and contradictory information found on the topic of creating desktop icons for a snapcraft app. This post is the closest it seems, to an official bit of documentation (albiet needing the extra steps I have outlined above). There are in the wilds of the internet:

  • posts that refer to icon files needing to be specified in the snapcraft.yaml - this doesn’t seem to be needed in order to define a desktop icon. The official doco says icon means an icon “Path to icon image that represents the snap.” which is quite a vague statement and could be improved.
  • a post by Michael that refer the desktop: share/applications/ rather than desktop: usr/share/applications/ location
  • posts about whether or not the desktop or desktop-legacy plugs are needed (I added them, to be safe)
  • multiple posts from Lin about additional patching being required to make the icon visible, with links to sed and bash scripts and associated entries to snapcraft.yaml - even an official proposal to enhance snapcraft. And even a snapcraft template that looks pretty impressive that adds good info, but also further confused me re how all this works.
  • numerous other posts trying to help with setting up snap desktop icons, with different and contradictory information - some of which preceded 2018. The above items are all 2018 and later, however

In summary:

  • following the instructions in this post do not work unless you add a dump plugin part - otherwise you get Failed to generate snap metadata: The path '/root/prime/usr/share/applications/pynsource.desktop' set for 'desktop' in 'pynsource' does not exist. Make sure that the files are in the prime directory.
  • you must follow the snap/gui directory structure, (not just a gui subdirectory underneath the snapcraft.yaml file location) or else .../meta/gui/ and .../snap/gui/ files are not created.

Thanks for your feedback!

I added an documentation page specifically about .desktop launchers: Desktop files for menu integration

I also updated the reference explanation of the icon key to better explain that this is only used for the snap store, not for the desktop launch menu.:

Let me know if this stuff is still unclear.

@galgalesh Thanks for the clarification. I’m now trying to streamline my snapcraft.yaml so that I’m not explicitly copying .png and .desktop files into usr/share/applications/ anymore - I used to need to have a part like this:

  # copy-desktop-icon-stuff:
  #   plugin: dump
  #   source: snap/gui
  #   organize:
  #     # this worked! without it the two files end up in /prime not /prime/usr/share/applications/
  #     pynsource.png: usr/share/applications/pynsource.png
  #     pynsource.desktop: usr/share/applications/pynsource.desktop     

with the desktop entry referring to desktop: usr/share/applications/pynsource.desktop - and this has been working ok for me.

But after your re-reading your post I thought perhaps I was over complicating things. So I tried to take advantage of your assertion that:

When you run snapcraft , the entire contents of snap/gui will be copied into the meta/gui/ folder of the resulting snap.

However I’m finding this is not the case? I’m looking in the prime/meta directory (after snapcraft --debug) and all it contains is snap.yaml with no ‘prime/meta/gui’ in sight which I need to contain my pynsource.png and pynsource.desktop files. My host source directory is set up correctly:

$ tree snap
├── gui
│   ├── pynsource.desktop
│   └── pynsource.png
└── snapcraft.yaml

so why aren’t they being copied in to prime/meta/gui as you suggest? My snapcraft.yaml is:

name: pynsource
version: git
summary: 'Pynsource - reverse engineer Python source code into UML'
description: |
  Pynsource - reverse engineer Python source code into UML

grade: stable
confinement: strict
base: core18

        command: desktop-launch python3 $SNAP/
        extensions: [gnome-3-28]
        plugs: [x11, unity7, pulseaudio, home, gsettings, network, desktop, desktop-legacy]
        desktop: ${SNAP}/meta/gui/pynsource.desktop
            LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/x86_64-linux-gnu/pulseaudio

    plugin: dump
    source: ./src
    plugin: dump
    source: ./snap/local/andy-diagnostics
    plugin: python
    python-version: python3
    source: ./src
        - libssl-dev
        - libjpeg-dev
        - libtiff-dev
        - libsdl1.2-dev
        - libnotify-dev
        - freeglut3
        - ibus-gtk3
        - libwebkitgtk-3.0-0
        - zlib1g
        - libsm6
        - libpulse0
        - libslang2
        - libsdl1.2debian
        - libgtk2.0-0
        - wxasync
        - /root/project/requirements-linux.txt

and running snapcraft gives me the error:

Failed to generate desktop file: Invalid desktop file '${SNAP}/meta/gui/pynsource.desktop': does not exist (defined in the app 'pynsource').

which makes sense, as the files, as I’ve said, are not there.

$ snapcraft --version                              
snapcraft, version 3.10.2

Thanks for working on this!

Are you running the snapcraft command in the snap folder or in the parent folder? You should run it in the parent folder so that `$PWD/snap/gui contains the desktop file and icon.

You don’t need to add this line when the desktop file is already in snap/gui. The desktop key should only be used if the desktop launcher is generated when your application builds.

Probably, the reason why meta/gui doesn’t contain the files yet is because the snap build fails before those files are copied. First, it copies any desktop launchers specified with the desktop keyword. Then it copies any desktop launchers from meta/gui.

Some more comments:

  • command: desktop-launch python3 $SNAP/ You don’t need to manually add desktop-launch any more when you use the gnome-3-28 extension. The extension adds it to the command chain for you.
  • The variable $SNAP is meant to be used after installation of your snap. It points to the directory of your snap after it is intalled. You should not use it during build. These are some of the variables to use during build: If your build generates the desktop file and you want to use that one, you can do something like desktop: ${SNAPCRAFT_STAGE}/usr/share/applications/pynsource.desktop
  • You can also remove the plugs desktop, desktop-legacy, gsettings and x11 as these are also added by the gnome-3-28 extension.
  • It’s better to use audio-playback instead of pulseaudio. the pulseaudio plug is deprecated. audio-playback gives access to the same functionality and is auto-connected to new snaps.
  • You also don’t need the LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/x86_64-linux-gnu/pulseaudio line because the gnome-3-28 extension takes care of that.

From the parent folder.

Removing the desktop: entry has fixed the problem - and thank you so much for all the other helpful explanations and suggestions - they all work and my snapcraft.yaml is looking pretty tidy now.

I also took the initiative and removed libpulse0 from stage-packages:.

1 Like