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.
Confinement
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.
Interfaces
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.
Aliases
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.
Presentation
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.
Screenshots
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.
Banner
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.
Description
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.