Installing applications on Linux usually means choosing between your distribution’s native packages, Flatpak and Snap. All three can put an application in your desktop menu, but they differ in where the software comes from, what it can access and how it receives updates.
A practical starting point is to use your distribution’s repositories for system components and utilities, then consider Flatpak or Snap for desktop applications. Choose the package that has a trustworthy maintainer, supports the features you need and has a clear update path. The format alone does not settle those questions.
You do not need to standardise your entire computer on one format. A Linux desktop can use native packages for its operating system, Flatpak for an image editor and Snap for another application. Keep track of which installation you use, though. Two identical icons are not twice as useful.
Native Packages, Flatpak and Snap Compared
A native package is built for a distribution’s package system and compatible releases. Flatpak and Snap provide separate application packaging systems that can work across supported distributions. Neither replaces the operating system’s own maintenance tools.
| Consideration | Native packages | Flatpak | Snap |
|---|---|---|---|
| Usual source | Distribution repositories or a publisher’s repository | Flatpak repositories, including Flathub | Snap Store |
| Typical role | System software, utilities and desktop applications | Desktop applications | Desktop applications, tools and services |
| Dependencies | Usually shared through the distribution’s packages | Shared runtimes plus application dependencies | Application packages with bases and other shared components |
| Application isolation | No universal application sandbox supplied by the format | Sandbox with permissions and portal access | Depends on strict or classic confinement |
| Update responsibility | Distribution or third party repository maintainer | Application and runtime repository maintainers | Publisher, with automatic refresh managed by snapd |
These are packaging differences, not a ranking of software quality. A carefully maintained native package can be a better choice than an abandoned Flatpak. An actively supported Snap can be preferable to a downloaded package that never receives another update.
For the distribution tools behind native packages, see our guide to APT, DNF and Pacman. Here, the focus is choosing and managing application installations rather than learning each package manager’s command syntax.
Installing Applications from Native Packages
Start with the repositories supplied by your distribution. They provide packages selected for that operating system, with dependencies handled through its package manager. Debian and Ubuntu systems use Debian packages and APT; conventional Fedora installations use RPM packages and DNF; Arch Linux uses Pacman.
Do not assume instructions for one distribution apply to another because both run Linux. Package names, repository arrangements and supported versions can differ. Image based distributions may also require a different approach to modifying the operating system itself.
Install Through the Software Application
Open your desktop’s software application, which might be called Software, Discover, Software Manager or App Center. Search for the application, open its details and check the package source before selecting Install. The exact labels depend on your desktop and distribution.
A useful installation routine is:
- Check that the application name and project details match what you intended to install.
- Inspect the source selector, if present, rather than accepting the first result.
- Read the proposed download, dependency and removal changes.
- Approve the installation and authenticate if requested.
- Launch the application and test the feature you actually need.
The source selector matters because a graphical store is an interface, not a package format. One application page may offer multiple builds. Installing from a desktop store does not, by itself, tell you whether the result is a native package, Flatpak or Snap.
If you prefer the terminal, use instructions written for your distribution and release. Our Linux terminal commands guide covers the working habits that make those instructions easier to follow, including reading output before approving changes.
Refresh Package Information Before Troubleshooting Missing Software
A package manager’s local catalogue can become outdated. Refreshing that catalogue is different from upgrading installed applications: one retrieves package information, while the other changes installed software. The distinction is documented in the Ubuntu instructions for installing and managing APT packages.
If an application cannot be found, check the catalogue, spelling and enabled repositories before downloading an installer elsewhere. Also check whether the package has a different name from the application shown in its window title.
Treat Downloaded Packages as a Separate Trust Decision
A publisher may distribute a .deb or .rpm file directly. Choose a build intended for your distribution, supported release and processor architecture. A matching file extension is not enough to establish compatibility.
Use a package installation tool that can resolve dependencies rather than trying to unpack the file manually. DNF5, for example, supports both repository packages and local RPM files through its package installation mechanism.
Before proceeding, establish how future updates will arrive. A downloaded installer might configure a publisher’s repository, but it might not. Do not assume that successful installation means the application has joined an automatic update service. Look for a documented update method and confirm it afterwards.
Adding a repository deserves more scrutiny than downloading a document. Native package installation can run privileged packaging scripts, and an external repository can introduce conflicts with distribution packages. The Ubuntu guidance on third party repositories covers these security and compatibility risks, including those associated with PPAs.
Prefer a publisher’s maintained instructions over an old forum command. Avoid repositories intended for another distribution or release, and do not disable signature checks to make an installation finish.
Installing Linux Applications with Flatpak
Flatpak is a useful option when you want a desktop application packaged separately from your distribution’s library versions. It can also avoid adding a native repository just to obtain one application.
Set Up Flatpak and Choose a Repository
Check whether Flatpak support is already installed. If not, follow your distribution’s setup instructions, including any integration needed for its graphical software application. Installing Flatpak and enabling a repository are separate tasks: the packaging tool needs somewhere to obtain applications.
Flatpak calls a repository a remote. Flathub is one option, but distributions and software projects can provide others. Check which remote supplies an application before installing it, particularly when search results show more than one build.
Flatpak also distinguishes between installations for one user and installations available across the system. Repositories have the same distinction. Keep the scope consistent when searching, installing and removing software; the Flatpak installation and management documentation covers application IDs, remotes and installation scope.
In a graphical store with Flatpak integration, select the Flatpak source, review the application details and approve the installation. If you obtain a Flatpak reference file from a project, check the repository it proposes adding. A convenient install button should not make the origin of the software an afterthought.
Expect Runtime Downloads
The first Flatpak installation can include more than the application itself. Flatpak applications use runtimes containing common dependencies, and several applications can use the same runtime. Different runtime versions can coexist; applications can also bundle libraries absent from their runtime. These relationships are covered in Flatpak’s runtime and sandbox concepts.
This makes the first download a poor basis for judging every later installation. Equally, do not assume that all applications share one runtime. When storage is tight, compare the proposed installation size on your own machine rather than relying on a general claim that one format is smaller.
On an older computer, available storage and the application’s own demands deserve attention alongside packaging. Our guide to running Linux on older laptops covers that broader decision.
Review Permissions Rather Than Trusting the Sandbox Label
Flatpak applications run in sandboxes, but their permitted access varies. An application can receive access to files, devices or services through its packaging permissions. Portals provide another route, allowing actions such as selecting a file through a system dialog without granting blanket access to every document.
Review access in your desktop’s application settings or a Flatpak permission tool such as Flatseal. Available controls depend on the desktop and tool. The Flathub instructions for modifying permissions cover graphical controls and permission overrides.
Match access to the job. A photo editor may need your Pictures folder; it does not follow that every application needs your entire home directory. If a file will not open, try the application’s file chooser and check the relevant permission before broadening access.
Permissions are a tradeoff, not a contest to switch everything off. Removing access an application needs can break a feature. Change one setting at a time and keep enough information to reverse the change.
Installing Applications with Snap
Snap uses the snapd service to manage package installation and updates. Before choosing it, check your distribution’s support and setup instructions. Do not assume that another distribution follows Ubuntu’s installation defaults.
When Snap is available through your software application, inspect the publisher, selected release channel and access requirements before installing. If you use publisher instructions instead, check that they refer to the intended Snap package rather than a similarly named application.
Check Strict and Classic Confinement
Strictly confined snaps obtain access to resources through interfaces. Classic snaps have access much closer to traditionally installed applications, subject to ordinary operating system permissions. Devmode is intended for development and debugging rather than routine installation. These distinctions are set out in the Snap confinement documentation.
A classic access warning is therefore worth reading. It does not automatically mean the application is unsuitable, but it changes the security assumptions you should make. Do not treat every Snap as having the same restrictions.
If a strictly confined application cannot access a peripheral or storage location, investigate its available interface connections. Avoid switching to a less restrictive mode simply because an online comment presents that as the quickest fix.
Plan for Automatic Updates
Store installed snaps normally update automatically through a process called refreshing. Refresh schedules and update holds provide control over timing, including postponing updates for an individual application. Locally installed snaps and devmode installations have different update behaviour; the Snap update management documentation covers those exceptions and controls.
For a work machine, decide when changes are acceptable before an update interrupts an inconvenient moment. A temporary hold can support testing, but record why it exists and when you intend to review it. An application left on hold indefinitely still needs a maintenance decision.
Prefer a normal production release channel unless you have a reason to test another build. Changing channels is not a substitute for diagnosing a permissions problem or a missing feature.
Which Installation Method Should You Choose?
Begin with the application’s requirements rather than a blanket preference for one format. Check whether the publisher supports the package, whether updates arrive reliably and whether the build works with your workflow.
For drivers and components that modify the operating system, follow the distribution’s supported route. A desktop application package is not a replacement for that process. Graphics related installations deserve particular care; see our guide to installing NVIDIA and AMD graphics drivers.
For a document editor or media application, consider a maintained native package first, then compare Flatpak or Snap if you need another release or packaging arrangement. Test ordinary tasks: opening files, saving to your chosen location, printing and working with peripherals.
Development tools need another check. An editor is not the same thing as its language environment. Before installing an editor in a sandbox, check how it will access compilers, terminals, debuggers and project directories. Keep Python project dependencies separate through Python virtual environments rather than treating application packaging as a replacement for project dependency management.
There is no useful universal promise that native packages are always faster, or that Flatpak and Snap are always slower. Compare the same application version where possible, and distinguish first launch from later launches. Choose based on a repeatable task, not the loudest packaging argument.
Updating and Removing Applications Cleanly
Maintain every packaging system you actually use. A native package update does not replace Flatpak or Snap maintenance, even if a graphical interface presents several update sources together. Check what your updater covers and whether automatic updates are enabled for each source.
For Flatpak, include runtimes in the update process rather than thinking only about the visible applications. For Snap, review refresh holds and failed changes. For native packages, check repository errors instead of assuming an apparently short update list means nothing needs attention.
Application updates are only part of maintaining a Linux installation. Our guide to Linux security updates and automatic patching covers the operating system side.
Remove Software Through the System That Installed It
Use the matching software manager or packaging tool to remove an application. Do not delete its installed files manually. On removal, inspect any proposed dependency changes before approving them, especially if the list includes software you still use.
Separate three decisions: removing the application, removing its settings and deleting your own work. Those are not interchangeable operations. Native package removal can leave configuration behind, while other packaging systems have their own data retention and cleanup options.
Before switching formats or testing an older release, export important settings and protect documents, local databases and other application data. A package rollback does not necessarily reverse changes to that data. Use a desktop backup and recovery plan rather than relying on reinstallation.
When moving between native, Flatpak and Snap builds, test the replacement before removing the original. Confirm that you can open existing work, save changes and use required extensions. Then remove the unused installation and check file associations so documents open in the intended copy.
Troubleshooting Installation and Access Problems
The Application Is Missing from Search
Check the spelling, package source and catalogue refresh status. For Flatpak, also check the remote and whether it belongs to the user or system installation. A missing search result is not a reason to add several unrelated repositories.
If you downloaded a package, confirm that it matches the distribution and architecture. Do not force installation past dependency or compatibility errors without establishing what caused them.
The Application Opens but Cannot Access a File
Identify which package you launched before changing permissions. An operating system ownership problem and a sandbox restriction require different fixes. Our guide to Linux file permissions and ownership covers the former.
For Flatpak, check permission overrides and whether the problem began after a change. Avoid granting access to the entire filesystem as a general repair. The Flathub troubleshooting procedure covers collecting application details, inspecting overrides and reporting packaging problems.
Installation Proposes Unexpected Removals
Cancel and read the transaction carefully. Check whether an external repository, incompatible package or replacement package caused the proposal. Removing a large group of desktop components to install one small application is a reason to investigate, not an invitation to press Confirm faster.
The Download Is a Windows Installer
A Windows executable is not a native Linux package, Flatpak or Snap. Look for a supported Linux build first. If the application has none, assess compatibility separately using our guide to running Windows applications with Wine and Bottles.
A Practical Default for Everyday Use
Use your distribution’s supported tools for the operating system. For desktop applications, choose a maintained package whose origin, permissions and update method you can identify. Keep one installation per application unless you deliberately need separate builds for testing.
Before considering an installation finished, answer four questions: who supplied it, how will it update, what can it access and where is its data? Those answers matter more than whether the install button said native, Flatpak or Snap.