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
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
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 -
apm will by default expose
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
See Commands and aliases for more information.
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.
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.
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.