The newest systemd component being worked on and drafted for an initial pull request is systemd-appd as a new mechanism to centralizing the tracking of user's apps.

The proposed systemd-appd is an app management service that will allow all session services to reliably identify apps and learn about their current permissions. This includes the likes of Dbus, PipeWire, Portals, and Wayland compositors. Systemd-appd will rely on a Varlink interface for the management of running app instances.

The systemd-appd is being worked on for use-cases like Flatpak with their Flatpak-Next / Flatpak 2.0 efforts. This component was originally talked about nearly one year ago on Phoronix: systemd-appd Is A New Component Being Planned By Flatpak Developers.

This patch further explains of systemd-appd:

"It allows all session services (dbus, pipewire, portals, Wayland compositors) to reliably identify apps and learn about their current permissions.

This commit introduces the core Varlink interface for basic management of running app instances.

Apps (or the processes that eventually exec() their way into becoming apps) are expected to register themselves upon startup, so that appd starts tracking their identity. Appd ensures that the app is running in a systemd unit that follows the XDG app naming convention (as defined in DESKTOP_ENVIRONMENTS.md). Due to previous changes in this patch series, that ensures the app's identity gets tagged onto the cgroup that contains it.

On top of this registration primitive, appd provides a mechanism for storing and retrieving additional metadata about the app. In this commit, that's just the app's current runtime permissions and entitlements. Session services can use this information to decide if an app shall be permitted to take some privileged action."

Those interested can see the draft pull request for more discussion on this in-development systemd feature.