Installing and updating Flatpak apps in AppCenter

AppCenter is the graphical app catalogue in elementary OS, and current releases can manage Flatpak applications alongside traditional system packages. That distinction matters: a Flatpak is delivered as a self-contained bundle from a remote repository, rather than being installed directly into the distribution. This guide explains how to add the catalogue, install software, review permissions and keep Flatpak apps current without mixing up their update paths.

Flatpak’s main strengths are consistent application versions and a sandbox that limits access to the rest of the system. A bundled runtime also reduces dependency conflicts, which can be useful on a laptop that mixes school, work and creative software. The sandbox is not invisible armour, though. An app can still request network, file, camera or device access, and publisher code still runs under your user account. Sensible installation habits therefore begin with choosing the right source and reviewing what an application asks for.

Australian users should also expect gaps in the global Flathub catalogue. mygov, Centrelink, ATO, MYOB and Xero services, along with state portals such as Service NSW, myEDH and Queensland transport and education apps, are generally distributed through official websites or mobile stores rather than as Flatpaks. In Sydney, Melbourne and Brisbane, the practical answer for those services is usually the browser or the publisher’s supported native app, not an unofficial Flatpak from an unknown source.

Older elementary OS installations may show only system packages in AppCenter because they predate built-in Flatpak support. Check your release notes before changing anything, update the system if necessary, and keep the distribution’s own updates separate from app updates. The steps below focus on current elementary OS releases while noting safe command-line fallbacks when AppCenter cannot find or refresh a remote.

Understand what AppCenter is managing

Current elementary OS versions give AppCenter a unified view of available software. Flatpak entries come from configured remotes, most importantly Flathub, while traditional entries come from the Ubuntu repositories on which elementary OS is based. AppCenter may show both kinds in the same search results. That is convenient, but it also makes the package source worth checking before an install.

An application’s detail view normally provides the name, developer, screenshots, description and an Install button. Treat the developer and repository as part of the software, not incidental metadata. Flathub’s verified publisher badge can help identify publishers that have completed its verification process, while an unfamiliar name or mismatched branding deserves a pause.

A useful habit is to identify the source before installing. If the same editor, browser or media tool appears as both a system package and a Flatpak, check flatpak list or the application’s About screen after installation. Both versions can coexist, and duplicate launchers are a common source of confusion.

Prepare the Flathub catalogue

Current elementary OS includes Flatpak support, and many installations also have the Flathub remote configured. The quickest check is to open AppCenter, search for a familiar application and look for a Flatpak source. If results appear only for system packages, update elementary OS and reopen AppCenter before changing repository settings.

For a terminal check, run flatpak remotes. A listed Flathub entry should be enabled. If the flatpak command is missing, install the package with sudo apt install flatpak. If Flathub is listed but disabled, enable it with flatpak remote-modify --enable flathub, using administrator authorisation if it is a system remote; if it is absent, the next step adds it.

Add the official Flathub repository with flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo. The --if-not-exists option prevents duplicate entries. Close and reopen AppCenter, then refresh its search. Avoid adding an unfamiliar remote merely because it carries an application missing from Flathub; a third-party remote expands both the catalogue and your trust boundary.

Install a Flatpak app

Search for the application by name, open its listing and read the description, source and requested permissions. Select Install and confirm the operation with your system password. AppCenter uses a privileged policy service for this step, so the prompt is expected even when the software comes from a Flatpak remote.

The first download may be larger than the application itself because Flatpak also fetches the runtime it depends on. Those shared runtimes are stored once and reused by compatible apps. For an Australian household using a capped mobile plan, completing this step on home broadband rather than mobile data can prevent an unexpectedly large download.

On first launch, a file chooser may appear when the app asks for a document, and other dialogs can request camera, microphone, screen sharing or location access. Grant only what the task requires. If access seems excessive for a simple utility, declining it is safer than granting everything in a rush.

Compare Flatpak and system packages

Packaging affects compatibility, updates and how closely an app integrates with the desktop. A Flatpak generally offers stronger isolation and predictable dependencies, whereas an Ubuntu system package may fit the system more deeply. Neither is universally better; the right choice depends on the application’s task and the quality of its maintainer’s package.

The source is the key detail to compare. A Flatpak from the official Flathub remote receives app and runtime updates through that remote. An Ubuntu package follows the normal elementary OS update path. Local integration can favour a system package, while isolation and a broad version choice often favour a Flatpak.

For software that needs an unusual kernel feature, proprietary codec, specialised hardware or a tightly integrated system service, test the Flatpak before removing a working system version. For routine desktop tools, a maintained Flathub package is often the tidier choice, especially when two versions would otherwise compete for file associations.

Review permissions and stored data

Flatpak’s sandbox controls are enforced by the system, but apps can request extra access through permissions and portals. Reviewing those requests before installation is sensible. After installation, flatpak info --show-permissions APP_ID prints the manifest permissions, while flatpak permissions APP_ID shows overrides you have granted.

If an app accumulates permissions it no longer needs, reset its overrides with flatpak override --reset APP_ID and launch it again to re-answer only the prompts that matter. Resetting is safer than uninstalling and reinstalling because it leaves the application intact. Some access still comes from the app’s own permissions rather than an override, so removing an override may not remove the underlying request.

User data usually lives under ~/.var/app/APP_ID, separate from the installed bundle. Uninstalling a Flatpak generally leaves that data behind, which is useful for recovery but can also retain sensitive files. Back up important material, and remove the matching directory only when you are certain the app and its data are no longer needed.

Update apps and shared runtimes

Open AppCenter’s updates area to see pending Flatpak releases. Update an app individually when you want to control the timing, or use its bulk update control for everything the catalogue reports. Flatpak does not silently update an open application; a notification is a prompt for action, not evidence that a new version has already been applied.

When AppCenter cannot see a release, use the terminal fallback: flatpak update updates installed applications and their runtimes, while flatpak update APP_ID targets one app. Run flatpak remotes if an update reports that the source is unavailable. A sideloaded bundle may never receive updates if its remote has been removed or its publisher has not signed a replacement.

Shared runtimes can remain after an app is removed. flatpak uninstall --unused identifies and removes unused runtimes and extensions, but review the list first because a Flatpak may still be preparing to run. Australian users on metered mobile plans should schedule large updates on reliable broadband. Sydney and Melbourne change their clocks for daylight saving, while Brisbane remains on AEST, so an “overnight” update window arrives at different local times.

Build a dependable update routine

A dependable routine is straightforward: update elementary OS itself, open AppCenter, review pending app changes and install them at a convenient time, then launch the apps you rely on. If an app behaves differently after an update, use its bundled rollback option where available; otherwise check the app’s release notes before removing it.

Keep local and regulated services on trusted channels. Australian banking, superannuation, tax and government apps often depend on mobile push notifications, device biometrics or browser security features outside a Flatpak’s control. The official website, browser or native store version may therefore be the safer choice, even if a lookalike exists in a Flatpak repository.

Backups matter because Flathub is a community catalogue rather than a guarantee of maintenance. Record any custom permissions or local configuration you depend on, and check that an app’s developer and source remain credible before updating. The practical takeaway is to install from a known remote through AppCenter, grant only the permissions the app needs, and run a brief update check each month while keeping essential Australian services on their official channels.