Ubuntu Platform

Ubuntu 26.04 LTS is the guide’s GNOME reference target, but it is not a single SDK. It is an LTS release with a supported toolchain set, two first-class package formats, a set of privileged system services, and a security-maintenance model that extends beyond the standard support window.

This page is the map. It tells you which Ubuntu sources to trust, which packaging path fits which audience, and which system APIs an app should use instead of shelling out to a command-line tool. The exact validated component versions are recorded in Baseline. The other Platform pages go deeper on Wayland, XDG, integration, Flatpak, packaging, and security.

What changed in Ubuntu 26.04

The Ubuntu Desktop session is Wayland-only. XWayland still runs X11 applications, but there is no Xorg GNOME session.
GNOME 50 ships Reduced Motion, improved Orca, fractional scaling on by default, better VRR/HDR, and a more accessible remote desktop.
The App Center manages snaps and debs from the Ubuntu archive, and can install third-party debs (with a warning). Snaps remain the recommended third-party path.
Permission prompting is experimental and snap-focused; users enable it in Security Center and manage portal permissions in Settings.
Snap base core26 is the recommended base. It no longer bundles Python, so Python snaps must add a runtime explicitly.
.NET 10 and OpenJDK 25 are the current archive defaults; Zig 0.15.2 is available in the archive.
Glycin now handles sandboxed image decoding for many apps, GStreamer 1.28 is the media stack with VA-API, and Sysprof is installed by default.
NVIDIA + Wayland is supported; use the drivers installed by ubuntu-drivers and test the Wayland session. Official ARM64 desktop images are available for VMs, ACPI/EFI hardware, and Snapdragon devices.
Ubuntu Insights is opt-in system telemetry; keep app telemetry separate and opt-in.

Release and support

Target an LTS release unless you have a reason not to. LTS releases are what users and organizations run, and they are what the Ubuntu archive and Snap bases are built around. Flatpak runtimes follow their own Freedesktop, GNOME, and KDE release schedules; they do not track Ubuntu LTS.

Release	Type	Standard support	Ubuntu Pro	Legacy add-on
26.04 LTS (Resolute Raccoon)	LTS	May 2031	May 2036	May 2041
24.04 LTS (Noble Numbat)	LTS	May 2029	May 2034	May 2039
22.04 LTS (Jammy Jellyfish)	LTS	May 2027	May 2032	May 2037
26.10 (Stonking Stingray)	Interim	Jul 2027	—	—

The 26.04 release notes say the standard support window ends in April 2031, while the release-cycle table says May 2031. This guide uses the release-cycle table and records the discrepancy rather than hiding it.

LTS is the baseline for app development, CI, and support statements.
Interim releases are for testing new kernels, toolchains, and desktop features. Do not make them your only supported target.
Ubuntu Pro is optional. Apps must work on a stock Ubuntu installation without it.
Legacy add-on is an extended-support option for organizations; it is not an app requirement.

Sources: Ubuntu Desktop for developers, Ubuntu release cycle, Ubuntu 26.04 release notes.

Toolchains

Ubuntu documents a supported toolchain set with installation guides, version availability, and first-program tutorials. Prefer the archive package when you need system integration and ABI stability. Prefer a snap when you need an isolated, cross-distribution tool. Use an upstream installer only when you need a version or feature that Ubuntu does not ship.

Toolchain	Install path	Ubuntu documentation
Python	`apt install python3` / `uv` for project environments	Python on Ubuntu
Go	`apt install golang-go` or the official tarball	Go on Ubuntu
Rust	`apt install rustc cargo` or `rustup` for current stable	Rust on Ubuntu
GCC	`apt install build-essential`	GCC on Ubuntu
Clang/LLVM	`apt install clang lld`	Clang on Ubuntu
.NET	`apt install dotnet10` (26.04 default); .NET 8/9 via the backports PPA or the .NET snap	.NET on Ubuntu
Java	`apt install openjdk-25-jdk` (26.04 default); `openjdk-21-jdk` for older compatibility	Java on Ubuntu
Zig	`apt install zig` (0.15.2); snap or upstream tarball only for a newer version	Zig on Ubuntu

Guidance:

Use the archive toolchain for code that links against system libraries and ships as a deb.
Use a snap or a project-local toolchain for compilers and language runtimes that must be newer than the archive.
Pin the toolchain version in CI. “Whatever is installed on the runner” is not a version policy.
Check the toolchain availability reference before promising support for an older release.
IDE setup and installation commands are collected in the IDE reference.

Packaging paths

Ubuntu supports two first-class package formats: deb and snap. Flatpak remains the cross-distribution path covered by this guide. They solve different problems.

Path	Best for	Updates	Sandbox	Trade-off
deb + PPA	Ubuntu archive integration, system tools, libraries	apt, unattended-upgrades	No	Full system access; tied to release
Snap	Third-party desktop apps in the Ubuntu App Center	snapd, automatic refresh	Yes, AppArmor	Larger install; confinement interfaces
Flatpak / Flathub	Cross-distro upstream desktop apps; not installed by Ubuntu by default	OSTree deltas	Yes, portals	Separate runtime model; the user or upstream must install Flatpak and add Flathub
OCI / Rockcraft	Services and cloud workloads	Container registry	Container	Not a desktop app format

Ubuntu’s own guidance recommends snaps for third-party apps in the App Center because they are sandboxed and updated independently of the release. The App Center also manages debs from the Ubuntu archive and can install third-party debs, but third-party debs are discouraged: they have full access to the user’s resources and may add their own repositories. Use a deb when you need archive/system integration or are maintaining an Ubuntu package; use a Snap when you want the App Center’s confined, auto-updating path.

Flatpak is a different case. Ubuntu does not ship Flatpak or the Flathub remote by default, and Canonical does not list it as a supported Ubuntu package format. It is still a mature, open-source, cross-distribution channel that many users install deliberately. If you target those users, treat Flatpak as a first-class build target and document the flatpak/flatpak-builder install and Flathub setup; do not imply that it is part of a stock Ubuntu installation.

deb and PPA

sudo add-apt-repository ppa:yourname/notes
sudo apt update
sudo apt install notes

Follow the Ubuntu packaging guide and the new-package guide.
Build packages in a clean chroot; validate with lintian.
Use a PPA for upstream deb distribution; use the Ubuntu archive only when you can maintain the package for the release lifecycle.
See Build packages in a PPA.

Snap and Snapcraft

snapcraft init
snapcraft pack
sudo snap install --dangerous ./notes_0.1.0_amd64.snap
snap connections notes

confinement: strict is the default for a new app. classic is for tools that genuinely need full system access and is reviewed manually.
Declare the smallest set of interfaces you need.
Use XDG Desktop Portals inside the snap where possible; the Snap documentation has a dedicated XDG desktop portals page.
Build with Snapcraft and follow the Craft a snap tutorial.
For snapd automation, use the REST API, not the snap CLI from inside a confined app.

Flatpak

Flatpak is covered in Flatpak & Portals and Flathub. Keep the distinction clear:

Ubuntu App Center recommends snaps for third-party desktop apps and also manages debs from the Ubuntu archive; third-party debs are supported but discouraged.
Flathub is the vendor-neutral upstream store for Flatpak apps across distributions. It is not part of a stock Ubuntu installation, so document the Flatpak setup separately.
Shipping both is legitimate if you can maintain both. Do not treat one as a drop-in replacement for the other.

OCI images and Rockcraft

Use Rockcraft when the deliverable is a container image, not a desktop app. Rocks are Ubuntu-based, minimal OCI images with a supported build path. They are not a way to package a GUI application for the desktop.

System services

Ubuntu’s desktop services expose stable D-Bus APIs. Use the API, not the command-line tool, and use a portal when one exists. The table is intentionally opinionated: it tells you what an app should normally do, not everything the service can do.

Service	API	App guidance	Primary documentation
systemd / journald	`org.freedesktop.systemd1`, journal fields	Use user units for background work; log to stderr/journald; never manage system units from an app	systemd, journald
NetworkManager	`org.freedesktop.NetworkManager`, libnm	Observe connectivity; do not reconfigure the network unless the app is a network manager	NetworkManager developers
PipeWire	PipeWire API, GStreamer	Play and record through PipeWire; do not open raw ALSA devices	PipeWire docs
WirePlumber	WirePlumber library, `wpctl`	Let the session manager route devices; do not override policies	WirePlumber docs
UPower	`org.freedesktop.UPower`	Read battery and power state; react to suspend/resume; do not poll	UPower docs
BlueZ	`org.bluez`	Use BlueZ profiles and D-Bus; do not talk to raw HCI	BlueZ D-Bus API
CUPS	IPP, libcups	Use `Gtk.PrintDialog` or the Print portal; do not manage printers	OpenPrinting CUPS
UDisks2	`org.freedesktop.UDisks2`	Use GIO/GVfs for files; only disk utilities should use UDisks directly	UDisks2 API
AppArmor	Kernel LSM, `aa-*` tools	Ship a profile for system services; desktop apps rely on the Flatpak/Snap sandbox	AppArmor docs
Polkit	`org.freedesktop.PolicyKit1`	Never run `sudo` from an app; define a Polkit action for privileged operations	Polkit docs
fwupd	`org.freedesktop.fwupd`	Do not flash firmware yourself; integrate with fwupd/LVFS or link to the firmware updater	fwupd / LVFS
PackageKit	`org.freedesktop.PackageKit`	Do not install packages from an app; use the software center/PackageKit	PackageKit
snapd	REST API on `/run/snapd.socket`	Do not manage snaps from inside a snap; let snapd/the store update them	snapd REST API
AT-SPI	D-Bus accessibility interfaces	Use native widgets and `Gtk.Accessible`; do not draw inaccessible controls	Ubuntu accessibility stack
Security Center / permission prompting	snapd prompting API, AppArmor	Use portals and minimal Snap interfaces; users manage experimental prompts in Security Center	Permissions prompting deep dive

Two rules cover most of the table:

Use the highest-level API that fits. A file dialog, print dialog, notification, or secret belongs in a portal or toolkit API, not in a direct service call.
Do not shell out to system tools from a sandbox. nmcli, udisksctl, snap, and fwupdmgr may be absent or restricted. Use the D-Bus API or a portal.

Security and Ubuntu Pro

Ubuntu’s security model combines AppArmor, Polkit, signed packages, and optional Ubuntu Pro services.

AppArmor confines services and sandboxed apps with per-application profiles. If you ship a system service, provide a profile and test it with aa-status and journalctl -k --grep=apparmor.
Polkit mediates privileged operations. Define a named action instead of asking users to run sudo; the desktop can then present a proper authentication dialog.
fwupd handles firmware updates through the LVFS. Apps should link to the firmware updater or expose status, not write firmware directly.
Ubuntu Pro adds ESM, Livepatch, FIPS, CIS hardening, and extended support. It is preinstalled as the pro client:

pro status
sudo pro attach <token>
sudo pro enable esm-apps
sudo pro enable livepatch
pro fix CVE-2025-12345

Apps must not require Pro. If your app exposes security status, detect whether a service is enabled and explain the benefit without blocking core functionality.

See Ubuntu Pro Client and Ubuntu Pro.

Accessibility on Ubuntu

Ubuntu Desktop’s accessibility stack is built on AT-SPI over D-Bus. GTK 4 exposes semantics through Gtk.Accessible; GTK 3 uses ATK. Orca is the default screen reader, with BRLTTY for Braille and Speech Dispatcher/eSpeak for speech.

Use GTK or Qt widgets that expose AT-SPI semantics.
Test with Orca and the accessibility inspector, not only with an automated checker.
Custom-rendered or web-rendered UI does not inherit AT-SPI semantics automatically; test it with Orca and budget for explicit accessibility work.
Follow Accessibility for the product-level checklist.

Sources: Ubuntu Desktop accessibility stack, AT-SPI D-Bus interfaces.

Where to get help

Ubuntu for Developers — toolchains, IDEs, packaging.
Ubuntu Desktop documentation — desktop behavior, accessibility, snap/deb policy.
Ubuntu Discourse — platform and desktop discussion.
Ubuntu Desktop Matrix — desktop development chat.
Ask Ubuntu — user-facing questions.
Launchpad — bugs, PPAs, and Ubuntu packages.

Ubuntu platform checklist

☐ Target an LTS release and state the support window.
☐ Pin the toolchain version used in CI and packaging.
☐ Choose deb, snap, Flatpak, or OCI deliberately; do not ship all four by default.
☐ Use portals or toolkit APIs for files, printing, notifications, secrets, and screen capture.
☐ Use D-Bus APIs or the snapd REST API instead of shelling out to nmcli, udisksctl, snap, or fwupdmgr.
☐ State whether the app ships through Ubuntu-supported deb/Snap or an alternative channel; document the Flatpak setup separately if you use it.
☐ Test the Wayland-only Ubuntu Desktop session and XWayland only for legacy X11 apps.
☐ Never require sudo at runtime; define a Polkit action if privileged work is unavoidable.
☐ Do not require Ubuntu Pro; detect optional services and degrade gracefully.
☐ Test with Orca and the Ubuntu accessibility stack.
☐ Validate the desktop file, AppStream metadata, and package with the Ubuntu tooling.
☐ Test on a stock Ubuntu installation, not only on your development machine.