Ich habe letztes Jahr bereits einen Artikel mit genau dem gleichen Zweck für die WWDC 2022 geschrieben und meine Top 3 Wünsche aufgelistet. Zum Glück wurde einer davon (Wunsch Nr. 3) tatsächlich erfüllt – die Xcode 14 Release Notes beschreiben das zugehörige neue Feature so:
Simplify an app icon with a single 1024x1024 image that is automatically resized for its target. Choose the Single Size option in the app icon’s Attributes inspector in the asset catalog. You can still override individual sizes with the All Sizes option. (18475136) (FB5503050)
Meine anderen beiden Wünsche gelten weiterhin und bleiben ganz oben auf meiner Wunschliste:
#1: Ein neues, reines Swift-Datenbank-Framework, das CoreData langfristig ersetzen soll. Wie ich mir so ein Framework vorstelle, habe ich hier beschrieben – lies dort für Details nach.
#2: Modularisierungs-Unterstützung für Apps in Xcode. Aktuell muss ich manuell eine lange Package.swift-Datei pflegen, um meine App zu modularisieren – mehr dazu hier.
Nachdem wir das geklärt haben, kommen hier 3 neue Wünsche, die ich für die diesjährige WWDC habe.
#3: Kreisdiagramme in der Swift Charts-Bibliothek
Am Ende meines letztjährigen Artikels schrieb ich:
In der Vergangenheit wurde ich immer von mindestens ein oder zwei Frameworks komplett überrascht, wie SwiftUI 2019, WidgetKit 2020 und DocC 2021. Was wird es dieses Jahr sein? Ich kann es kaum erwarten, es herauszufinden!
Nun, es war definitiv Swift Charts! Die neue, glänzende Bibliothek, die vielleicht nicht jede App sofort braucht, aber ich bin sicher, dass sie viele Entwickler inspirieren wird, Daten in ihren Apps zu visualisieren, um Nutzern einen besseren Überblick über ihre gesammelten Daten zu geben. Sie ist SwiftUI-only, also hatten noch nicht alle Teams die Möglichkeit, sie einzusetzen.
Die erste Version der Charts-Bibliothek wurde mit einer guten Auswahl an Diagrammtypen ausgeliefert, die alle gemeinsam haben, dass sie nur ein oder zwei gerade Achsen benötigen. Du kannst zum Beispiel bereits Liniendiagramme, Balkendiagramme und sogar Heatmaps zeichnen (und anpassen!). Jordi Bruin hat ein GitHub-Repo zusammengestellt mit Screenshots und Quellcode, das dir einen guten Überblick gibt, was heute schon möglich ist.
Aber als ich die Swift Charts-Bibliothek selbst für meine Open-Source-App Open Focus Timer verwenden wollte, die ich während meiner Livestreams auf Twitch entwickle, wollte ich den Nutzern ein Tortendiagramm zeigen, wie sich ihre Arbeitszeit auf verschiedene Projekte verteilt. Aber Tortendiagramme werden von der Charts-Bibliothek aktuell nicht unterstützt, genauso wenig wie Spinnendiagramme, Donut-Diagramme oder Sunburst-Diagramme. Ich finde aber, sie sind so verbreitet, dass sie alle in einer zweiten Version der Charts-Bibliothek dieses Jahr hinzugefügt werden sollten.
Und nächstes Jahr könnten vielleicht auch baumartige Diagramme hinzugefügt werden, die helfen könnten, professionelle Tools zu erstellen – z. B. zum Zeichnen eines UML-Diagramms der Model-Schicht einer App, zum Visualisieren von Datenstrukturen wie B-Bäumen oder zum Bauen interaktiver Zustandsmaschinen, die helfen könnten, Features auf einer abstrakteren Ebene zu verstehen. Ich habe genug Ideen, die solche Diagramme gut nutzen könnten!
#4: Streamer-Modus in Xcode zum Schwärzen von Code
Inhalte zu teilen ist eine tolle Sache. Es hilft nicht nur anderen, die den geteilten Inhalt konsumieren, etwas Neues zu lernen oder sich inspirieren zu lassen. Das Feedback kann auch dem Content Creator helfen, neue Aspekte zu entdecken, an die er noch nicht gedacht hat, wie subtile Bugs, UX-Probleme oder fehlende Barrierefreiheit. Aber wenn der zu teilende Inhalt mit einem Coding-Projekt zusammenhängt, kommen Sicherheits- und Geheimhaltungsbedenken ins Spiel.
Wenn man zum Beispiel ein Open-Source-Framework mit der Community teilt, das sich mit Drittanbieter-Services integriert, muss man sicherstellen, dass nie Test-Zugangsdaten ins Repository committed werden, da sie sonst leaken und missbraucht werden könnten. Genau in diese Situation bin ich mit SwiftPM für mein Open-Source-Tool BartyCrouch geraten – wie ich es gelöst habe, erkläre ich in diesem Artikel.
Und Secrets sind nicht der einzige Teil, den wir vor anderen verbergen wollen: Kein Unternehmen möchte, dass der Kernwert seiner Produkte, der viel Aufwand gekostet hat, an einen potenziellen Konkurrenten durchsickert. Nachahmer sind ein ernstes Problem, das Unternehmen zerstören kann. Die Lösung für Git-Repositories ist einfach genug: Wertvoller Code, der nicht leaken darf, muss Closed Source bleiben und nie mit Außenstehenden geteilt werden.
Foto von Kristina Flour / Unsplash
Aber Secrets aus einem Git-Repository zu verbergen oder Teile der Codebasis privat zu halten, ist nur ein Teil der Geschichte. Was ist mit Videocalls mit Freunden oder Fremden, die uns helfen wollen? Was ist mit Indie-Entwicklern (wie mir), die so viel wie möglich von ihrer Arbeit live streamen wollen? Es gibt so viele Situationen, in denen ich einfach meinen Bildschirm teilen und ein bestimmtes Problem oder eine Lösung direkt im Kontext meiner echten Anwendung zeigen möchte – aber ich tue es nicht. Das Risiko, versehentlich sensiblen Code zu leaken, ist für mich einfach zu hoch. Das führt zu vielen verpassten Möglichkeiten:
Als Indie-Entwickler würde ich gerne sogar die Entwicklung von Updates für meine Closed-Source-Apps live streamen, aber es gibt Teile, die ich nicht leaken möchte. Also streame ich nur meine Open-Source-Arbeit. Das ist echt schade.
Als Framework-Nutzer würde ich gerne Bugs oder Feature-Wünsche melden, indem ich schnell meinen Bildschirm aufnehme und ein Video der Nutzung im Kontext teile. Aktuell verzichte ich oft darauf, überhaupt etwas zu melden, weil mir die Vorbereitung einer Demo zu umständlich ist. Oder ich kopiere Teile des Codes aus dem Kontext und muss dann mehrere Fragen beantworten, um zu erklären, warum ich es genau so mache.
Als Teilnehmer eines wöchentlichen Entwickler-Austauschs spreche ich lieber auf einer abstrakten Ebene über Code, wenn ich auf Probleme stoße, anstatt meinen Bildschirm zu teilen und es im Detail zu zeigen. Und selbst wenn ich meinen Bildschirm doch teile, würde ich meinem Gegenüber niemals erlauben, meinen Bildschirm zu steuern (z. B. um mir schnell etwas zu zeigen). Ich weiß, ein Teil des Problems ist, dass ich Vertrauensprobleme habe – aber damit bin ich nicht allein.
Was ich mir also wünsche, ist eine Funktion in Xcode, um bestimmte Teile meiner Codebasis als „vertraulich” zu markieren, und wenn ich meinen Bildschirm teile, werden alle vertraulichen Teile auf dem geteilten Bildschirm ausgeblendet. So eine Funktion wird in Apps wie Discord üblicherweise „Streamer-Modus” genannt. Sie könnte auf verschiedene Weisen implementiert werden – so stelle ich mir das vor:
Die vertraulichen Inhalte könnten für den Streamer sichtbar bleiben, aber von Xcode hervorgehoben werden, damit der Streamer weiß, dass sie in geteilten Inhalten nicht erscheinen.
Das Markieren von Inhalten als „vertraulich” könnte auf verschiedenen Ebenen erfolgen, z. B. auf Dateiebene (alle Inhalte einer Datei werden geschwärzt), auf Typ-Ebene, auf Funktionsebene oder auf Variablenebene. Im letzteren Fall würden die gesamten Zeilen geschwärzt.
Die Namen der geschwärzten Inhalte könnten weiterhin sichtbar sein (Dateiname / Typname / Funktionsdeklaration / Variablenname) und nur ihre Bodies/Werte geschwärzt werden.
Die Namen aller als „vertraulich” markierten Inhalte könnten vor Bearbeitung gesperrt werden, um sicherzustellen, dass ein Umbenennen nicht vorübergehend deren Inhalte leakt.
Die Vertraulichkeitsmarkierungen könnten in einer Datei gespeichert werden, die in Git committed werden kann, sodass andere Entwickler im Team sie in ihren externen Calls ebenfalls nutzen könnten.
Der Streamer-Modus könnte automatisch aktiviert werden, wenn eine App gerade die Screen-Capturing-APIs nutzt, sodass der Entwickler nicht daran denken muss, den „Streamer-Modus” manuell einzuschalten. Das sollte sowohl für Videocalls (in FaceTime/Zoom etc.) als auch für Bildschirmaufnahmen (in OBS/QuickTime etc.) funktionieren.
Ich bin nicht sehr optimistisch, dass so eine Funktion es in Xcode schafft, da ich das Gefühl habe, dass das kein Problem ist, das von vielen Entwicklern häufig angesprochen wird. Es fühlt sich wie ein Nischenthema an. Aber meiner Meinung nach ist es eines dieser Features, von denen man nicht weiß, dass man sie vermisst hat, bis man sich daran gewöhnt hat – und dann möchte man sie nie wieder missen.
#5: AR/VR OS-Entwicklung mit einem iPhone
Tim Cook spricht öffentlich über das Potenzial von AR seit mindestens 2016. Unter der Annahme, dass er nicht über etwas sprechen würde, an dem Apple nicht schon mindestens ein ganzes Jahr geforscht hat, können wir sicher sagen, dass Apple seit mindestens 8 Jahren an AR-Produkten arbeitet. Das erste iPhone brauchte zweieinhalb Jahre Entwicklungszeit. Die erste Apple Watch brauchte drei Jahre Entwicklung. Während man also fragen könnte, warum wir Apples erstes AR-Gerät immer noch nicht bekommen haben, gehe ich einfach mal davon aus, dass wir dieses Jahr eines bekommen. Und ich nehme auch an, dass dieses neue Gerät mit einem eigenen Betriebssystem ausgeliefert wird – nennen wir es „AR/VR OS”.
Ich kann schon jetzt ein Problem für Entwickler absehen, wenn so ein Gerät angekündigt wird: Nicht jeder Entwickler wird sich sofort ein neues Gerät kaufen können. Manche wegen finanzieller Einschränkungen, manche weil Produkte der ersten Generation meist nicht gleich in allen Ländern verfügbar sind. In der Vergangenheit war das kein großes Problem. Es gibt Simulatoren für das iPhone, das iPad, die Apple Watch und sogar den Apple TV, die mit Xcode ausgeliefert werden. Zwar gibt es Einschränkungen (wie keine Kameraunterstützung), aber die meisten Apps können vollständig entwickelt und größtenteils auch getestet werden, ohne Probleme. Das liegt daran, dass all diese Geräte eines mit unserem Entwicklungsgerät, dem Mac, gemeinsam haben: Sie alle rendern eine virtuelle Oberfläche auf einem flachen Bildschirm.
Aber ein AR-Gerät ist anders: Per Definition „erweitert” es die Realität, was bedeutet, dass wir für die Entwicklung und das Testen einer nützlichen App Zugang zu einem Kamerafeed brauchen, damit wir etwas zum „Erweitern” haben. Apple könnte zwar einige virtuelle Beispielumgebungen zum Testen in einem AR/VR-Simulator bereitstellen, wie sie es bei der Standortsimulation getan haben, aber das wäre für viele Anwendungsfälle sehr einschränkend und kann auch nervig sein.
Was ich mir stattdessen wünsche, ist, dass Apple Entwicklern eine Möglichkeit bietet, die AR/VR OS-Entwicklung mit dem Kamerafeed eines verbundenen iPhones oder iPads zu testen. Das könnte auf Geräte mit einem LiDAR-Scanner beschränkt werden, wenn das eine technische Voraussetzung ist. Aber es sollte auch drahtlos funktionieren, da wir damit herumlaufen wollen, um unsere Features in verschiedenen Umgebungen zu testen. Die grundlegende Technologie dafür wurde bereits in Form von Continuity Camera ausgeliefert, das es erlaubt, ein iPhone als Webcam zu verwenden. Vielleicht war dieses Feature ja nur ein Nebenprodukt besagter Testfunktionen, die ursprünglich für das interne Team gebaut wurden, das am AR-Produkt arbeitete. Wer weiß? Das könnte ein Zeichen sein, dass es kommen wird.
Aber noch wichtiger: Warum ich optimistisch bin, dass wir irgendeine Möglichkeit zum Testen für AR/VR OS ohne das echte Gerät bekommen werden, ist, dass Apple ein Interesse daran hat, dass so viele Apps wie möglich das Gerät unterstützen. Und das bedeutet, es muss so einfach wie möglich sein, Anwendungen dafür zu entwickeln. Schließlich ist die Verfügbarkeit von (einzigartigen) Apps ein wichtiges Verkaufsargument jeder neuen Softwareplattform.
Wie steht es um den KI-Hype?
Ich wünsche mir zwar eine bessere Auto-Completion-Unterstützung in Xcode oder sogar einen virtuellen Coding-Assistenten, dem ich sagen kann, was ich möchte, und er schreibt den Code, damit ich nicht alles selbst tippen muss – aber ich glaube, wir sind noch nicht so weit. Ich habe mit ChatGPT experimentiert, aber es lag in 80 % der Fälle daneben, wenn ich nach Code fragte. Es verwendete nicht nur ständig veraltete APIs, sondern produzierte auch Code, der nicht kompilierte. Oft verstand es nicht einmal, was ich wollte.
Obwohl ein dediziertes Modell fürs Programmieren von Apple bessere Ergebnisse liefern könnte, glaube ich nicht, dass es etwas erreichen wird, das ich als „zuverlässig” bezeichnen würde. Und ich bin sicher, Apple weiß das. Sie werden so eine Funktion vielleicht in der Zukunft erforschen, aber ich hoffe, sie springen nicht auf den aktuellen Hype-Zug auf und bauen etwas Halbfertiges in Xcode ein. Ich bevorzuge Tools, auf die ich mich verlassen kann und die vorhersehbar sind. Ich glaube, das sieht Apple genauso. Aber die Technologie ist noch nicht so weit. Ich erwarte etwas Großes in diese Richtung frühestens nächstes Jahr, dieses Jahr vielleicht etwas Kleines, wenn überhaupt.
Fazit
Das sind also meine Top 5 Wünsche für die WWDC 2023. Stimmst du mir zu? Und was sind deine? Lass es mich wissen, indem du auf Twitter hier oder auf Mastodon dort kommentierst.