Wie iOS 18.3 SwiftData zerstörte (in gewisser Weise)

SwiftData hat ein Problem. Seit iOS 18.3 sind Queries, die über eine Sortierung verfügen, potenziell problematisch. Sie können nämlich zum unmittelbaren Absturz der App führen. Dieses Verhalten existiert auch in iOS 18.3.1 und in der ersten Beta von iOS 18.4.

Zu viele Ebenen

Als ich schrieb, dass Sortierungen in Queries potenziell problematisch sind, hatte das einen Grund. Denn Sortierungen funktionieren weiterhin, sofern der zugehörige Key-Path sich unmittelbar auf eine Property des Models bezieht, dessen Instanzen über den Query bezogen werden sollen. Dazu ein Beispiel:

@Model final class Author {
    var firstName: String
    var lastName: String

    init(firstName: String, lastName: String) {
        self.firstName = firstName
        self.lastName = lastName
    }
}

@Model final class Book {
    var title: String
    var author: Author

    init(title: String, author: Author) {
        self.title = title
        self.author = author
    }
}

Die Klasse Book verfügt über die zwei Eigenschaften title und author, wobei letztere auf eine Instanz einer eigenen Model-Klasse namens Author verweist. Ein Query auf Bücher, sortiert nach Titel, ist mit SwiftData auch ab iOS 18.3 weiter ohne Probleme möglich:

@Query(
    sort: \Book.title,
    order: .forward
)
private var notes: [Note]

Vorbei ist es aber mit der heilen Welt, wenn die Sortierung sich nicht unmittelbar auf eine Eigenschaft von Book bezieht, sondern eine weitere Ebene hinzukommt. Wie im folgenden Fall, in dem für die Sortierung der Bücher die Nachnamen der Autoren verwendet werden sollen.

@Query(
    sort: \Book.author.firstName,
    order: .forward
)
private var notes: [Note]

Führt man solch eine Query aus, kommt es seit iOS 18.3 zum Crash der App. Zumindest, wenn noch eine weitere Voraussetzung erfüllt ist, die diesen Fehler geradezu perfid macht.

Fehler nicht in Debug-Build-Konfiguration

Das gezeigte Beispiel lässt sich fehlerfrei umsetzen, wenn man die App direkt aus Xcode heraus in der standardmäßig aktiven Debug-Build-Konfiguration installiert. Bei Tests einer App über Xcode und während der Entwicklung fällt dieses Problem also gar nicht auf, da es schlicht nicht existiert. Erst mit der Release-Build-Konfiguration führt der Query zu einem Crash der App. Und das realisiert man möglicherweise erst, wenn die App schon zur Veröffentlichung freigegeben wurde.

Dafür lässt sich das Fehlerbild mit diesem Wissen einfach nachstellen: Man ändere lediglich im Scheme die Build-Konfiguration im Bereich Run von Debug auf Release. Schon stürzt die App mit dem genannten Query auch bei Installation über Xcode heraus ab. Die Fehlermeldung des Compilers lautet wie folgt:

Fatal error: KeyPath Book.\.\ points to a field (\) that is unknown to Book and cannot be used.

Fehler aus der Hölle

Die beschriebene Gesamtkonstellation macht die aktuelle Problematik mit Queries in SwiftData zu einem grässlichen Thema. Dabei geht es bei der Sortierung von Queries um eine API, die in dem gezeigten Fall nicht auf außergewöhnliche Weise genutzt wird, die aber jüngst mit iOS 18.3 in der Release-Build-Konfiguration massive Probleme bereitet. Und Abhilfe vonseiten Apple ist aktuell nicht in Sicht. Wie eingangs erwähnt, existiert das Problem auch in iOS 18.3.1 und der ersten Beta von iOS 18.4.

Was also tun? Letztlich bleibt nur, in dem beschriebenen Fehlerfall auf eine Sortierung über Queries zu verzichten und die Sortierung separat in einem zweiten Schritt auszuführen. So kann man weiterhin die gewünschten Daten mittels Query auslesen, dann aber die Sortierung selbst noch einmal auf das Query-Ergebnis anwenden. Erfreulicherweise ist dieser Umweg zumindest funktional frei von Fehlern und Abstürzen.

Die beschriebene Problematik wurde auch bereits in Apples offiziellen Entwickler-Foren angesprochen. Der Unmut ist deutlich herauszuhören, ebenso wie die laute Stille zur Lösung des Problems: https://developer.apple.com/forums/thread/773308

Ich hoffe sehr, dass Apple zeitnah dieses Fehlverhalten beheben wird, möglicherweise auch mit einem weiteren Release in Form von iOS 18.3.2, spätestens aber mit der finalen Version von iOS 18.4. Andernfalls muss sich Apple die Frage gefallen lassen, mit welcher Ernsthaftigkeit Entwickler auf solch fundamentale Frameworks wie SwiftData setzen sollen, wenn ein einzelner Feature-Release von iOS bestehende Apps gänzlich unbrauchbar machen kann. Letztlich stellt es die Qualität von Apples Software – sowohl in Bezug auf Betriebssysteme als auch Frameworks – stark infrage. Und die fehlende Reaktion vonseiten Apples zu diesem Thema wiegt obendrauf noch schwer.