Es ist mittlerweile schon ein bisschen zur Gewohnheit geworden, dass ich kurz nachdem Apple die Termine für die nächste WWDC bekannt gibt, eine Liste der Dinge zusammenstelle, die mir in Apples Tools und Frameworks am meisten fehlen. Ich hoffe, dass diese Übersichtsartikel für Apple-Ingenieure hilfreich sind, um intern Prioritäten zu bestätigen oder anzupassen. Und bisher wurde tatsächlich jedes Jahr 33 % von dem, was ich mir gewünscht habe, Realität! Mag Zufall sein, aber ich finde es trotzdem gut.
Einige dieser Ideen habe ich schon vor langer Zeit als Radar eingereicht. Aber oft bringt es neue Dinge zum Vorschein, die mir im Arbeitsalltag nicht begegnen, wenn ich mir die Zeit nehme, über die Dinge nachzudenken, die mir am meisten fehlen. Du wirst in dieser Liste also ein paar offensichtliche Sachen finden, aber ich bin mir sicher, dass auch Dinge dabei sind, an die du nie gedacht hast. Ich würde gerne hören, was du denkst – kommentiere doch auf Social Media und erwähne meinen Handle @Jeehut.
ℹ️ Es gibt noch 3 Wünsche aus meinem letztjährigen Artikel, die noch nicht umgesetzt wurden, und ich bin weiterhin der Meinung, dass wir sie brauchen:
Einfache App-Modularisierung in Xcode ohne den ganzen Aufwand
Tortendiagramme gibt es jetzt, aber Spinnendiagramme fehlen noch!
Streamer-Modus in Xcode, um sensiblen Code in Calls/Aufnahmen zu verbergen
#1 – Eine WeatherKit-ähnliche API für Apple Sports
Ich war überrascht, als Apple WeatherKit 2022 vorstellte. Es war das erste System-Framework (das ich kenne), das für Entwickler nicht kostenlos nutzbar war – aber doch 500.000 Aufrufe pro Monat gratis mitbrachte. Das war großzügig genug, damit Indie-Entwickler interessante neue Apps darauf aufbauen konnten. Apple hatte im Grunde den Datenteil einer System-App extrahiert und Entwicklern zugänglich gemacht. Und nicht nur das – sie machten es auch für Bootstrapped-Indies erschwinglich!
Die neue Apple Sports App.
Die Einführung der Apple Sports App in den USA brachte mich auf eine Idee: Was wäre, wenn Apple dasselbe mit den Daten dieser App machen würde? Ich hatte über die Jahre mehrere App-Ideen, die ich als Prototyp gebaut, aber nicht veröffentlichen konnte, weil es keine bezahlbare Live-Sportdaten-API gab. Deren Preise richten sich an große Konzerne (wie es bei vielen APIs der Fall ist). Aber angesichts der Tatsache, dass die beste Art, ein Sportevent heutzutage zu erleben, die Vision Pro ist, wäre es meiner Meinung nach sehr sinnvoll, wenn Apple es Indies so einfach wie möglich macht, neue Erlebnisse rund um Sportevents zu entwickeln.
Ich wünsche mir eine neue „SportsKit”-API mit einem großzügigen Gratis-Kontingent wie bei WeatherKit!
#2 – Einen .zoom-Modifier für ScrollView in SwiftUI
Eines der ersten Feature-Wünsche für den Spielbildschirm meiner Kreuzworträtsel-App CrossCraft war, hinein- und herauszuzoomen, um einen besseren Überblick über die zusammenhängenden Buchstaben zu bekommen. Aber als ich .zoom tippte, um den entsprechenden Modifier zu meiner ScrollView in SwiftUI hinzuzufügen, war ich schockiert festzustellen, dass es ihn gar nicht gibt! 😱
Es gibt zwar Workarounds mit einer benutzerdefinierten MagnifyGesture, einem GeometryReader basierend auf dem .scaleEffect-Modifier mit eigenen @State-Properties, aber das funktioniert nur für eingeschränkte Anwendungsfälle wie das Zoomen in Bilder. Meine View ist aber eine ScrollView, die sich ganz anders verhält als eine normale View. Ich habe mehrere Ansätze ausprobiert, konnte es aber nicht so zum Laufen bringen, wie man es erwarten würde. Und selbst wenn ich es geschafft hätte – den Inhalt einer ScrollView zu zoomen ist ein so häufiger Anwendungsfall, dass es wirklich in ScrollView eingebaut und einfach nutzbar sein sollte, ohne den ganzen Aufwand.
Ich wünsche mir einen
.zoom(scale:offset:)-Modifier fürScrollViewin SwiftUI!
#3 – SwiftData-Limitierungen mit CloudKit beheben
Paul Hudson hat es perfekt in seinem großartigen SwiftData + CloudKit Artikel formuliert:
SwiftData with iCloud has a requirement that local SwiftData does not: all properties must be optional or have default values, and all relationships must be optional. The first of those is a small annoyance, but the second is a much bigger annoyance – it can be quite disruptive for your code.
Dem ist wirklich nicht viel hinzuzufügen, außer dass ich eine Menge Computed Properties in allen meinen Modellen schreiben musste, um Optionals auf Non-Optionals zu mappen. Es ist sicher, meine Apps stürzen nicht ab. Warum ist das also nicht in irgendeinem SwiftData-Macro eingebaut?
Ich wünsche mir, dass Non-Optional-Typen in SwiftData-Modellen mit CloudKit funktionieren.
#4 – Persistente Windows und Volumes in visionOS
Ich habe so viele App-Ideen für visionOS, die nur dann Sinn ergeben, wenn die Position von Windows oder Volumes über App-Neustarts und sogar Systemneustarts oder Updates hinweg gespeichert werden könnte. Ich habe zum Beispiel eine App namens Posters veröffentlicht, mit der man seine Wände mit automatisch aktualisierenden, interaktiven Filmpostern dekorieren kann – aber wenn du das Gerät neustartest, sind sie weg. Die Erweiterung der Realität ist nur vorübergehend.
Wände dekorieren mit Posters in visionOS.
Ich verstehe, dass Apple uns im Shared Space keinen vollen ARKit-Zugriff geben möchte. Es ist nicht möglich, gute Performance zu haben, wenn alle Apps gleichzeitig ARKit nutzen. Das wünsche ich mir auch nicht. Aber das System trackt die Fensterpositionen bereits.
Ich wünsche mir eine (vom Nutzer genehmigte) Option, um Window-/Volume-Positionen zu speichern.
#5 – Modale Texteingabe auf tvOS (wie bei PlayStation)
Auf iOS, iPadOS und visionOS bekommen wir QWERTY-Tastaturen, weil sie bekannt, schnell und einfach zu tippen sind. Ausgerechnet auf tvOS hat man sich entschieden, die Tasten in eine Zeile zu setzen. Die Folge: Um zu einer bestimmten Taste zu gelangen, braucht man viel länger als bei einem QWERTY-ähnlichen Rastersystem. Außerdem nimmt die Texteingabe die volle Breite des TV-Bildschirms ein und wird oben platziert, sodass sie zum Hauptfokus wird. Warum das Ganze? Schau dir einfach mal diese viel bessere modale Tastatur-UI von Sony aus dem Jahr 2013 an:
Virtuelle Tastatur auf der PS4.
Das Fehlen einer solchen Lösung macht Erlebnisse unmöglich, bei denen die Tastatur nur ein Zubehör zu einer ansonsten interessanteren View ist. Weil sie fehlt, habe ich meine ursprünglichen Pläne verworfen, CrossCraft auch auf tvOS zu bringen. Ich hätte es geliebt, Kreuzworträtsel auf dem Fernseher zu generieren und zu lösen. Das könnte ein tolles Familienerlebnis sein. Aber mit der aktuellen Tastatur ist es ein UX-Albtraum!
Ich wünsche mir eine schmalere, QWERTY-ähnliche Zusatztastatur auf tvOS.
#6 – Den String Catalog Editor nützlicher machen
Ja, String Catalogs sind neu. Deshalb ist es zu erwarten, dass sie noch nicht vollständig ausgereift sind. Aber selbst einige der grundlegendsten Dinge funktionieren aktuell nicht richtig. Einen Eintrag per Rechtsklick als „Reviewed” zu markieren, ist möglich. Aber mehrere gleichzeitig auswählen und markieren? Geht nicht. Eine neue Sprache mit dem Plus-Button unten hinzufügen? Geht. Aber eine mit dem Minus-Button entfernen? Geht nicht.
Abgesehen von den kaputten Grundlagen habe ich noch einen Feature-Wunsch, der absolut sinnvoll wäre: Die Oberfläche markiert Parameter bereits blau, es gibt also eine Erkennung. Aber wenn einer in einer anderen Sprache fehlt, gibt es keine Warnung. Das sollte es aber!
Ich wünsche mir, dass der String Catalog Editor in Xcode nützlicher wird.
💁♂️ UPDATE: Ich habe diese Verbesserungen selbst umgesetzt! 😍 Ich habe im Grunde Xcodes String Catalog Editor nachgebaut und als komplett kostenloses Feature in meine App TranslateKit integriert. Schau mal rein! 🌐 👍
#7 – Neue „Create LLM”-App wie „Create ML”
Hast du mal Create ML ausprobiert? Es ist ein Entwicklertool, das Apple bereits 2019 eingeführt hat und das meiner Meinung nach von vielen Entwicklern übersehen wird. Es ist ein KI-Tool, das das Problem der Klassifikation ziemlich gut löst. Schau dir einfach mal die verfügbaren Optionen an:
Create ML Projektvorlagen
Aber wir alle wissen, dass generative KI basierend auf LLMs der neue Trend ist. Und es gibt sogar Belege dafür, dass Apple aktiv daran arbeitet, in naher Zukunft etwas zu veröffentlichen. Angenommen, sie schaffen es, dieses Jahr etwas für Konsumenten auf den Markt zu bringen – was ich mir als Entwickler wünsche, ist ein Tool ähnlich wie Create ML, aber für LLMs. Stell dir vor, du könntest Apples Core-LLM-Modell mit deinen spezifischen Fachgebietsdaten und vielleicht sogar mit persönlichen Nutzerdaten anpassen, alles lokal auf dem Gerät gespeichert. Das würde erstaunliche neue App-Erlebnisse ermöglichen, und als Entwickler würden wir es kostenlos bekommen!
Ich wünsche mir eine einfache Möglichkeit, fachspezifische und personalisierte LLMs zu erstellen.
#8 – Verbesserte Source-Control-UX in Xcode
Jahr für Jahr wird die Integration von Git in Xcode besser und besser. Letztes Jahr hat es einen Punkt erreicht, an dem ich beschlossen habe, Xcode als meine Standard-Git-UI zu verwenden. Vorher nutzte ich Git-Fork, aber die volle Integration in Xcode ist unschlagbar!
Allerdings fehlen mir ein paar Dinge. Erstens: Obwohl Xcode eine Code-Diff-Ansicht hat, gibt es keine Möglichkeit, die Diffs vergangener Commits zu sehen – nur „Uncommitted Changes”. Zweitens: Die Diff-Ansicht selbst hat wirklich seltsame Farbwahlen, die es schwer machen zu verstehen, welcher Code entfernt und welcher hinzugefügt wurde. Es ist üblich, dass Tools Rot und Grün für klare Bedeutungen verwenden, was ich der aktuellen Lösung deutlich vorziehen würde. Drittens: Um in einem Schritt zu committen und zu pushen, muss man auf das Pfeil-nach-unten-Icon rechts neben dem „Commit”-Button klicken und „Commit and Push…” wählen. Ich würde eine Checkbox bevorzugen, die ihren Zustand behält, damit ich nicht jedes Mal mehrere Klicks machen muss. Und schließlich: Manchmal tippe ich eine Commit-Nachricht und finde beim Überprüfen der Änderungen etwas, das nicht stimmt. Dann wechsle ich zur Datei, nehme Anpassungen vor, und wenn ich zur Diff-Ansicht zurückkehre, ist meine Commit-Nachricht weg! Sie sollte noch da sein.
Ich wünsche mir eine verbesserte Source-Control-UX und vernünftige Git-Funktionalität in Xcode.
#9 – SwiftUI Previews zuverlässig zum Laufen bringen
Das ist ein Ärgernis seit den allerersten Tagen von SwiftUI. Das Designen in SwiftUI könnte so nützlich und schnell sein. Wenn doch nur die Previews funktionieren würden. Aber bei mir funktionieren die Previews 90 % der Zeit nicht. Und ich habe die gängigen Lösungen schon ausprobiert. Manchmal haben sie geholfen, manchmal nicht. Aber es ist nervig, Workarounds machen zu müssen, nur damit SwiftUI Previews funktionieren.
Ich wünsche mir, dass SwiftUI Previews jedes Mal funktionieren, wenn eine App für den Simulator baut.
#10 – Screenshots über SwiftUI Previews
App Store Screenshots zu erstellen ist schwierig. Man kann sie manuell auf 2–3 Geräten in einer Sprache machen. Aber sobald man sie lokalisieren möchte, wird der Aufwand unerträglich. Wenn ich raten müsste, würde ich sagen, dass 99 % der Screenshots im App Store veraltet sind. Aber das muss nicht so sein.
Wir brauchen etwas Hilfe von Apple, um das zu lösen. Und ich rede nicht von UI Tests. Die sind langsam. Die sind Extra-Aufwand. Die sind unzuverlässig. Ich schreibe heutzutage keine UI Tests mehr, weil es SwiftUI Previews gibt. Ja, ich habe oben geschrieben, dass sie nicht zuverlässig sind – das stimmt. Aber was wäre, wenn Apple das verbessern würde? Das #Preview-Macro macht es wirklich einfach, mehrere Previews in einer einzigen View zu erstellen. Und es ist relativ einfach, über die Initialisierung einen State an deine Views zu übergeben.
Ich wünsche mir eine API zum Erstellen lokalisierter Screenshots mit SwiftUI Previews.
Fazit
Das sind meine Top 10 Wünsche für die WWDC24. Stimmst du zu? Was habe ich vergessen?