Playable nativ auf macOS und Linux

Playable
20. September 2026
PAP-024

Playable erhält zwei eigenständige Desktop-Apps mit gemeinsamem Swift-Kern. macOS verwendet SwiftUI und AppKit, Linux GTK4 und libadwaita. Beide teilen Fachlogik, API-Vertrag, lokale Datenregeln und Wiedergabezustände, aber keine Oberfläche und keine Annahme über den UI-Ereigniszyklus. Der bestehende Projektplan bleibt bis Epic 09 unverändert; die Linux-Arbeit folgt als Epic 10 bis 13.

1. Die Entscheidung

Playable wird nicht als eine Oberfläche gebaut, die sich an zwei Systeme anpasst. Es wird als ein Produkt mit zwei nativen Oberflächen gebaut. Die macOS-App folgt den Konventionen von macOS, die Linux-App den Konventionen von GNOME und libadwaita. Gemeinsam bleibt, was für einen Nutzer auf beiden Systemen dasselbe bedeutet: Podcast, Episode, Favorit, Konto, Warteschlange, Wiedergabezustand, Suche und Synchronisation.

Der gemeinsame Teil ist ein Satz kleiner Swift-Module. Sie kennen weder Fenster noch Schaltflächen, weder AppKit noch GTK. Sie sprechen mit der Playable-Plattform über deren versionierten OpenAPI-Vertrag und erhalten Live-Änderungen über die dafür vorgesehene Echtzeitverbindung. Diese Verträge entstehen bereits in Epic 03 und sind damit die feste Grenze für beide Apps.¹²

Swift ist auf den vorgesehenen Linux-Systemen offiziell verfügbar.³ Damit liegt die sprachliche Gemeinsamkeit dort, wo sie Wert hat, ohne den nativen Charakter der Apps einzuschränken.

2. Der gemeinsame Kern

Der Kern stellt Werte und Fähigkeiten bereit, keine globalen App-Zustände. Ein Podcast oder eine Episode ist ein unveränderlicher Swift-Wert. Ein Repository lädt und verändert Daten. Ein Wiedergabecontroller übersetzt Befehle und Ereignisse in einen nachvollziehbaren Zustand. Die Apps entscheiden selbst, wie sie diesen Zustand beobachten und darstellen.

Die wichtigsten Grenzen sind PodcastRepository, AccountRepository, FavouritesRepository, RealtimeFeed, AudioEngine, CredentialStore, NowPlayingService und NotificationService. Jede Plattform setzt nur die Grenzen um, für die sie eigene Systemdienste besitzt. Transportmodelle bleiben in PlayableAPI, Datenbankzeilen in PlayableStore und Framework-Objekte in der jeweiligen App.

Die API wird aus dem veröffentlichten OpenAPI-Vertrag erzeugt. Der erzeugte Client bleibt hinter PlayableAPI, damit eine Änderung des Generators nicht in die Oberfläche wandert. Auf Linux übernimmt ein AsyncHTTPClient-Transport die Verbindung.⁴⁵ Die Echtzeitverbindung liefert Ereignisse mit denselben kanonischen Kennungen wie die REST-Antworten und kann nach einem Verbindungsabbruch einen konsistenten Stand wiederherstellen.²

Lokale Daten liegen in SQLite. SQLite.swift ist dafür die erste Wahl, weil es Swift und Linux ausdrücklich unterstützt.⁶ Geheimnisse gehören nicht in diese Datenbank. Sie liegen auf macOS im Keychain und auf Linux über libsecret im Secret Service.

3. Zwei native Apps

Auf macOS entsteht die Oberfläche mit SwiftUI und gezielten AppKit-Bausteinen. Fenster, Seitenleiste, Toolbar, Menüs, Tastaturkürzel, Einstellungen, Wiederherstellung und Systemmediensteuerung verhalten sich wie Bestandteile einer macOS-App. AVFoundation übernimmt die Wiedergabe, Keychain die Sitzung und MediaPlayer die Systemanzeige.

Auf Linux entsteht die Oberfläche mit GTK4 und libadwaita. Navigation, Toolbar, Listen, Dialoge, adaptive Aufteilung und schmale Fenster folgen der GNOME Human Interface Guideline.⁷ Die Anwendung verwendet Standard-Widgets, damit Tastaturbedienung und AT-SPI-Semantik bereits in den Grundelementen vorhanden sind.⁸

swift-adwaita ist die bevorzugte Swift-Bindung. Das Package deckt GTK4 und libadwaita ab und führt eigene Hinweise für GLib-Nebenläufigkeit und GTK-Objektlebenszeiten.⁹¹⁰¹¹ Seine Typen bleiben vollständig in PlayableLinux, damit die App bei Bedarf zu einer anderen Bindung wechseln kann.

Die Wiedergaberegeln sind gemeinsam, die Decoder nicht. Ein pausierter Live-Stream schließt seine Verbindung. Beim Fortsetzen beginnt er an der aktuellen Live-Position. Eine aufgezeichnete Episode behält ihre Position und kann suchen. Beide Audioadapter melden dieselben Zustände: Auflösen, Puffern, Abspielen, Pausieren, Stoppen und Fehler.

4. Packages und Ausweichwege

Jede externe Abhängigkeit bekommt eine enge Aufgabe und eine definierte Ausweichroute. Ein Package wird nur übernommen, wenn der Feasibility-Lauf seine benötigten Funktionen ohne Fork nachweist.

GStreamer playbin übernimmt Formaterkennung, Decoderwahl und Netzwerkpufferung.¹² Der Swift-Adapter bleibt klein und serialisiert alle Pipeline-Aufrufe. gstreamer-swift wird im Feasibility-Lauf geprüft, aber nur übernommen, wenn Bus-Nachrichten, Abbruch, Streamwechsel und Spektraldaten vollständig zugänglich sind.¹³

libsecret ist die direkte Anbindung an den Secret Service.¹⁴ MPRIS stellt Wiedergabestatus, Metadaten, Lautstärke und Befehle bereit.¹⁵ Für Live-Inhalte meldet die Linux-App ausdrücklich, dass Suchen nicht möglich ist.

5. Die Epics in Reihenfolge

Die bestehenden Epics 01 bis 07 bauen Plattform, Daten, API, Benachrichtigungen, Website, Dashboard und Dokumentation. Epic 08 und 09 liefern die macOS-App und das vollständige Podcast-Erlebnis. Ihre gemeinsamen Swift-Teile werden von Beginn an frei von Apple-UI-Typen gehalten. Dadurch beginnt Linux nicht mit einer nachträglichen Portierung, sondern mit einem bereits getesteten Kern.

E10 wird erst als GitHub-Epic angelegt, wenn E08 die gemeinsamen Grenzen tatsächlich liefert. Sein erster Vorgang ist ein Wegwerf-Prototyp, der die riskanten Linux-Anbindungen gemeinsam im Flatpak-Runtime prüft. Die Entscheidung über Wrapper fällt aus diesem Lauf, nicht aus der API-Oberfläche eines Repositories.

6. Prüfpunkte und Fallstricke

Flatpak gehört in den ersten Linux-Lauf. Ein Flathub-Build darf seine SwiftPM-Abhängigkeiten nicht während des Baus aus dem Netz laden. Die Quellen werden deshalb mit dem offiziellen SwiftPM-Generator vorab in das Manifest aufgenommen.¹⁶¹⁷ GTK, libadwaita und GStreamer kommen dynamisch aus dem GNOME-Runtime. Ein vollständig statisches Swift-Linux-SDK ersetzt diese Bibliotheken nicht.

7. Wo Plan und Fortschritt stehen

Dieses Paper hält die Architektur, die Paketentscheidungen und die Reihenfolge der Epics fest. Es ändert sich, wenn eine Modulgrenze, ein Package, ein Ausweichweg oder die Reihenfolge geändert wird. Das GitHub-Projekt bleibt die einzige Sicht auf den Fortschritt. Ein Epic trägt den Zuschnitt, seine Issues tragen die Arbeit und ihre Checklisten.¹⁸

Die Epics E10 bis E13 werden als Board-Vorgänge angelegt, sobald die Linux-Umsetzung freigegeben wird. Bis dahin ist dieses Paper die technische Entscheidung, nicht der Beginn einer Implementierung.

Package.swift
Sources/
  PlayableCore/
    Domain/
    Errors/
    Ports/
    State/
    UseCases/
  PlayableAPI/
    Generated/
    Client/
    Mapping/
    Realtime/
  PlayableStore/
    Database/
    Migrations/
    Repositories/
    Sync/
  PlayableLinux/
    Application/
    Presentation/
    UI/
    Platform/
Apps/
  macOS/
    PlayableMac/
      Application/
      Presentation/
      UI/
      Platform/
Packaging/
  Flatpak/

Native UI
  -> platform presenter
  -> shared use case
  -> repository or platform port
  -> API, store or audio adapter
  -> normalized domain event
  -> shared state transition
  -> platform presenter
  -> native UI event loop