A Flatpak jövőbeli architektúrája a jelenlegi tervek szerint nagyobb mértékben épülhet a systemd szolgáltatásaira. A tervezett irányvonal azonban a nem systemd-alapú disztribúciók esetén kompatibilitási kérdéseket vet fel. A Flatpak jelenleg a Linux disztribuciók nagy részében elérhető alkalmazásterjesztési megoldás, egy systemd-appd-re épülő modell viszont további fejlesztéseket igényelne az Alpine, a Void, a Devuan és más hasonló, a systemd-t elutasító rendszerek esetén, már ha azt hajlandók meglépni az érintett disztribuciók.
A vita a Flatpak Next néven futó projekthez kapcsolódik, amely egy későbbi átalakítás alapja lehet. Sebastian Wick Flatpak-karbantartó és Adrian Vovk a Linux App Summit 2026 rendezvényen arról számolt be, hogy a jelenlegi modell több területen elérte a határait. A fejlesztők megbízhatóbb módszert keresnek a futó alkalmazáspéldányok azonosítására, a jogosultságok kezelésére, a beágyazott sandboxok támogatására, valamint a portálokhoz és a PipeWire-hoz kapcsolódó asztali szolgáltatások pontosabb integrációjára.
Ebben a tervezett felépítésben a systemd-appd nevű új systemd-komponens kapna szerepet. Ennek célja, hogy információt adjon a futó alkalmazáspéldányokról, segítse a Flatpak-példányok hitelesítését, lehetővé tegye az olyan alkalmazások pontosabb kezelését, amelyek saját belső sandboxot is használnak, javítsa a PipeWire-hoz kapcsolódó azonosítást, és hosszabb távon kiváltsa a Flatpak jelenlegi D-Bus proxy modelljét. A korábbi tervezési dokumentumok alapján a Flatpak már most is kérheti a systemd-től, hogy az alkalmazáspéldányokat megfelelő cgroupokba helyezze, de ez jelenleg nem kötelező feltétel. A jövőbeli modellben viszont minden alkalmazáspéldányhoz külön cgroup tartozhatna, mert erre épülne az alkalmazásazonosság és a futási metaadatok követése. A tervezett irányvonal technikailag indokolt lehet,mivel a böngészők és a saját belső sandboxot használó összetettebb alkalmazások pontosabb azonosítást és szigorúbb futásidejű követést igényelnek.
Ha a későbbi verziók systemd-appd nélkül nem tudnák ugyanazt a funkcionalitást nyújtani, akkor a systemd-t nem használó rendszereknek saját kompatibilitási réteget, downstream patchkészletet vagy alternatív megvalósítást kellene fenntartaniuk, már ha egyáltalán hajlandók ezt meglépni az érintett disztribuciók fejlesztőcsapatai, azonban egyelőre egy érintett disztribució álláspontja sem ismert. További részletek Sebastian Wick blogbejegyzésében olvashatók.
