Was ist eine PLIST? Apples Property-List-Format
Die kurze Antwort: Ein strukturierter Container für App-Daten
Eine PLIST-Datei – kurz für Property List – ist Apples Standardformat zum Speichern von Konfigurationseinstellungen, Präferenzen und serialisierten Daten im gesamten Ökosystem: macOS, iOS, iPadOS, watchOS und tvOS. Ihre Wurzeln reichen bis ins späte 1980er-Jahre zu NeXTSTEP zurück, und sie bleibt das Rückgrat dafür, wie deine Apps deine Entscheidungen speichern, wie Systemdienste ihre Konfigurationen laden und wie Xcode-Projekte beschreiben, was gebaut werden soll. Du hast gerade Hunderte von PLIST-Dateien auf deinem Mac, ob du es merkst oder nicht. Öffne das Terminal und führe `ls ~/Library/Preferences/` aus. Du wirst eine lange Liste von Dateien wie `com.apple.finder.plist`, `com.apple.dock.plist` und viele andere sehen – eine für fast jede Anwendung, die du jemals benutzt hast. Diese einfachen Dateien sagen dem Finder, wie breit deine Seitenleiste sein soll, sagen dem Dock, wo deine Symbole leben, und erinnern Safari daran, welche Tabs beim letzten Beenden geöffnet waren. Das Format unterstützt einen kleinen, festen Satz von Datentypen: Strings, Integers, Gleitkommazahlen, Booleans, Datumsangaben, Binärdaten (Data), Arrays und Dictionaries. Das ist die gesamte Liste. Es gibt keine benutzerdefinierten Typen, keine Vererbung und keine Schemata. Das ist kein Versehen; es ist eine bewusste Designentscheidung. Apple benötigte ein Format, das das OS mit minimalem Overhead lesen und schreiben konnte, und das einfach genug war, um eine manuelle Bearbeitung zu überstehen, ohne sofort den Zustand einer App zu beschädigen.
XML vs. Binär vs. JSON: Drei Varianten desselben Formats
Obwohl es ein PLIST-Format gibt, kommt es in drei verschiedenen Kodierungen vor. Sie zu verwechseln, ist eine häufige Fehlerquelle. Zuerst ist die **XML-PLIST**, die menschenlesbare Version. Öffne eine in einem Texteditor, und du siehst eine DOCTYPE-Deklaration, die auf `http://www.apple.com/DTDs/PropertyList-1.0.dtd` verweist, gefolgt von einem Meer verschachtelter Tags: `<dict>`, `<key>`, `<string>`, `<integer>`, `<true/>`. Xcode verwendet dies für seine Projektdateien (`project.pbxproj` ist eine Variante), und es ist das, was du willst, wenn du Einstellungen für ein Backup oder zur Inspektion exportierst. Der offensichtliche Nachteil ist die Ausführlichkeit. Ein einfaches Dictionary mit 20 Schlüsseln kann sich leicht über 150 Zeilen erstrecken. Aus Performance-Gründen verwendet macOS fast immer **Binär-PLIST** (bplist), wenn Dateien auf die Festplatte geschrieben werden. Wenn eine App ihre Präferenzen speichert, schreibt sie typischerweise eine Datei, die mit den magischen Bytes `bplist00` beginnt. Dieses Format ist deutlich kompakter und viel schneller zu parsen als sein XML-Pendant. Diese 150-zeilige XML-Datei kann in binärer Form auf nur 400 Byte schrumpfen. Der Kompromiss ist, dass du binäre PLISTs nicht in einem Standard-Texteditor lesen kannst; sie sehen einfach wie Kauderwelsch aus. Schließlich gibt es die **JSON-PLIST**, eine neuere Option, die seit macOS 10.7 unterstützt wird. Sie verwendet die Standard-JSON-Syntax, ist aber immer noch auf die Kern-PLIST-Datentypen beschränkt. Diese ist ein bisschen ein Sonderling. JSON unterscheidet nativ nicht zwischen Ganzzahlen und Gleitkommazahlen und hat keinen dedizierten Date-Typ, was einige subtile Einschränkungen mit sich bringt. Du wirst selten sehen, dass Apples eigene Tools JSON-PLISTs produzieren; sie erscheinen hauptsächlich, wenn Build-Tools von Drittanbietern oder CI-Pipelines Konfigurationsdateien generieren. Zum Glück kannst du mit Apples integriertem Kommandozeilen-Tool `plutil` einfach zwischen allen dreien konvertieren. Ein Befehl wie `plutil -convert xml1 com.apple.dock.plist -o dock_readable.plist` erstellt dir eine menschenlesbare Kopie deiner Dock-Einstellungen, ohne die ursprüngliche Binärdatei zu ändern.
Wo PLIST-Dateien liegen und was sie steuern
Zu wissen, wo man PLIST-Dateien findet, ist die halbe Miete, wenn du eine fehlerhafte App beheben oder Einstellungen auf eine neue Maschine migrieren musst. Sie befinden sich an einigen vorhersehbaren Orten. Deine persönlichen Anwendungseinstellungen werden in `~/Library/Preferences/` gespeichert. Hier befinden sich dein benutzerdefiniertes Dock-Layout, dein Terminal-Farbschema und deine Xcode-Tastaturbelegungen, alles an dein spezifisches Benutzerkonto gebunden. Die Dateinamen folgen einem Reverse-DNS-Benennungsschema, wie `com.apple.Terminal.plist` oder `com.googlecode.iterm2.plist`. Im Gegensatz dazu befinden sich Einstellungen, die für jeden Benutzer auf einem Mac gelten, in `/Library/Preferences/`. Diese steuern systemweite Verhaltensweisen wie Netzwerkkonfiguration und Zeitzone und erfordern typischerweise Administratorrechte zur Änderung. PLISTs speichern nicht nur Präferenzen; sie treiben auch das macOS-Automatisierungssystem an. Die Dateien in `/Library/LaunchAgents/`, `/Library/LaunchDaemons/` und die benutzerspezifischen `~/Library/`-Versionen definieren Hintergrunddienste und geplante Aufgaben. Eine LaunchDaemon-PLIST teilt dem `launchctl`-Dienst mit, welche ausführbare Datei ausgeführt werden soll, welche Argumente übergeben werden sollen, ob sie bei einem Absturz neu gestartet werden soll und ihren Zeitplan. Das vielleicht wichtigste von allen ist die `Info.plist`-Datei, die in jedem `.app`-Paket versteckt ist. Klicke im Finder mit der rechten Maustaste auf eine beliebige App, wähle „Paketinhalt anzeigen“ und navigiere zu `Contents/Info.plist`, um sie zu sehen. Diese Datei ist der offizielle Ausweis der App, der ihren Bundle-Identifier, die minimale OS-Version, erforderliche Hardwarefunktionen, URL-Schemata und benötigte Berechtigungen (wie Kamera- oder Mikrofonzugriff) deklariert. Auf iOS ist die `Info.plist` das, was der App Store und das OS selbst verwenden, um zu entscheiden, ob deine App überhaupt auf einem bestimmten Gerät laufen kann. Ein wichtiger Warnhinweis: Wenn du planst, eine Datei in `~/Library/Preferences/` zu bearbeiten, beende immer zuerst die entsprechende App. Das Lesen einer Datei, während die App läuft, ist in Ordnung, aber wenn du Änderungen schreibst, wird die App diese wahrscheinlich beim nächsten Speichern ihres Zustands überschreiben. Beende die App, nimm deine Änderungen vor und starte sie dann neu.
PLIST-Dateien lesen und bearbeiten: Deine praktischen Optionen
Apple bietet ein vollständiges Toolkit zum Lesen und Ändern von PLIST-Dateien, von ausgefeilten grafischen Oberflächen bis hin zu leistungsstarken Kommandozeilen-Dienstprogrammen. Für die meisten Entwickler ist **Xcodes integrierter PLIST-Editor** der beste Ausgangspunkt. Er öffnet jede PLIST-Datei in einer strukturierten Baumansicht mit typgerechter Bearbeitung: Du erhältst Kontrollkästchen für Booleans, Datumsauswahlen für Date-Werte und sauber erweiterbare Arrays und Dictionaries. Du kannst Schlüssel hinzufügen, löschen und neu anordnen, ohne jemals rohes XML zu berühren. Dies ist der standardmäßige, genehmigte Workflow zur Bearbeitung von `Info.plist`- und Entitlement-Dateien. Für Scripting und Automatisierung ist das **Kommandozeilen-Tool `plutil`** unverzichtbar. Es wird mit macOS geliefert und ist ein Kraftpaket für Validierung, Konvertierung und Bearbeitung auf Schlüsselebene. `plutil -lint myfile.plist` prüft schnell auf Syntaxfehler, während ein Befehl wie `plutil -replace NSHighResolutionCapable -bool YES MyApp.app/Contents/Info.plist` einen einzelnen Schlüssel setzen kann, ohne einen Editor zu öffnen. Es ist ein Muss für Shell-Skripte und CI/CD-Pipelines. Wenn du Benutzereinstellungen ändern möchtest, ist der **`defaults`-Befehl** das richtige Tool dafür. Du kannst eine aktuelle Einstellung mit `defaults read com.apple.finder ShowPathbar` lesen oder sie mit `defaults write com.apple.finder ShowPathbar -bool TRUE` ändern. Genau deshalb werden so viele macOS „Power-User“-Anpassungen als einfache `defaults write`-Einzeiler-Befehle geteilt. Manchmal brauchst du mehr Leistung. **Drittanbieter-Editoren** wie PlistEdit Pro (ca. 12 $ im Mac App Store, Stand 2025) fügen Funktionen hinzu, die Xcode fehlen, wie z.B. Side-by-Side-Vergleich, direkte Bearbeitung binärer PLISTs ohne Konvertierung und Stapelverarbeitungen. Wenn du täglich mit PLISTs kämpfst, ist ein spezielles Tool eine kluge Investition. Und was ist mit einem einfachen **Texteditor**? Er funktioniert perfekt für XML-PLISTs, aber er beschädigt binäre. Wenn du eine Binärdatei in VS Code oder BBEdit öffnest, musst du sie zuerst mit `plutil -convert xml1` in XML konvertieren. Nach der Bearbeitung konvertiere sie mit `plutil -convert binary1` zurück, bevor das System sie verwenden kann.
PLIST-Dateien konvertieren: Was CocoConvert kann und was nicht
CocoConvert wurde entwickelt, um die gängigsten PLIST-Konvertierungsszenarien zu bewältigen, denen Nutzer im Web begegnen: XML-PLISTs in JSON konvertieren, JSON in XML-PLIST umwandeln und binäre PLIST-Dateien in lesbares XML dekodieren, ohne dass Entwickler-Tools benötigt werden. Für die XML-zu-JSON-Konvertierung ordnet CocoConvert die PLIST-Datentypen ihren JSON-Entsprechungen zu. Strings, Integers, Arrays und Dictionaries werden sauber konvertiert. Booleans werden zu JSON `true` und `false`. Datumsangaben werden in standardmäßige ISO 8601-Strings serialisiert (z.B. `2024-11-03T14:22:00Z`). Alle Binärdaten aus `<data>`-Elementen werden im Output base64-kodiert, was den Inhalt perfekt erhält, aber bedeutet, dass diese spezifischen Felder im JSON nicht menschenlesbar sind. Die Binär-zu-XML-Funktion ist besonders nützlich. Wenn du jemals ein Präferenz-Backup von einem iPhone mit einem Drittanbieter-Tool exportiert hast, kann CocoConvert die resultierende `bplist`-Datei parsen und eine lesbare XML-PLIST erzeugen, sodass du deren Inhalt überprüfen kannst, ohne Xcode auf deinem Rechner installieren zu müssen. Wir müssen auch klarstellen, was CocoConvert nicht kann: Es kann PLIST-Dateien nicht zurück ins Binärformat konvertieren. Das Generieren einer binären PLIST erfordert das Erstellen präziser Byte-Level-Offset-Tabellen, eine Aufgabe, die für Apples native Bibliotheken einfach, aber in einem Webdienst sehr schwierig korrekt zu implementieren ist. Wenn du eine modifizierte binäre PLIST zurück auf ein Gerät schreiben musst – um beispielsweise bearbeitete iPhone-Präferenzen wiederherzustellen – musst du `plutil` auf einem Mac oder einen nativen Editor wie PlistEdit Pro verwenden. Während macOS oft eine XML-Datei lesen kann, wo eine binäre erwartet wird, sind einige Apps streng und werden die XML-Version ablehnen oder ignorieren. CocoConvert validiert auch die Struktur, nicht die Semantik. Eine PLIST mit einem fehlerhaften Bundle-Identifier oder einer ungültigen OS-Version wird problemlos konvertiert, denn aus Sicht des Dateiformats ist sie gültig. Das sind Probleme auf Anwendungsebene, die ein Formatkonverter nicht diagnostizieren kann.
Häufige PLIST-Probleme und wie du sie diagnostizierst
PLIST-Korruption ist selten, aber ein einzigartig frustrierendes macOS-Troubleshooting-Szenario. Die Symptome – eine App, die nicht startet, Präferenzen, die bei jedem Neustart zurückgesetzt werden, ein Systemdienst, der stillschweigend fehlschlägt – weisen selten direkt auf eine bestimmte Datei hin. Die häufigste Ursache ist **Korruption durch einen unsachgemäßen Schreibvorgang**. Wenn macOS abstürzt oder die Stromversorgung unterbrochen wird, während eine App ihre Einstellungen speichert, kann die PLIST auf der Festplatte abgeschnitten oder verfälscht werden. Dein erster Diagnoseschritt sollte `plutil -lint ~/Library/Preferences/com.example.app.plist` sein. Eine intakte Datei gibt `OK` zurück; eine beschädigte gibt einen Parse-Fehler aus, normalerweise mit einer hilfreichen Zeilennummer oder einem Byte-Offset. **Berechtigungsprobleme** sind der zweithäufigste Grund. Eine PLIST-Datei im `~/Library/Preferences/`-Verzeichnis eines Benutzers, die irgendwie `root` gehört, führt dazu, dass eine App bei jedem Start stillschweigend auf ihre Standardeinstellungen zurückfällt. Überprüfe den Besitz mit `ls -l ~/Library/Preferences/com.example.app.plist` – der Besitzer muss dein Benutzername sein, nicht `root`. Du kannst es mit `sudo chown $(whoami) ~/Library/Preferences/com.example.app.plist` beheben. Ein noch subtileres Problem sind **zwischengespeicherte Präferenzen**. Um schneller zu sein, verwendet macOS einen Hintergrund-Daemon, `cfprefsd`, um Präferenzwerte zwischenzuspeichern. Das bedeutet, dass selbst wenn du eine PLIST-Datei direkt auf der Festplatte bearbeitest, die laufende App möglicherweise weiterhin die alte, zwischengespeicherte Version liest. Wenn deine `defaults write`-Änderungen nicht wirksam werden, ist dies fast sicher der Grund. Erzwinge einen Cache-Flush mit `killall cfprefsd` (es startet automatisch neu) oder melde dich einfach ab und wieder an. Xcode-Build-Fehler lassen sich oft auf eine fehlerhafte `Info.plist` zurückführen. Der Build schlägt mit einem vagen Fehler wie „Die Daten konnten nicht gelesen werden, da sie nicht im richtigen Format vorliegen“ fehl, was lediglich Xcodes Art ist zu sagen, dass die Datei nicht geparst werden konnte. Bevor du etwas anderes tust, suche nach Merge-Konfliktmarkierungen wie `<<<<<<<` im XML, oder führe einfach `plutil -lint` für die Datei aus. Führe bei jeder PLIST, die du nicht selbst erstellt hast – sei es aus einem Geräte-Backup, einem GitHub-Repo oder von einem Kollegen – zuerst `plutil -lint` aus. Das dauert drei Sekunden und erspart eine Menge Verwirrung.
PLIST im breiteren Apple-Entwicklungs-Workflow
Über das bloße Speichern von Präferenzen hinaus sind PLIST-Dateien eine tragende Infrastruktur in Apples Entwicklungstoolchain, oft auf Weisen, die erst offensichtlich werden, wenn etwas kaputtgeht. Das Code-Signing einer App hängt von einer Entitlements-PLIST ab. Dies ist die Datei, die genau deklariert, welche speziellen Funktionen eine App verwenden darf: iCloud, Push-Benachrichtigungen, App Groups, Keychain-Sharing und so weiter. Diese Datei wird während des Builds direkt in die Code-Signatur der App eingebettet. Wenn die Entitlements-PLIST nicht mit dem Provisioning Profile übereinstimmt, wird die App einfach nicht auf einem Gerät installiert. Apples `codesign`-Tool liest und validiert diese Datei direkt. Xcodes Build-System selbst stützt sich stark auf PLISTs. Die `*.xcscheme`-Dateien, die sich in `.xcodeproj/xcshareddata/xcschemes/` befinden, sind PLISTs, die beschreiben, welche Targets gebaut werden sollen, welche Argumente beim Start übergeben werden sollen und welche Umgebungsvariablen gesetzt werden sollen. Da sie nur strukturiertes XML sind, können sie sicher in die Versionskontrolle eingecheckt werden und sind leicht zwischen Branches zu vergleichen. Sogar die Metadaten für die App Store-Einreichung werden über eine PLIST verwaltet. Das Privacy Manifest (`PrivacyInfo.xcprivacy`), eingeführt in Xcode 15 und für die meisten App-Einreichungen nach Mai 2024 erforderlich, ist eine PLIST-Datei. Es deklariert, welche APIs deine App verwendet, die potenziell für Fingerprinting genutzt werden könnten, und warum. Einen Fehler in dieser Datei zu haben, verursacht keinen Build-Fehler; es führt zu einer Ablehnung im App Store Review, was deutlich nervtötender zu debuggen ist. Für jeden, der plattformübergreifende Tools entwickelt, die mit Apples Ökosystem interagieren – CI-Systeme, MDM-Lösungen oder Backup-Dienstprogramme – ist ein tiefes Verständnis des PLIST-Formats unvermeidlich. Die Formatspezifikation ist in Apples `CFPropertyList`-Referenz dokumentiert, aber das Binärformat wurde auch gründlich reverse-engineert. Exzellente Open-Source-Parser existieren für Python, Ruby, Go und Rust. Das `plistlib`-Modul in Pythons Standardbibliothek (seit 3.4) ist besonders zuverlässig für Produktionsskripte, die Geräte-Backups oder Xcode-Projektdateien verarbeiten müssen.