You installed Fedora and the Software center shows outdated apps
You opened the Software center on a fresh Fedora Workstation install. You search for a modern desktop application and find a version from two years ago. You run sudo dnf install and get a dependency chain that pulls in half the system. Someone tells you to use Flatpak. You run the command, watch it download three hundred megabytes for a simple editor, and wonder why it asks for permission to access your home directory. The sandbox is working exactly as designed. You just need to understand the boundaries it draws.
What is actually happening under the hood
Flatpak packages applications with their dependencies into isolated bundles. Instead of relying on host system libraries, the app carries its own runtime environment. Think of it like shipping a fully furnished room instead of asking the host to provide furniture. The host system only needs the Flatpak framework and a shared runtime. The app runs inside a sandbox that blocks access to the filesystem, network, and hardware by default. When the app needs to open a file or play audio, it requests permission through a portal. The portal asks the user, and the system grants temporary access. This design prevents library conflicts and keeps the host system stable.
Fedora ships with the Flatpak framework enabled by default. The flatpak command-line tool and GNOME Software both use the same backend. They read AppStream metadata to display app icons, descriptions, and installation paths. The <bundle type="flatpak"> tag in that metadata tells the software center to route the installation through the Flatpak daemon instead of dnf. The daemon handles download verification, sandbox creation, and portal routing. You interact with the CLI or the GUI, but the daemon does the heavy lifting.
Runtimes are the foundation of this architecture. A runtime contains the core libraries and frameworks an app needs to function. GNOME apps share the org.gnome.Platform runtime. KDE apps share the org.kde.Platform runtime. When you install your first GNOME Flatpak, the framework downloads the entire runtime. Subsequent GNOME apps reuse that same runtime. This saves disk space and ensures consistent behavior across applications. The runtime updates independently of the apps. You can update runtimes without touching your installed software.
Convention aside: Fedora separates system packages from user applications by design. dnf manages the OS, kernel modules, and core utilities. Flatpak manages desktop applications and third-party software. Keep them in their respective lanes. Mixing them creates permission drift and makes troubleshooting harder.
How to set up and install Flatpak apps
Fedora Workstation includes the flatpak package and the Flathub remote out of the box. Verify the installation and check the configured remotes before proceeding.
flatpak --version
# Confirms the CLI tool is present and reports the framework version
flatpak remotes
# Lists configured repositories. Flathub should appear here by default
If Flathub is missing, add it manually. The remote provides the application catalog and shared runtimes.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# --if-not-exists prevents duplicate entries if the remote was already configured
# The URL points to the official Flathub repository manifest
Install an application. The command pulls the app bundle and any missing runtimes. The framework resolves dependencies automatically.
flatpak install flathub org.gnome.Calculator
# Installs the GNOME Calculator from Flathub
# The framework automatically downloads the required GNOME runtime if missing
# Press y to confirm the installation and disk usage prompt
Applications install to ~/.local/share/flatpak by default. This keeps user apps separate from system packages. System-wide installations go to /var/lib/flatpak and require sudo. User-level installations are preferred for desktop workflows. They avoid permission conflicts and let you update apps without root access. The directory structure mirrors standard Linux conventions. User configuration lives in the home directory. System configuration lives under /var or /etc. Never mix them.
Verify the installation and sandbox behavior
Check the installed list and launch the app directly from the terminal. Running it from the command line shows sandbox warnings and permission requests immediately.
flatpak list
# Displays all installed Flatpak apps with their IDs and versions
flatpak run org.gnome.Calculator
# Launches the app through the sandbox
# Watch for portal dialogs asking for file or network access
The app opens. The terminal returns to the prompt. If the app fails to launch, the sandbox blocked a required resource. Check the journal for denial messages.
journalctl -xeu flatpak
# Shows recent Flatpak daemon logs with explanatory context
# Look for permission denials or missing runtime errors
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and what the error looks like
Flatpak apps sometimes refuse to access files outside their sandbox. You will see a portal dialog asking for permission. If the dialog never appears, the app likely lacks the correct portal integration. The terminal will print a permission error when you try to open a file.
Error: Failed to open file: Permission denied
This message means the sandbox blocked the path. Grant access by adding the directory to the app's sandbox permissions. You can do this through GNOME Software or by modifying the installation flags.
flatpak override --user --filesystem=~/Documents org.gnome.Calculator
# Grants persistent read-write access to the Documents folder
# --user scopes the override to your account instead of all users
# The path must use tilde expansion or absolute paths
Another common issue is the clipboard not working between sandboxed and native apps. Flatpak isolates the clipboard by default. Enable clipboard sharing with an override.
flatpak override --user --talk-name=org.freedesktop.portal.Clipboard org.gnome.Calculator
# Allows the app to communicate with the system clipboard portal
# This fixes copy-paste failures between Flatpak and native windows
Updates also behave differently than dnf. The flatpak update command checks all configured remotes and downloads new app bundles. It does not touch system packages. Run it regularly to keep third-party apps current.
flatpak update
# Checks Flathub and other remotes for newer app versions
# Downloads and applies updates in the background
# Press y to confirm the transaction when prompted
Keep dnf upgrade --refresh for system packages. Keep flatpak update for desktop apps. They manage different layers of the system. Fedora's release cadence is six months. Flatpak apps update continuously. Plan your maintenance accordingly.
When to use this versus alternatives
Choose the right packaging method based on your workflow.
Use Flatpak when you want modern desktop applications that update independently of the host system. Use DNF when you need system utilities, kernel modules, or low-level libraries that integrate with the OS. Use native source compilation when you require custom patches or bleeding-edge features not available in any repository. Stay on the default Fedora package set when you prioritize system stability and minimal disk usage.
Trust the package manager. Manual file edits drift, snapshots stay.