Das hat richtig gut funktioniert. Die zwei Modelle finden unterschiedliche Dinge. Claude ist besser in Synthese und Kommunikation. Codex liest genauer — es verfolgt Code-Pfade, prüft Edge Cases, erklärt nicht zu früh „fertig”. Sie ermitteln unabhängig voneinander, und genau das macht die Ergebnisse besser.

Aber das Hin-und-Her-Kopieren war furchtbar.

Links gingen verloren, Formatierungen zerfielen, aber das war nicht das eigentliche Problem. Das eigentliche Problem war, dass jede Übergabe von mir abhing. Output kopieren, in die andere Session einfügen, warten, zurückkopieren, wieder einfügen. Meine Aufmerksamkeit steckte in dieser Schleife fest, obwohl sie woanders viel nützlicher gewesen wäre. Das war der echte Schmerzpunkt — ein Workflow, der ohne mich nicht weiterlief.

Ich wollte den Workflow selbst gar nicht ändern. Ich wollte nur aufhören, der menschliche Nachrichtenbus zu sein.

Der Harness-Artikel, der alles bestätigt hat

Dann bin ich auf Anthropics Harness design for long-running application development gestoßen, erwähnt in einem YouTube-Video. Ich hab den ganzen Artikel gelesen, und er hat zwei Dinge gleichzeitig bewirkt.

Erstens hat er bestätigt, was ich schon erlebt hatte: eine separate Session die Arbeit unabhängig prüfen zu lassen — ohne den Anchoring Bias, der entsteht, wenn man selbst gebaut hat — liefert bessere Ergebnisse. Genau das hatte ich mit Claude und Codex gesehen.

Zweitens hat er diese Erfahrung in ein klareres System überführt. Ich hatte mich hauptsächlich auf den „anderes Modell”-Aspekt konzentriert. Der Artikel machte den „unabhängiger Evaluator”-Teil viel expliziter. Sogar eine andere Claude-Session hilft, wenn sie unabhängig genug ist. Die Trennung an sich ist das Entscheidende.

Und ehrlich gesagt ergibt das ja auch Sinn: Wenn die ursprüngliche Session den Code für falsch gehalten hätte, hätte sie ihn nicht so geschrieben. Es ist derselbe Vorteil, den Pair Programming schon immer hatte — ein zweites Augenpaar fängt auf, was das Gehirn des Autors ausblendet. Da unterscheiden sich diese LLMs gar nicht so sehr von uns.

Diese Kombination — bestätigt durch Erfahrung, dann geschärft durch den Artikel — war der Moment, in dem es Klick gemacht hat. Das war nicht nur eine persönliche Eigenart in meiner Arbeitsweise. Es schien allgemein nützlich zu sein. Also hab ich den Workflow in ein richtiges Plugin verwandelt und es TandemKit genannt.

Das Koordinationsproblem, das wirklich gelöst werden musste

Mein erster Entwurf hatte vier Top-Level-Sessions: Planner, Generator und zwei Evaluators — einer Claude, einer Codex. Sie koordinierten sich über einfache Textdateien. Wenn eine Session fertig war, schrieb sie eine Sync-Datei, und die andere wartete im Hintergrund, bis sich diese Datei änderte. In Claude hat das einwandfrei funktioniert. Aber Codex wollte einfach nicht zuverlässig warten. Egal was ich versuchte — verschiedene File-Watching-Ansätze, verschiedene Signaling-Mechanismen — Codex hat entweder verpasst, dass es dran war, oder das Warten komplett übersprungen.

Ich war beim fünften oder sechsten Workaround dafür, als ich entdeckt habe, dass OpenAI gerade ein offizielles Codex-Plugin für Claude Code veröffentlicht hatte — codex-plugin-cc. Claude konnte Codex jetzt intern aufrufen, die Antwort sehen und dieselbe Codex-Session später fortsetzen. Genau das, was ich brauchte.

Das hat den Claude-Codex-Austausch aber nicht unsichtbar gemacht. Alles wird weiterhin in Markdown-Dateien unter TandemKit/ geschrieben, eine Datei pro Runde. Die komplette Mission-History bleibt auf der Festplatte — jede Recherche, jeder Convergence-Austausch, jedes Evaluationsergebnis.

Dieses Archiv ist auch nützlich. Wenn Wochen später etwas Merkwürdiges auftaucht, liefert die Git-History nicht nur eine Commit-Message — sie liefert die ganze Konversation hinter dem Commit, sodass man tatsächlich nachvollziehen kann, warum eine Entscheidung getroffen wurde. Es ist auch super, um den Workflow selbst zu verbessern: Alte Missions durchzulesen ist oft der schnellste Weg zu erkennen, dass eine Regel in AGENTS.md oder einen lokalen Skill gehört.

Was sich geändert hat, war die Infrastruktur. Statt ein fragiles viertes Terminal zu jonglieren, ruft TandemKit jetzt einen persistenten Codex-Subagent on demand über codex-plugin-cc auf und setzt ihn fort, wann immer es einen weiteren unabhängigen Durchlauf braucht.

Was eine Mission eigentlich ist

Ich nutze KI-Agenten jetzt seit fast einem Jahr täglich, und eine Mission ist die Arbeitsgröße, bei der ich immer wieder lande: groß genug, um von separater Planung, Generierung und Evaluation zu profitieren, aber klein genug, dass das Ganze innerhalb eines Satzes von Sessions noch implementiert und vollständig verifiziert werden kann.

Wenn die Arbeit kleiner ist — ein schneller Einzeiler-Fix, ein kleines Refactoring, ein simples Umbenennen — nutze ich einfach direkt Claude Code. TandemKits Multi-Session-Schleife verbraucht mehr Tokens und mehr Aufwand, als so eine Änderung verdient.

Wenn die Arbeit größer ist, teile ich sie vorher auf. Da kommt PlanKit ganz natürlich ins Spiel: Es führt Ideen durch Ideas → Roadmap → Features → Missions. Wenn etwas den Status „Mission” erreicht, ist es kein vager Feature-Topf mehr — es ist bereits in ein session-großes Arbeitsstück zugeschnitten.

Eine aktuelle Mission in der Praxis

Ich wollte App Store Connect Localization-Support zu TranslateKit hinzufügen, meinem KI-gestützten Tool für App-Lokalisierung. Die Idee war simpel: Statt App-Metadaten manuell in App Store Connect zu pflegen, könnten Entwickler Namen, Untertitel, Beschreibungen und Keywords für alle ihre Lokalisierungen direkt in TranslateKit bearbeiten — synchronisiert über Apples API.

Das war zu groß für eine Mission. Also hab ich es in zwei aufgeteilt: eine Mission für die App Store Connect API-Anbindung — JWT-Authentifizierung, Credential-Handling, Metadaten abrufen, Metadaten aktualisieren — und eine Mission für die UI-Änderungen, um das Ganze in der App sichtbar zu machen. Datenschicht zuerst, UX-Schicht danach.

Beim Planen haben Claude und Codex Edge Cases aufgedeckt, die ich nicht durchdacht hatte. Zum Beispiel: Was passiert, wenn der User eine neue Sprache hinzufügen will, aber es noch keine neue App Store Connect Version gibt? Bereits veröffentlichte Versionen lassen sich nicht bearbeiten, also muss das System entscheiden — Änderungen lokal cachen, den User auffordern zuerst eine Version zu erstellen, oder anbieten plattformübergreifend automatisch eine zu erstellen.

Und wenn TandemKit eine neue Version anlegt, welche Nummer soll sie bekommen? In die History schauen und raten? Den User bitten eine einzutippen? Gängige Nächste-Version-Optionen zur Auswahl anbieten? Das sind Produktentscheidungen, keine Implementierungsdetails, und die gehören in die Spec, bevor auch nur eine Zeile Code existiert.

Bei der Evaluation der API-Mission hat Claude das Feature zunächst als bestanden markiert, weil der Happy Path funktionierte und die Tests für existierende Versionen grün waren. Codex verfolgte den weniger offensichtlichen Branch und fand die eigentliche Lücke: Wenn keine editierbare App Store Connect Version existierte, erstellte der Code zwar den neuen Version-Record, versuchte aber nie den Localization-Write im selben Flow erneut. Der „neue Sprache”-Pfad sah also erfolgreich aus, tat aber im Stillen nichts, bis der User nochmal Sync auslöste — genau die Art von Code-Path-Bug, die ein zweites Modell findet.

Der Fix war klein: den Write nach der Version-Erstellung erneut versuchen, Tests für diesen Branch hinzufügen. Aber ohne den zweiten Durchlauf wäre er durchgerutscht.

Drei Sessions, autonome Schleife

DU  -- Planung
  |
  `--> [1] Planner Session
             Claude ---------> Codex (Hintergrund)
              |    <- Findings - |
              `---- konvergieren ┘
                         |
                      Spec.md  <-- du genehmigst, bevor es weitergeht

DU  -- beide Sessions starten, dann zurücklehnen
  |
  |--> [2] Generator Session
  |          implementiert gegen Spec.md
  |          committet bei Meilensteinen
  |
  `--> [3] Evaluator Session
             Claude ---------> Codex (Hintergrund)
              |    <- Findings - |
              `---- konvergieren ┘
                         |
                 FAIL -> Generator behebt -> Schleife
                 PASS -> Review Briefing -> du

Der Planner ist der einzige interaktive Schritt. Sobald du Spec.md freigibst, laufen Generator und Evaluator eigenständig, bis du entweder ein FAIL zum Fixen oder ein PASS mit Review Briefing bekommst.

Wie Claude und Codex sich tatsächlich einigen

Der naheliegende Ansatz wäre Scoring: Beide Modelle bewerten die Arbeit, man mittelt die Scores, bestanden ab einem bestimmten Schwellenwert. Aber Scores verstecken Fehler. Eine 8/10 kann bedeuten, dass zwei kritische Kriterien komplett durchgefallen sind und der Rest okay war.

Deshalb evaluiert TandemKit Kriterium für Kriterium. Jedes Finding bekommt zwei Dimensionen:

• Agreement Level: agreed, partially agreed oder disputed

• Severity Level: HIGH, MEDIUM oder LOW

Claude und Codex ermitteln unabhängig und schreiben ihre Findings in Dateien. Dann liest Claude, was Codex gefunden hat, erstellt eine zusammengeführte Evaluation — behält bei, wo es übereinstimmt, erklärt wo es anderer Meinung ist — und Codex reviewt diesen Merge. Bei jeder Uneinigkeit werden die tatsächlichen Quelldateien nochmal gelesen, statt aus dem Gedächtnis zu argumentieren.

Die Convergence-Regel ist simpel: Die Schleife läuft weiter, bis keine HIGH- oder MEDIUM-Findings mehr in den Buckets „partially agreed” oder „disputed” übrig sind. Wenn dieselbe Meinungsverschiedenheit drei Runden überlebt, hört TandemKit auf zu iterieren und präsentiert dir beide Positionen.

Normalerweise 2–4 Runden.

Warum nicht Agent Teams

Du fragst dich vielleicht: Hat Claude Code nicht Agent Teams für genau das? Doch, aber Agent Teams braucht API-Billing — nicht in Claude Max enthalten — und kann kein Codex einbinden.

Wenn Claude Max dich schon 100+ $/Monat kostet, sind 20 $/Monat für ChatGPT Plus ein vernünftiger Aufschlag — du bekommst ein unabhängiges zweites Modell, plus Bildgenerierung für UI-Mockups, Icons und andere Grafiken, die Claude nicht erzeugt.

Alles ist Plain Text

Jede Recherche, jeder Convergence-Austausch, jede Evaluationsrunde wird als lesbare Datei in deinem Projekt gespeichert:

TandemKit/001-ConnectAPIClient/
├── Spec.md
├── Planner-Discussion/
│   ├── Claude-01.md    ← Claudes Recherche
│   ├── Codex-01.md     ← Codex' unabhängige Findings
│   └── Claude-02.md    ← konvergierter Plan
├── Generator/
│   └── Round-01.md
└── Evaluator/
    ├── Round-01.md     ← FAIL: Version erstellt, Lokalisierungs-Write nicht wiederholt
    └── Round-02.md     ← PASS

Einfach die Dateien öffnen und du kannst die gesamte Argumentationskette nachvollziehen.

Erste Schritte

Die README auf GitHub beschreibt den kompletten Setup-Ablauf und zeigt, wie die Sessions einander übergeben. Wenn das nach dem Workflow klingt, den du bisher von Hand zusammengestückelt hast, ist das der richtige Startpunkt:

Und ich bin ehrlich froh, dass Apple auf serverbasierte LLMs umgeschwenkt ist, statt nur auf lokale Modelle zu setzen. Nachdem ich inzwischen gesehen habe, wie großartig Claude Code mit dem richtigen Context Engineering sein kann, weiß ich, dass eine rein lokale Lösung Jahre gebraucht hätte, um brauchbare Qualität zu erreichen. Apple hat hier richtig entschieden, die ursprüngliche Swift-Assist-Idee zu verwerfen, aber sie hatten offensichtlich nicht genug Zeit, eine vollständige Lösung für das erste Release zu bauen. Als jemand, der dem Apple-Ökosystem für die Entwicklung treu ist, ist es frustrierend, solche offensichtlichen Lücken in einem potenziell großartigen Tool zu sehen. Zum ersten Mal in meiner 14-jährigen Entwicklerkarriere nutze ich Xcode also nicht mehr als meinen täglichen Begleiter.

Claude Code in Cursor fasst zusammen, welchen Kontext es dank Context Engineering hat.

Ich bin stattdessen dazu übergegangen, Claude Code in Cursors Terminal laufen zu lassen – so bekomme ich Cursors Editor-Awareness zusammen mit Claude Codes überlegenen Tools wie Websuche, Planungsmodus und dem großzügigen 5-Stunden-Nutzungsfenster. Ich setze voll auf das Chat-Interface und versuche, der KI durch umfangreiches Context Engineering (Richtlinien, Referenzdokumentation) beizubringen, wie sie guten Code schreibt. Xcodes KI-Integration hingegen – obwohl vielversprechend durch die native IDE-Position – fehlen grundlegende Features, die diese Art von KI-getriebenem Entwickeln produktiv machen.

Hier ist, was mich davon abhält, zurück zu Xcode zu wechseln.

Die 7 fehlenden Features in Xcode AI

1. Request-Queuing war die erste Einschränkung, die mir in Xcode sofort aufgefallen ist. Beim Entwickeln wechseln die Gedanken und Fragen schnell. Auf jede Antwort warten zu müssen, unterbricht meinen Rhythmus komplett. Eine der besten Möglichkeiten, bei der Arbeit mit KI Zeit zu sparen, ist vorauszudenken, während man wartet. Sowohl Cursor als auch Claude Code lassen mich nahtlos Anfragen anreihen und halten mich im Flow. Xcode blockiert einfach jede Eingabe.

Xcode 26 blockiert neue Chat-Eingaben, während die vorherige verarbeitet wird.

2. Context-Engineering-Unterstützung ist der Bereich, in dem Xcode komplett versagt. Es gibt keine Unterstützung für Kontextdateien wie .cursorrules oder CLAUDE.md. Ohne automatisches Laden von Kontext ist all die Arbeit, die ich in Context Engineering gesteckt habe – der KI meine Coding-Standards, Architekturmuster, Fehlerbehandlungsansätze und mehr beizubringen – in Xcode schlicht nicht möglich. Ich muss meine Richtlinien in jeder Unterhaltung aufs Neue erklären. Claude Code und Cursor laden automatisch meine übergeordneten Richtlinien und verstehen dann, wann welche detailliertere Richtlinie gelesen werden muss. Das verwandelt KI von einem generischen Code-Generator in einen tatsächlich nützlichen Assistenten. In Xcode leider nicht.

Der Coding Assistant teilt mir mit, dass es keine Möglichkeit gibt, ihm etwas über mein Projekt oder meine Richtlinien beizubringen.

3. Build-Validierung zeigt, dass Xcode nicht für KI-getriebene Entwicklung konzipiert wurde. Die KI kann ihre eigenen Codeänderungen nicht durch Builds validieren und hat nicht mal Zugriff auf die Build-Ausgabe, wenn ich sie selbst starte. Sie kann nicht mal die Konsolenausgabe lesen, wenn ich sie explizit darum bitte. Klar, Xcode erlaubt es, nach dem Build einen Fehler auszuwählen und die KI um eine Korrektur zu bitten – aber das ist für einen anderen Workflow gedacht. Es ist nur nützlich, wenn man selbst Code schreibt und einen Fehler macht, was selten vorkommt. Aber wenn die KI Code für mich schreibt? Build-Fehler treten ständig auf. Selbst bauen und dann manuell auf “Beheben” klicken zu müssen, ist super nervig. Die KI sollte einfach selbst bauen und die Fehler sehen können. Mit Claude Code lasse ich es einfach xcodebuild ausführen und die KI sieht alle Fehler sofort. Sie fragt mich zwar um Erlaubnis, aber wenn ich zustimme, kann sie iterieren, beheben und neu bauen, bis alles kompiliert – ohne manuelles Eingreifen.

Der Coding Assistant teilt mir mit, dass er die Konsolenausgabe nicht lesen kann.

4. Git-Integration fehlt komplett – kein Durchsuchen der History, kein Vergleichen von Versionen, keine automatisierten Commits nach meinen Richtlinien. Ich kann der KI nicht sagen, sie soll meinen aktuellen Code mit einer früheren Version vergleichen, um Dokumentationsdateien basierend auf den letzten Änderungen zu aktualisieren, oder funktionierenden Code aus früheren Commits zurückholen. Claude Code kann meine Git-History durchsuchen, funktionierenden Code aus früheren Commits wiederherstellen und ordentlich formatierte Commits erstellen, indem es die tatsächlichen Änderungen analysiert und eine passende Nachricht findet, die meinen Commit-Richtlinien folgt. Es kann sogar helfen, Dokumentation zu aktualisieren, indem es vergleicht, was sich seit der letzten Version geändert hat.

Der Coding Assistant teilt mir mit, dass er nicht auf die Git-History zugreifen kann.

5. Terminal- und CLI-Zugriff ist die größte Lücke. Kein Kommandozeilenzugriff bedeutet kein swift-format, keine eigenen Skripte, keine Automatisierung. Als Indie-Entwickler, der viele Aufgaben gleichzeitig jongliert, ist das eine ernsthafte Einschränkung. Ich kann der KI nicht beibringen, vor einem Commit einen Code-Formatter auszuführen, kann sie nicht meine Test-Suites starten lassen und keine der eigenen Skripte ausführen, die meinen Entwicklungsprozess beschleunigen. Claude Code führt jeden Terminal-Befehl aus, den ich brauche. Es formatiert Code vor Commits, führt meine Test-Suites aus, startet Deployment-Skripte, verwaltet Abhängigkeiten und übernimmt meinen gesamten Automatisierungs-Workflow. Ein einziges Terminal-Tool gibt Zugriff auf alles – git, xcodebuild, Paketmanager, was auch immer. Moderne KI kann das!

❇️ Wenn Apple allein den Terminal-Zugriff hinzufügen würde, wären die obigen Punkte 3 und 4 ebenfalls gelöst! Natürlich ist voller Kommandozeilenzugriff riskant. Aber Claude Code löst das elegant, indem es beim ersten Mal um Erlaubnis fragt und eine Allow- & Deny-Liste in einer einfachen Konfigurationsdatei unterstützt.

6. Projektdatei-Einschränkungen zeigen, dass Xcode nicht für moderne KI-Context-Engineering-Workflows ausgelegt ist. Viele Projekte erstrecken sich über mehrere Repositories – wie TranslateKit mit seiner App, dem Server und den Open-Source-Paket-Komponenten. Meine Context-Engineering-Richtlinien liegen im übergeordneten Ordner, der kein Xcode-Projekt enthält, und trotzdem brauche ich KI-Zugriff darauf über alle Komponenten hinweg. Wenn ich einen Ordner in Xcode ziehe, um ihn im Editor zu öffnen, bekomme ich nur einen Fehler. Xcode kann nur einzelne Textdateien, Xcode-Projekte oder Swift-Package-Manifestdateien öffnen – aber keine beliebigen Ordner. Außerdem werden Dotfiles versteckt, sodass ich Dinge wie GitHub Actions Workflows nicht sehen oder bearbeiten kann. Cursor dagegen öffnet jeden Ordner, zeigt versteckte Dateien an und funktioniert über meine gesamte Multi-Repo-Entwicklungsumgebung hinweg. Das sollte Xcode auch können!

Der Fehlerdialog, wenn ich versuche, einen beliebigen Ordner in Xcode zu öffnen.

7. Websuche und Dokumentationszugriff fehlen ebenfalls komplett. Die KI kann nicht mal in Xcodes eigenen heruntergeladenen Dokumentationsdateien suchen. Wenn ich aktuelle Informationen oder API-Referenzen brauche, bin ich auf mich allein gestellt. Claude Code hat eine eingebaute Websuche. Wenn ich nach den neuesten Swift-Evolution-Proposals oder neuen APIs frage, die auf der WWDC25 vorgestellt wurden, findet es einfach die Antwort. In Xcode 26 nicht.

Nach den neuen Frameworks gefragt, die Apple 2025 eingeführt hat, halluziniert es zu 100 %.

Diese sieben Einschränkungen ergeben zusammen ein grundlegendes Problem: Xcodes KI fühlt sich an wie eine Tech-Demo und nicht wie ein Produktivitäts-Tool. Jedes fehlende Puzzleteil zwingt mich zurück in manuelle Workflows, die Claude Code nahtlos erledigt.

Mein Fahrplan für Apple: 5 Release-Meilensteine

So könnte Apple diese Lücken schließen und mich 2026 zurück zu Xcode bringen:

Xcode 26.1 (Oktober 2025): Fügt Request-Queuing und Kontextdatei-Unterstützung hinzu (z. B. Xcode.md). Diese Features sollten einfach zu implementieren sein und kein Risiko unerwünschter Nebeneffekte haben.

Xcode 26.2 (Dezember 2025): Spezifische Tool-Integrationen für git, xcodebuild und swift-format. Da diese alle in Xcode integriert oder Apple-Technologien sind, können Apple-Ingenieure ihre bestehende Erfahrung nutzen, um diese Tools der KI mit sicheren, konservativen Aktionen bereitzustellen.

Xcode 26.3 (März 2026): Websuche, Integration der neuesten Dokumentation und Öffnen beliebiger Ordner mit Zugriff auf versteckte Dateien. Diese Integrationen sind alle risikoarm, brauchen aber Zeit, um sie richtig umzusetzen.

Xcode 26.4 (Mai 2026): Voller Terminal-Zugriff mit befehlsspezifischen Allow-/Deny-Listen.

Ich verstehe Apples Sicherheitsbedenken, aber Entwickler können mit der Verantwortung umgehen. Vertraut uns die Tools an, die wir brauchen, Apple, bitte!

Xcode 27 (September 2026, angekündigt auf der WWDC 26): Features, “die nur Apple bieten kann”, wie tiefe Simulator-Integration (stell dir vor, die KI navigiert durch deine App, um zu testen, ob ihre Änderungen wie erwartet funktioniert haben), oder SwiftUI-Preview-Zugriff (damit die KI sehen kann, wie ihr UI-Code aussieht). Vielleicht sogar ein “App Builder”-Modus, der SwiftUI zu einem sekundären Artefakt macht und App-Entwicklung einem ganz neuen Publikum zugänglich macht. Hier könnte Apple uns mit etwas überraschen, das wir nicht haben kommen sehen. Nicht nur “aufholen”, sondern die Konkurrenz wirklich übertreffen.

Das Fazit

Ich habe Xcode immer geliebt und möchte es ehrlich wieder exklusiv nutzen. Apple hat einzigartige Vorteile, die kein Wettbewerber bieten kann – nahtlose IDE-Integration, Simulator-Steuerung, SwiftUI-Preview-Funktionen. Aber im Moment ist Claude Code dramatisch leistungsfähiger, mit einem 5-fachen Produktivitätsunterschied. Aufgaben, die in Xcode Stunden dauern, erledigt Claude Code in Minuten – hauptsächlich weil es für einfache Dinge wie “Build drücken” nicht von mir abhängt.

Apple muss sich beeilen. Mit jedem Tag, der vergeht, etablieren mehr Entwickler tiefe Workflows mit anderen Tools. Ich werde jedes Point-Release gespannt verfolgen, und sobald Xcodes KI konkurrenzfähig wird, bin ich der Erste, der zurückkehrt. Bis dahin halte ich Claude Code in meinem Terminal offen und träume von dem Tag, an dem Xcode mich wieder umhauen wird und den Wandel zu einer AI-first-IDE schafft.

Wie sind eure Erfahrungen mit Xcodes KI-Integration? Habt ihr Workarounds für diese Einschränkungen gefunden, oder nutzt ihr auch Alternativen?

1. Foundation Models: On-Device-KI

Der größte Gamechanger dieses Jahr ist Foundation Models – Apples On-Device-KI-Framework, das leistungsfähige 3-Milliarden-Parameter-Modelle direkt in deine Apps bringt. Was macht das so besonders?

• Privacy-first: Alles läuft auf dem Gerät, ohne Server-Verzögerungen

• Strukturierter Output: Mit dem @Generable-Macro lassen sich typisierte Antworten garantieren

• Tool Calling: Die KI kann automatisch mit den Funktionen deiner App interagieren

• Teilergebnisse: Aktualisiere deine UI, während Antworten in Echtzeit generiert werden

Verwandte Sessions

• Meet the Foundation Models framework

• Deep dive into the Foundation Models framework

• Explore prompt design & safety for on-device foundation models

• Bring on-device AI to your app using Foundation Models

2. Xcode bekommt ChatGPT-Integration

Apple hat alle überrascht, indem sie ChatGPT direkt in Xcode integriert haben – statt des angekündigten Swift Assist. Das bringt:

• Native KI-Unterstützung mit Code-Generierung und Dokumentation

• Unterstützung für mehrere KI-Anbieter (ChatGPT, Claude, lokale Modelle)

• Git-ähnliche History für KI-Änderungen, um Änderungen einfach rückgängig zu machen

• Kontextbezogene Code-Vorschläge (wie Dokumentieren, Erklären usw.)

Das #Playground-Macro revolutioniert außerdem das Debugging – erstelle SwiftUI-Preview-artige Playgrounds für jeden Datentyp, nicht nur für Views. Ideal für Prompt Engineering!

Verwandte Sessions

• What’s new in Xcode

• Optimize SwiftUI performance with Instruments

• Record, replay, and review: UI automation with Xcode

3. SwiftUI WebView ist endlich da

Nach Jahren voller Wünsche ist WebView jetzt nativ in SwiftUI verfügbar:

WebView(url: URL(string: "https://swift.org")!)

Zusammen mit dem neuen WebPage-Typ für erweiterte Steuerung – einschließlich JavaScript-Ausführung und Scroll-Synchronisation. Das eröffnet hybride App-Erlebnisse, die vorher komplex umzusetzen waren und UIKit/AppKit-Bridging erforderten.

Verwandte Sessions

• Meet WebKit for SwiftUI

• What’s new in SwiftUI

• What’s new in Safari and WebKit

• What’s new for the spatial web

4. AlarmKit: Drittanbieter-Wecker-Apps

AlarmKit durchbricht Fokus-Modi und Systemeinschränkungen und ermöglicht:

• Echte Wecker-Apps, die Nutzer tatsächlich aufwecken können

• Live-Activities-Integration (erforderlich) für Schlummerfunktionalität

• Eigene Wecktöne und individuelle Erlebnisse

• Perfekt für Timer-, Wecker- und Gebets-/Medikamenten-Erinnerungs-Apps

Verwandte Session

• Wake up to the AlarmKit API

5. App Store Connect: Analytics-Rundumerneuerung

App Store Connect bekommt ein großes Upgrade:

• Monthly Recurring Revenue (MRR) endlich verfügbar

• Neue Analytics-APIs für Drittanbieter-Tools

• Angebotscodes für Nicht-Abo-Produkte (auf allen Plattformen)

• Verbesserte Navigation – Analytics ist jetzt in die einzelnen Apps integriert

Verwandte Sessions

• What’s new in App Store Connect

• Optimize your monetization with App Analytics

• What’s new in StoreKit and In-App Purchase

• Automate your development process with the Connect API

6. visionOS: Räumliche Revolution

Große Verbesserungen bei visionOS:

• Persistenz: Widgets, Fenster und Volumes bleiben zwischen Sitzungen angeheftet

• Nearby Sharing: Geteilte Multi-User-Erlebnisse im selben Raum

• APMP-Unterstützung: Support für 180°-, 360°- und Wide-FOV-Spatial-Video

• Verbesserte SwiftUI-3D-Layout-Tools, die die Entwicklung erleichtern

• Swift Charts 3D: Dreidimensionale Datenvisualisierung für räumliche Apps

Verwandte Sessions

• What’s new in widgets

• What’s new in visionOS 26

• Explore video experiences for visionOS

• Bring Swift Charts to the third dimension

7. Swift 6: Concurrency wird zugänglich

Approachable Concurrency löst die Adoptionsprobleme von Swift 6:

• Standard-@MainActor-Isolation reduziert Warnungen

• Schrittweises Opt-in zu Concurrency mit @concurrent

• Macht die Swift-6-Migration für bestehende App-Projekte endlich realistisch

Verwandte Sessions

• What’s new in Swift

• Embracing Swift concurrency

• Elevate an app with Swift concurrency

8. Wi-Fi Aware: Mehr als Bluetooth

Wi-Fi Aware ermöglicht Erlebnisse wie AirPlay/AirDrop:

• Leistungsstarke lokale Kommunikation

• Größere Reichweite als Bluetooth, plattformübergreifender Standard

• Unterstützung für mehr gleichzeitige Verbindungen (ähnlich wie bei AirPods)

• Perfekt für Media-Streaming und Multiplayer-Erlebnisse

Verwandte Session

• Supercharge device connectivity with Wi-Fi Aware

9. String Catalog-Verbesserungen

Lokalisierung wird genauer und flexibler:

• KI-generierte Kommentare für Übersetzungskontext

• String Symbols mit Auto-Completion (für manuelle Strings)

• Mehrfachauswahl für Massenaktualisierungen (einschließlich neuer Refactoring-Funktion)

Verwandte Sessions

• Explore localization with Xcode

10. Icon Composer & Layered Icons

Die neue Icon Composer-App erstellt:

• Geschichtete Icons mit bis zu 4 Ebenen und eingebauten Effekten

• Vorschau aller Icon-Stile (einschließlich des umstrittenen “Clear”-Stils)

• Einheitliches .icon-Dateiformat zum Ablegen in Xcode

• Kann auch flache Bilder für Marketingzwecke exportieren

Verwandte Sessions

• Create icons with Icon Composer

• Say hello to the new look of app icons

• Meet Liquid Glass

• Get to know the new design system

Schau dir die vollständige Analyse an

Dieser Artikel deckt nur einen kleinen Teil der neuen APIs ab, aber es gibt noch so viel mehr in meiner umfassenden Video-Analyse zu entdecken. Ich gehe alles Interessante durch und teile meine Einschätzung, was für deine Apps am wichtigsten sein wird:

Was wollt ihr am liebsten in euren Apps umsetzen? Lasst es mich in den Kommentaren auf YouTube oder auf anderen Kanälen wissen (Links unten)!

In diesem Beitrag teile ich die Grundlage, die ich für verbesserte Fehlerbeschreibungen geschaffen habe, und lade dich ein, gemeinsam mit mir ein umfassendes Wörterbuch benutzerfreundlicher Fehlermeldungen für Swift-Entwickler zu erstellen.

Das Problem mit System-Fehlermeldungen

Schauen wir uns ein paar reale Beispiele unhilfreicher System-Fehlermeldungen an:

// Dateisystem-Fehler
"The file couldn't be opened because it doesn't exist."
// Bessere Meldung: "The file 'report.pdf' could not be found. Please verify the file name and location."

// Core Data-Fehler
"The operation couldn't be completed. (Cocoa error 133000.)"
// Bessere Meldung: "The database has a validation error. One or more required fields are empty or have invalid values."

Diese Standard-Meldungen haben mehrere Probleme:

1. Sie sind oft zu technisch für Endnutzer

2. Ihnen fehlt der Kontext, was gerade versucht wurde

3. Sie bieten selten Vorschläge, wie sich das Problem lösen lässt

4. Sie sind manchmal schlicht falsch oder irreführend

5. Sie können Implementierungsdetails preisgeben, die Nutzer gar nicht sehen sollten

Apple hat tausende Fehlercodes über Dutzende Frameworks verteilt, und viele davon existieren seit Jahrzehnten. Neuere APIs wurden zwar verbessert, aber viele ältere Frameworks liefern nach wie vor Meldungen, die für Entwickler gedacht sind – nicht für Nutzer.

Die Lösung: Community-kuratierte Fehlerzuordnungen

ErrorKit stellt eine Funktion namens userFriendlyMessage(for:) bereit, die System-Fehler auf hilfreichere Meldungen abbildet:

do {
    let data = try Data(contentsOf: url)
    // Daten verarbeiten...
} catch {
    // Statt die Standard-Meldung anzuzeigen
    // showAlert(error.localizedDescription)

    // Eine verbesserte Meldung anzeigen
    showAlert(ErrorKit.userFriendlyMessage(for: error))
}

Unter der Haube analysiert diese Funktion den Fehler und gibt eine bessere Beschreibung zurück, basierend auf einer wachsenden Sammlung bekannter Fehlertypen:

// Beispiel aus ErrorKits Implementierung
enum FoundationErrorMapper: ErrorMapper {
    static func userFriendlyMessage(for error: Error) -> String? {
        let nsError = error as NSError

        // URL-Ladefehler
        if nsError.domain == NSURLErrorDomain {
            switch nsError.code {
            case NSURLErrorNotConnectedToInternet:
                return String(localized: "You are not connected to the Internet. Please check your connection.")
            case NSURLErrorTimedOut:
                return String(localized: "The request timed out. Please try again later.")
            // Viele weitere Fälle...
            }
        }

        // Dateisystem-Fehler
        if nsError.domain == NSCocoaErrorDomain {
            switch nsError.code {
            case NSFileNoSuchFileError:
                return String(localized: "The file could not be found.")
            // Viele weitere Fälle...
            }
        }

        // Weitere Domains und Fehlercodes...

        return nil // Fallback auf Standard-Behandlung
    }
}

Aktuelle Abdeckung und Beispiele

ErrorKit enthält Zuordnungen für häufige Fehler in wichtigen Apple-Frameworks:

Foundation

• Netzwerk: NSURLErrorNotConnectedToInternet → “Your device isn’t connected to the internet. Please check your connection and try again.”

• Dateisystem: NSFileNoSuchFileError → “The file ‘report.pdf’ could not be found. Please verify the file name and location.”

Core Data

• Validierung: NSValidationErrorMinimum → “The database failed validation. Please check your inputs and try again.”

• Store-Verwaltung: NSPersistentStoreCoordinatorError → “Database error. This might be due to a recent app update or file corruption.”

MapKit

• Wegbeschreibungen: MKErrorDirectionsNotFound → “No directions found for the requested route.”

• Standort: MKErrorLocationUnknown → “Current location unavailable. Please check location permissions.”

Warum wir eine gemeinschaftliche Antwort brauchen

In einer idealen Welt würde Apple all seine verwirrenden Fehlermeldungen fixen. Und fairerweise muss man sagen: Sie haben einiges verbessert – neuere Frameworks wie SwiftUI sind deutlich klarer. Aber Jahrzehnte von Legacy-APIs liefern eben immer noch kryptische, technische Meldungen, die wohl nie wieder angefasst werden.

Genau hier kann unsere Community einen echten Unterschied machen. Kein einzelner Entwickler hat jeden obskuren Fehler gesehen – aber zusammen haben wir die meisten davon erlebt. Indem wir teilen, was wir bereits herausgefunden haben, und diese Meldungen in verständliche Sprache umschreiben, können wir eine Ressource schaffen, die allen Zeit spart und die Erfahrung für Entwickler und Nutzer gleichermaßen verbessert.

So kannst du beitragen

Wenn du schon mal eine System-Fehlermeldung umgeschrieben hast, um sie hilfreicher zu machen, machst du die Arbeit ja bereits – jetzt kannst du sie teilen. Hier sind die 3 grundlegenden Schritte:

1. Eine schlechte Meldung entdecken Notiere die Error-Domain und den Code, die Operation, die den Fehler ausgelöst hat, sowie nützliche Infos aus dem userInfo-Dictionary.

2. Eine bessere Version schreiben Verwende verständliche Sprache. Sei konkret. Biete einen hilfreichen nächsten Schritt an, wenn es Sinn ergibt.

3. Auf GitHub einreichen Eröffne einen Pull Request oder ein Issue im ErrorKit-Repo mit deiner verbesserten Meldung, dem ursprünglichen Kontext und eventuellen Anmerkungen.

Selbst kleine Beiträge können tausenden Entwicklern helfen und die Nutzererfahrung für Millionen verbessern!

Über Apple-Frameworks hinaus: Fehler beliebiger Libraries mappen

Während Apple-Frameworks der Hauptfokus sind, funktioniert ErrorKits Fehlerzuordnungssystem mit jedem Fehlertyp. Das ErrorMapper-Protocol ermöglicht es Entwicklern, eigene Zuordnungen für Third-Party-Libraries zu erstellen:

// Beispiel-Mapper für Alamofire-Netzwerkfehler
enum AlamofireErrorMapper: ErrorMapper {
    static func userFriendlyMessage(for error: Error) -> String? {
        switch error {
        case let afError as Alamofire.AFError:
            switch afError {
            case .sessionTaskFailed(let underlying):
                if let urlError = underlying as? URLError {
                    switch urlError.code {
                    case .notConnectedToInternet:
                        return String(localized: "Your device isn't connected to the internet. Please check your connection and try again.")
                    case .timedOut:
                        return String(localized: "The server took too long to respond. Please try again later.")
                    default:
                        return nil
                    }
                }
                return nil
            case .responseValidationFailed(let reason):
                if case .unacceptableStatusCode(let code) = reason {
                    return String(localized: "The server returned error \(code). Please check your request or try again later.")
                }
                return nil
            default:
                return nil
            }
        default:
            return nil
        }
    }
}

// Für sofortige Verwendung registrieren
ErrorKit.registerMapper(AlamofireErrorMapper.self)

Diese Erweiterbarkeit eröffnet Möglichkeiten für:

• Eigene Zuordnungen in deiner App für beliebte Libraries wie Alamofire

• Mapper-Packages für Closed-Source-SDKs wie Stripe, Admob usw.

• Teilen von Fehlerzuordnungen innerhalb von Teams oder Organisationen

Fazit

Fehlermeldungen haben einen erheblichen Einfluss auf die Nutzererfahrung, werden in der Entwicklung aber oft übersehen. ErrorKits userFriendlyMessage(for:)-Funktion schafft einen Rahmen, um das durch Community-Zusammenarbeit zu ändern – eine Zusammenarbeit, bei der Entwickler ihr Wissen bündeln, um das gesamte Swift-Ökosystem benutzerfreundlicher zu machen.

Wenn du schon mal kryptische Fehlermeldungen entschlüsselt hast, ist deine Erfahrung wertvoll. Indem du zu ErrorKit beiträgst, kannst du diese Probleme nicht nur für dich selbst lösen, sondern für jeden Swift-Entwickler, der vor denselben Herausforderungen steht. Schau dir ErrorKit an und teile deine Lösungen, um diese Community-Ressource aufzubauen:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Seid ihr schon auf kryptische Fehlermeldungen in Apple-Frameworks gestoßen? Habt ihr sie für euch hilfreicher gemacht? Schreibt mir auf den sozialen Kanälen (Links unten)!

Vorherige Artikel in dieser Serie:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

2. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

3. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

Wenn du schon mal eine iOS-App supportet hast, kennst du dieses frustrierend vage Nutzerfeedback. Keine Schritte zum Reproduzieren, keine Fehlermeldung, kein Kontext – nur das gefürchtete “geht nicht”, das dich mit mehr Fragen als Antworten zurücklässt.

Selbst die detailorientiertesten Nutzer wissen selten, welche Informationen du zur Diagnose brauchst. Und wenn sie doch versuchen zu helfen, fehlt ihnen oft das technische Wissen, um die richtigen Details zu liefern. Diese Diskrepanz erzeugt eine frustrierende Erfahrung für alle Beteiligten.

In diesem Beitrag stelle ich zwei praktische Ansätze vor, die ich in ErrorKit implementiert habe, um diese Lücke zu schließen: einen einfachen Feedback-Button, der automatisch Diagnose-Logs sammelt, und einen strukturierten Ansatz für Error-Analytics, der dir hilft, Muster zu erkennen – auch ohne direkte Nutzerberichte.

Das Problem des fehlenden Kontexts

Wenn Nutzer auf Probleme stoßen, erschweren mehrere Herausforderungen die Diagnose:

1. Sie wissen nicht, welche Informationen du brauchst

2. Sie können nicht einfach auf System-Logs zugreifen

3. Sie können sich nur schwer an die genauen Schritte erinnern und diese formulieren

4. Komplexe Probleme können mehrere Komponenten betreffen

5. Sporadische Probleme sind schwer auf Abruf reproduzierbar

Ohne richtigen Kontext wird Debugging zum Ratespiel. Du verbringst womöglich Stunden mit dem Reproduzieren eines Problems, das mit den richtigen Informationen in Minuten gelöst wäre.

Lösung 1: Feedback-Button mit angehängten Logs

Die erste Lösung macht es Nutzern extrem einfach, dir vollständige Informationen zu schicken. ErrorKit bietet einen SwiftUI-Modifier, der einen Mail-Composer mit automatischer Log-Sammlung hinzufügt:

struct ContentView: View {
    @State private var showMailComposer = false

    var body: some View {
        VStack {
            // Dein App-Inhalt

            Button("Report a Problem") {
                showMailComposer = true
            }
            .mailComposer(
                isPresented: $showMailComposer,
                recipient: "support@yourapp.com",
                subject: "YourApp Bug Report",
                messageBody: """
                   Please describe what happened:



                   ----------------------------------
                   Device: \(UIDevice.current.model)
                   iOS: \(UIDevice.current.systemVersion)
                   App version: \(Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? "Unknown")
                   """,
                attachments: [
                    try? ErrorKit.logAttachment(ofLast: .minutes(30))
                ]
            )
        }
    }
}

Das erstellt einen einfachen “Problem melden”-Button, der:

1. Einen vorausgefüllten E-Mail-Composer öffnet

2. Geräte- und App-Informationen enthält

3. Automatisch aktuelle System-Logs anhängt

4. Platz für den Nutzer bietet, das Problem zu beschreiben

Der Log-Anhang ist hier das Geheimrezept. Wenn der Nutzer diesen Button nach einem Problem antippt, bekommst du ein umfassendes Bild davon, was in und um deine App passiert ist, als das Problem auftrat.

Apples Unified Logging System nutzen

ErrorKit verwendet Apples Unified Logging System (OSLog/Logger), um Diagnose-Informationen zu sammeln. Falls du noch kein strukturiertes Logging nutzt, hier eine kurze Einführung:

import OSLog

// Logger erstellen
let logger = Logger()
// oder mit Subsystem und Kategorie
let networkLogger = Logger(subsystem: "com.yourapp", category: "networking")

// Auf passenden Ebenen loggen
logger.debug("Detailed connection info")      // Entwickler-Debugging
logger.info("User tapped submit button")      // Allgemeine Informationen
logger.notice("Profile successfully loaded")   // Wichtige Ereignisse
logger.error("Failed to load user data")      // Fehler, die behoben werden sollten
logger.fault("Database corruption detected")   // Systemausfälle

// Werte formatieren und Datenschutz steuern
logger.info("User \(userId, privacy: .private) logged in from \(ipAddress, privacy: .public)")

Das Unified Logging System bietet mehrere Vorteile gegenüber print()-Anweisungen:

• Log-Level zum Filtern von Informationen

• Datenschutzkontrollen für sensible Daten

• Effiziente Performance mit minimalem Overhead

• Persistenz über App-Neustarts hinweg

Umfassende Log-Sammlung

Ein zentraler Vorteil von ErrorKits Ansatz ist, dass nicht nur die Logs deiner App erfasst werden, sondern auch relevante Logs von:

1. Third-Party-Frameworks, die Apples Unified Logging System nutzen

2. Systemkomponenten, mit denen deine App interagiert (Netzwerk, Dateisystem usw.)

3. Hintergrundprozessen, die mit der Funktionalität deiner App zusammenhängen

Das gibt dir ein vollständiges Bild davon, was in und um deine App passiert ist, als das Problem auftrat – nicht nur die Logs, die du explizit hinzugefügt hast.

Log-Sammlung steuern

Du kannst die Log-Sammlung anpassen, um Detail und Datenschutz auszubalancieren:

// Logs der letzten 30 Minuten ab Notice-Level sammeln (Standard)
try ErrorKit.logAttachment(ofLast: .minutes(30), minLevel: .notice)

// Logs der letzten Stunde ab Error-Level sammeln (weniger ausführlich)
try ErrorKit.logAttachment(ofLast: .hours(1), minLevel: .error)

// Logs der letzten 5 Minuten ab Debug-Level sammeln (sehr detailliert)
try ErrorKit.logAttachment(ofLast: .minutes(5), minLevel: .debug)

Der minLevel-Parameter filtert Logs nach Wichtigkeit:

• .debug: Alle Logs (sehr ausführlich)

• .info: Informative Logs und darüber

• .notice: Bemerkenswerte Ereignisse (Standard)

• .error: Nur Fehler und Ausfälle

• .fault: Nur kritische Fehler

Das gibt dir Kontrolle darüber, wie viel Information du sammelst, während du trotzdem den nötigen Kontext für die Diagnose erhältst.

Alternative Methoden für mehr Kontrolle

Wenn du mehr Kontrolle über die Log-Verarbeitung brauchst, bietet ErrorKit zusätzliche Ansätze:

Log-Daten direkt abrufen

Um Logs an dein eigenes Backend zu senden oder sie in der App zu verarbeiten, verwende loggedData:

let logData = try ErrorKit.loggedData(
    ofLast: .minutes(10),
    minLevel: .notice
)

// Die Daten mit deinem eigenen Reporting-System verwenden
analyticsService.sendLogs(data: logData)

In eine temporäre Datei exportieren

Um Logs über andere Mechanismen zu teilen, verwende exportLogFile:

let logFileURL = try ErrorKit.exportLogFile(
    ofLast: .hours(1),
    minLevel: .error
)

// Die Log-Datei teilen
let activityVC = UIActivityViewController(
    activityItems: [logFileURL],
    applicationActivities: nil
)
present(activityVC, animated: true)

Lösung 2: Smarte Error-Analytics mit Gruppierungs-IDs

Während der Feedback-Button Nutzern hilft, bemerkte Probleme zu melden, bleiben viele Probleme ungemeldet. Nutzer stoßen vielleicht auf einen Fehler, zucken die Schultern und versuchen es erneut – ohne dir je davon zu erzählen. Genau hier kommen Error-Analytics ins Spiel.

ErrorKit bietet Tools, um Fehler automatisch zu tracken und intelligent zu gruppieren:

func handleError(_ error: Error) {
    // Eine stabile ID abrufen, die dynamische Parameter ignoriert
    let groupID = ErrorKit.groupingID(for: error)

    // Die vollständige Fehlerketten-Beschreibung abrufen
    let errorDetails = ErrorKit.errorChainDescription(for: error)

    // An dein Analytics-System senden
    Analytics.track(
        event: "error_occurred",
        properties: [
            "error_group": groupID,
            "error_details": errorDetails,
            "user_id": currentUser.id
        ]
    )

    // Dem Nutzer eine passende UI anzeigen
    showErrorAlert(message: ErrorKit.userFriendlyMessage(for: error))
}

Beispiel einer globalen Fehlerbehandlungsfunktion für deine App.

Die Magie steckt hier in der groupingID(for:)-Funktion. Sie generiert einen stabilen Bezeichner basierend auf der Typstruktur des Fehlers und den Enum-Cases, wobei dynamische Parameter und lokalisierte Meldungen ignoriert werden.

Das bedeutet, dass Fehler mit der gleichen Ursache dieselbe Gruppierungs-ID haben, auch wenn konkrete Details (wie Dateipfade oder Nutzer-IDs) unterschiedlich sind:

// Beide erzeugen dieselbe groupID: "3f9d2a"
ProfileError
└─ DatabaseError
   └─ FileError.notFound(path: "/Users/john/data.db")

ProfileError
└─ DatabaseError
   └─ FileError.notFound(path: "/Users/jane/backup.db")

Dieser Ansatz bietet mehrere Vorteile:

1. Häufige Probleme identifizieren: Sieh, welche Fehler am häufigsten auftreten

2. Fixes priorisieren: Konzentriere dich zuerst auf Probleme mit großer Auswirkung

3. Behebung nachverfolgen: Beobachte, ob Fehlerraten nach Fixes sinken

4. Neue Probleme erkennen: Identifiziere schnell neue Fehlermuster nach Releases

5. Mit Nutzersegmenten korrelieren: Sieh, ob bestimmte Fehler spezifische Nutzer betreffen

Beide Ansätze für maximale Einblicke kombinieren

Ein wirkungsvoller Ansatz ist es, automatische Analytics mit nutzerinitiiertem Feedback zu kombinieren, also etwa so:

func handleError(_ error: Error) {
    // Immer für Analytics tracken
    trackErrorAnalytics(error)

    // Bei schwerwiegenden oder unerwarteten Fehlern zum Feedback auffordern
    if isSerious(error) {
        showErrorAlert(
            message: ErrorKit.userFriendlyMessage(for: error),
            feedbackOption: true
        )
    } else {
        // Bei kleineren Problemen einfach eine Meldung anzeigen
        showErrorAlert(message: ErrorKit.userFriendlyMessage(for: error))
    }
}

func showErrorAlert(message: String, feedbackOption: Bool = false) {
    // Implementierung eines Alerts, der optional einen
    // "Feedback senden"-Button enthält, der den Mail-Composer mit Logs öffnet
}

Das ergibt ein umfassendes System, in dem:

1. Alle Fehler für Analytics getrackt werden und dir breite Muster liefern

2. Schwerwiegende Fehler Nutzer zu detailliertem Feedback mit Logs auffordern

3. Nutzer jederzeit Feedback für Probleme initiieren können, die du womöglich nicht trackst

Best Practices für Logging

Um den Wert der Log-Sammlung zu maximieren, beachte diese Best Practices:

1. Logs mit Kontext strukturieren

Liefere genug Kontext in deinen Logs, um zu verstehen, was passiert ist:

// Statt:
Logger().error("Failed to load")

// Verwende:
Logger().error("Failed to load document \(documentId): \(ErrorKit.errorChainDescription(for: error))")

2. Passende Log-Level wählen

Setze Log-Level strategisch ein, um die Ausführlichkeit zu steuern:

• .debug für Entwicklerdetails, die nur während der Entwicklung gebraucht werden

• .info zum Nachverfolgen des normalen App-Ablaufs

• .notice für wichtige Ereignisse, die Nutzer interessieren würden

• .error für Probleme, die behoben werden müssen, aber die Kernfunktionalität nicht verhindern

• .fault für kritische Probleme, die die Kernfunktionalität beeinträchtigen

3. Sensible Informationen schützen

Verwende Privacy-Modifier, um Nutzerdaten zu schützen:

Logger().info("Processing payment for user \(userId, privacy: .private)")

4. Wichtige Nutzeraktionen loggen

Erstelle Breadcrumbs der Nutzeraktivität, um den Weg zu Fehlern nachzuvollziehen:

Logger().notice("User navigated to profile screen")
Logger().info("User tapped edit button")
Logger().notice("User saved profile changes")

5. Start und Abschluss wichtiger Operationen loggen

Klammere bedeutende Operationen ein, um unvollständige Aufgaben zu identifizieren:

Logger().notice("Starting data sync")
// ... Sync-Implementierung
Logger().notice("Completed data sync")

Die Auswirkung auf Support und Entwicklung

Die Implementierung dieser Tools kann sowohl die Nutzererfahrung als auch die Entwicklungsabläufe transformieren:

Für Nutzer:

• Vereinfachtes Melden: Feedback mit einem einzigen Tipp absenden

• Keine technischen Fragen: Frustrierendes Hin-und-her-Kommunizieren vermeiden

• Schnellere Lösung: Probleme können schneller diagnostiziert und behoben werden

• Bessere Erfahrung: Zeigt Nutzern, dass ihre Probleme ernst genommen werden

Für Entwickler:

• Vollständiger Kontext: Sieh genau, was passiert ist, als Probleme auftraten

• Reduzierter Support-Aufwand: Weniger Zeit für Nachfragen nach zusätzlichen Informationen

• Bessere Reproduktion: Zuverlässigere Reproduktionsschritte basierend auf Log-Daten

• Effizientes Debugging: Muster in Fehlerberichten schnell erkennen

• Datengetriebene Prioritäten: Zuerst die häufigsten Probleme beheben

Fazit

ErrorKits Ansatz überbrückt die frustrierende Lücke zwischen einem Nutzer, der “es geht nicht” sagt, und dem tatsächlichen Wissen, was passiert ist. Ich habe festgestellt, dass automatische Log-Sammlung kombiniert mit smarter Error-Analytics eine Feedback-Schleife erzeugt, die tatsächlich funktioniert.

Wirklich mächtig wird es, wenn du detaillierte Logs bekommst, sobald Nutzer sich entscheiden, ein Problem zu melden, und gleichzeitig die Probleme auffängst, die sie nie erwähnen. Dieser duale Ansatz hat grundlegend verändert, wie ich Probleme in meinen Apps verstehe und behebe. Wenn du es satt hast, Probleme im Blindflug zu debuggen, enthält ErrorKit all diese Logging-Tools und Verbesserungen für die Fehlerbehandlung – Werkzeuge, die ich gebaut habe, weil ich sie selbst brauchte:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Wie gehst du mit Nutzerfeedback und Error-Reporting um? Hast du andere effektive Techniken gefunden, die wirklich helfen? Schreib mir auf den sozialen Kanälen (Links unten)!

Vorherige Artikel in dieser Serie:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

2. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

Folgender Artikel in dieser Serie:

1. Making Swift Error Messages Human-Friendly—Together

In diesem Beitrag erkläre ich das Verschachtelungsproblem und zeige dir, wie ich es in ErrorKit mit einem einfachen Protocol gelöst habe, das Typed Throws ohne Boilerplate praxistauglich macht. Als Bonus siehst du, wie richtige Fehlerketten dein Debugging-Erlebnis dramatisch verbessern können.

Typed Throws: Das Versprechen und das Problem

Schauen wir uns zuerst an, was uns Typed Throws in Swift 6 bietet:

// Statt nur 'throws' können wir den Fehlertyp angeben
func processFile() throws(FileError) {
    if !fileExists {
        throw FileError.fileNotFound(fileName: "config.json")
    }
    // Implementierung...
}

Das ermöglicht eine bessere Fehlerbehandlung an der Aufrufstelle:

do {
    try processFile()
} catch FileError.fileNotFound(let fileName) {
    print("Could not find file: \(fileName)")
} catch FileError.readFailed {
    print("Could not read file")
}
// Kein generischer catch nötig, wenn wir alle möglichen FileError-Fälle behandelt haben!

Die Vorteile liegen auf der Hand:

• Compile-time-Verifizierung der Fehlerbehandlung

• Kein Type-Casting mit as? in Catch-Blöcken nötig

• Selbstdokumentierende API, die Aufrufern genau sagt, was schiefgehen kann

• IDE-Autovervollständigung für Fehlerfälle

Das Verschachtelungshölle-Problem

Das Problem entsteht bei der Arbeit mit mehrschichtigen Anwendungen. Sieh dir das an:

// Datenbankschicht wirft DatabaseError
func fetchUser(id: String) throws(DatabaseError) {
    // Datenbankoperationen...
}

// Profilschicht muss die Datenbankschicht aufrufen
func loadUserProfile(id: String) throws(ProfileError) {
    do {
        // Problem: Dies wirft DatabaseError, nicht ProfileError
        let user = try fetchUser(id: id)
    } catch {
        // Manuelle Fehlerkonvertierung nötig
        switch error {
        case DatabaseError.recordNotFound:
            throw ProfileError.userNotFound
        default:
            throw ProfileError.databaseError(error) // Ein Wrapper-Case wird benötigt
        }
    }
}

Das erzeugt mehrere Probleme:

1. Explosion von Wrapper-Cases: Jeder Fehlertyp braucht Wrapper-Cases für alle möglichen Kind-Fehler

2. Manuelles Error-Mapping: Repetitive Do-Catch-Blöcke mit expliziter Fehlerkonvertierung

3. Typen-Inflation: Fehlertypen wachsen mit jeder Schicht und werden schwerer zu pflegen

4. Verlorener Kontext: Details über den ursprünglichen Fehler gehen bei der Übersetzung oft verloren

Für kleine Apps mag das handhabbar sein. Für größere Apps mit vielen Schichten wird es schnell zu dem, was man als “Verschachtelungshölle” bezeichnen kann.

Die Lösung: Das Catching-Protocol

ErrorKit löst das mit einem einfachen Protocol namens Catching:

public protocol Catching {
    static func caught(_ error: Error) -> Self
}

Dieses Protocol erfordert einen einzelnen Enum-Case namens caught, der jeden Fehler in deinen Typ einwickelt. So verwendest du es:

enum ProfileError: Throwable, Catching {
    case userNotFound
    case invalidProfile
    case caught(Error) // Ein einziger Case für alle anderen Fehler

    var userFriendlyMessage: String {
        switch self {
        case .userNotFound:
            return "User not found."
        case .invalidProfile:
            return "Profile data is invalid."
        case .caught(let error):
            // Die Meldung des eingewickelten Fehlers verwenden
            return ErrorKit.userFriendlyMessage(for: error)
        }
    }
}

Beachte, dass Throwable ein Drop-in-Ersatz für Error ist (siehe vorheriger Beitrag).

Jetzt passiert die Magie mit der catch-Funktion, die mit dem Protocol mitgeliefert wird:

func loadUserProfile(id: String) throws(ProfileError) {
    // Bei bekannten Fehlern direkt werfen
    guard isValidID(id) else {
        throw ProfileError.invalidInput
    }

    // Für Operationen, die andere Fehlertypen werfen können, die catch-Funktion verwenden
    let user = try ProfileError.catch {
        // Jeder hier geworfene Fehler wird automatisch
        // in ProfileError.caught(error) eingewickelt
        return try fetchUser(id: id)
    }

    // Rest der Implementierung...
}

Beachte, dass die catch-Funktion zurückgibt, was du in der Closure zurückgibst.

Die catch-Funktion wickelt automatisch alle Fehler, die in ihrer Closure geworfen werden, in deinen Fehlertyp ein. Keine manuellen Do-Catch-Blöcke, kein explizites Error-Mapping – es funktioniert einfach. Sogar mehrere try-Ausdrücke sind möglich.

Das Geheimrezept der catch-Funktion

Die catch-Funktion ist elegant einfach:

extension Catching {
    public static func `catch`<ReturnType>(
        _ operation: () throws -> ReturnType
    ) throws(Self) -> ReturnType {
        do {
            return try operation()
        } catch {
            throw Self.caught(error)
        }
    }
}

Diese Funktion:

1. Nimmt eine werfende Closure entgegen

2. Versucht, sie auszuführen

3. Gibt das Ergebnis bei Erfolg zurück

4. Wickelt jeden geworfenen Fehler automatisch über deinen caught-Case ein

5. Behält den Rückgabetyp der Operation bei

Das Beste daran? Es funktioniert nahtlos mit Swift 6’s Typed Throws, erhält die Typsicherheit und eliminiert gleichzeitig Boilerplate.

Die Fehlerkette für Debugging erhalten

Einer der größten Vorteile dieses Ansatzes ist, dass er die vollständige Fehlerkette erhält. Statt Kontext zu verlieren, wenn Fehler Schichtgrenzen überschreiten, fügt jede Schicht Informationen hinzu und behält den ursprünglichen Fehler intakt.

ErrorKit nutzt das für mächtiges Debugging mit der errorChainDescription(for:)-Funktion:

do {
    try await updateUserProfile()
} catch {
    print(ErrorKit.errorChainDescription(for: error))

    // Ausgabe zeigt die vollständige Kette:
    // AppError
    // └─ ProfileError
    //    └─ DatabaseError
    //       └─ FileError.notFound(path: "/Users/data.db")
    //          └─ userFriendlyMessage: "Could not find database file."
}

Diese hierarchische Ansicht zeigt dir:

1. Wo der Fehler entstanden ist (FileError)

2. Den genauen Weg durch deine Anwendung (FileError -> DatabaseError -> ProfileError -> AppError)

3. Die konkreten Details, was schiefgelaufen ist (Datei nicht gefunden, mit dem Pfad)

4. Die benutzerfreundliche Meldung, die dem Nutzer angezeigt würde

Dieses Maß an Einblick ist beim Debugging unbezahlbar, besonders bei komplexen Anwendungen, in denen Fehler tief im Call Stack entstehen können.

Strukturierte Fehlerketten-Ausgabe

Die Fehlerketten-Beschreibung funktioniert durch rekursives Inspizieren der Fehlerstruktur:

static func errorChainDescription(for error: Error) -> String {
    // Rekursive Implementierung, die eine hierarchische Beschreibung aufbaut
    Self.chainDescription(for: error, enclosingType: type(of: error))
}

Siehe hier für die vollständige Implementierung von chainDescription in ErrorKit.

Die Funktion nutzt Swifts Reflection-Fähigkeiten, um:

1. Den Fehler über die Mirror-API zu inspizieren

2. Bei Fehlern, die Catching konformieren, den eingewickelten Fehler zu extrahieren

3. Bei Enum-Fehlern Case-Namen und zugehörige Werte zu erfassen

4. Bei Struct- oder Class-Fehlern Typ-Metadaten einzubeziehen

5. Alles in einer hierarchischen Baumstruktur zu formatieren

Das liefert weit mehr Informationen als Standard-Error-Logging, besonders bei komplexen Fehlerhierarchien.

Eingebaute Unterstützung in ErrorKit

Alle eingebauten Fehlertypen von ErrorKit (wie FileError oder NetworkError) konformieren bereits zu Catching, sodass du sie sofort verwenden kannst:

func saveUserData() throws(DatabaseError) {
    // Wickelt automatisch SQLite-Fehler, Dateisystem-Fehler usw. ein
    try DatabaseError.catch {
        try database.beginTransaction()
        try database.execute(query)
        try database.commit()
    }
}

Praxisbeispiel: Eine typische Anwendung

Schauen wir uns an, wie das in einem vollständigeren Beispiel funktioniert:

// Datenzugriffsschicht
func fetchUserData(id: String) throws(DatabaseError) {
    guard database.isConnected else {
        throw DatabaseError.connectionFailed
    }

    // Hier könnten Dateisystem-Fehler auftreten
    try DatabaseError.catch {
        let query = try QueryBuilder.build(for: id)
        return try database.execute(query)
    }
}

// Geschäftslogik-Schicht
func processUserProfile(id: String) throws(ProfileError) {
    guard isValidID(id) else {
        throw ProfileError.invalidInput
    }

    // Wickelt automatisch DatabaseError ein
    let userData = try ProfileError.catch {
        return try fetchUserData(id: id)
    }

    // Nutzerdaten verarbeiten...
}

// Präsentationsschicht
func displayUserProfile(id: String) throws(UIError) {
    // Wickelt automatisch ProfileError ein (das möglicherweise DatabaseError enthält)
    let profile = try UIError.catch {
        return try processUserProfile(id: id)
    }

    // Profil anzeigen...
}

Wenn eine Datenbankverbindung fehlschlägt, siehst du Folgendes in der Fehlerkette:

UIError
└─ ProfileError
   └─ DatabaseError.connectionFailed
      └─ userFriendlyMessage: "Unable to establish a connection to the database. Check your network settings and try again."

Das zeigt dir genau, was passiert ist und wo der Fehler entstanden ist, was das Debugging erheblich erleichtert. Der zusätzliche Kontext kann dir den entscheidenden Hinweis geben, um das Problem zu beheben!

Fazit

Swift 6’s Typed Throws ist eine mächtige Ergänzung der Sprache, bringt aber Herausforderungen bei der Fehlerweiterleitung über Schichten hinweg mit sich. Das Catching-Protocol bietet eine einfache, elegante Lösung, die Typsicherheit erhält und gleichzeitig Boilerplate eliminiert.

Kombiniert mit ErrorKits errorChainDescription-Funktion wird Fehlerbehandlung zu einem mächtigen Debugging-Werkzeug. Nutze ErrorKit jetzt und profitiere von vielen weiteren Verbesserungen, die Fehlerbehandlung in Swift in realen Apps nützlicher machen:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Hast du schon angefangen, Swift 6’s Typed Throws zu nutzen? Wie gehst du mit der Fehlerweiterleitung über Schichten in deinen Apps um? Schreib mir auf den sozialen Kanälen (Links unten)!

Vorheriger Artikel in dieser Serie:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

Folgende Artikel in dieser Serie:

1. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

2. Making Swift Error Messages Human-Friendly—Together

“The operation couldn’t be completed. (YourApp.YourError error 0.)”

Dann bist du nicht allein. Dieses verwirrende Verhalten bringt Swift-Entwickler – von Anfängern bis zu Experten – seit der Einführung der Sprache zur Verzweiflung. Heute möchte ich erklären, warum das passiert, und eine Lösung vorstellen, die Swift-Fehlerbehandlung intuitiver macht.

Das überraschende Verhalten von Swifts Error-Protocol

Schauen wir uns ein einfaches Beispiel an, das das Problem demonstriert:

enum NetworkError: Error {
   case noConnectionToServer
   case parsingFailed

   var localizedDescription: String {
      switch self {
      case .noConnectionToServer:
         return "No connection to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }
}

// Verwendung des Fehlers
do {
   throw NetworkError.noConnectionToServer
} catch {
   print("Error message: \(error.localizedDescription)")
   // Erwartet: "No connection to the server."
   // Tatsächlich: "The operation couldn't be completed. (AppName.NetworkError error 0.)"
}

Was ist schiefgelaufen? Wir haben eine klare Fehlermeldung definiert, aber Swift hat sie komplett ignoriert!

Warum das passiert: Die NSError-Bridge

Dieses verwirrende Verhalten entsteht, weil Swifts Error-Protocol unter der Haube auf Objective-Cs NSError-Klasse gemappt wird. Wenn du auf localizedDescription zugreifst, verwendet Swift nicht deine Property – es erstellt ein NSError mit einer Domain (deinem Modulnamen), einem Code (dem Integer-Wert des Enum-Case) und einer Standardmeldung.

Dieses Design mag für Objective-C-Interoperabilität sinnvoll sein, aber es erzeugt eine schreckliche Entwicklererfahrung, besonders für Swift-Neulinge.

Die “offizielle” Lösung: LocalizedError

Swift bietet doch eine offizielle Lösung an: das LocalizedError-Protocol. So soll man es verwenden:

enum NetworkError: LocalizedError {
   case noConnectionToServer
   case parsingFailed

   var errorDescription: String? { // Hinweis: Optionaler String
      switch self {
      case .noConnectionToServer:
         return "No connection to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }

   // Es gibt auch diese optionalen Properties, die selten genutzt werden
   var failureReason: String? { return nil }
   var recoverySuggestion: String? { return nil }
   var helpAnchor: String? { return nil }
}

Das funktioniert zwar, hat aber mehrere Probleme:

• Alle Properties sind optional (String?), also hilft dir der Compiler nicht, wenn du einen Fall vergisst

• Nur errorDescription beeinflusst localizedDescription; die anderen Properties werden oft ignoriert

• Die Benennung macht nicht klar, welche Property die angezeigte Meldung beeinflusst

• Es nutzt immer noch einen Legacy-Ansatz basierend auf Cocoa-Fehlerbehandlungsmustern

Eine bessere Lösung: Das Throwable-Protocol

Nachdem mich diese Frustration zu oft getroffen hat, habe ich als Teil von ErrorKit eine einfachere Lösung geschaffen – ein Protocol namens Throwable:

public protocol Throwable: LocalizedError {
   var userFriendlyMessage: String { get }
}

Dieses Protocol hat mehrere Vorteile:

• Es hat eine einzige, nicht-optionale Anforderung – kein Vergessen von Fällen mehr

• Der Name userFriendlyMessage drückt die Absicht klar aus

• Es erweitert LocalizedError für Kompatibilität (kein Mehraufwand für dich!)

• Es folgt Swifts Namenskonventionen mit dem -able-Suffix

So verwendest du es:

enum NetworkError: Throwable {
   case noConnectionToServer
   case parsingFailed

   var userFriendlyMessage: String {
      switch self {
      case .noConnectionToServer:
         return "Unable to connect to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }
}

// Verwendung des Fehlers
do {
   throw NetworkError.noConnectionToServer
} catch {
   print("Error message: \(error.localizedDescription)")
   // Zeigt jetzt korrekt: "Unable to connect to the server."
}

Mit Throwable bekommst du genau das, was du erwartest – deine Fehlermeldungen erscheinen exakt wie beabsichtigt, ohne Überraschungen.

Schnelle Entwicklung mit String Raw Values

Für schnelles Prototyping funktioniert Throwable auch nahtlos mit String Raw Values:

enum NetworkError: String, Throwable {
   case noConnectionToServer = "Unable to connect to the server."
   case parsingFailed = "Data parsing failed."
}

// Das war's! Keine zusätzliche Implementierung nötig

Die Raw-String-Werte werden automatisch zu deinen Fehlermeldungen – ganz ohne Boilerplate während der frühen Entwicklung. Später, wenn du bereit für richtige Lokalisierung bist, kannst du auf String(localized:) in einer vollständigen Implementierung von userFriendlyMessage umsteigen.

Fertige Fehlertypen

Um noch mehr Boilerplate zu vermeiden, enthält ErrorKit vordefinierte Fehlertypen für häufige Szenarien:

func fetchData() async throws {
    guard isNetworkAvailable else {
        throw NetworkError.noInternet
    }

    guard let url = URL(string: path) else {
        throw ValidationError.invalidInput(field: "URL path")
    }

    // Weitere Implementierung...
}

Diese eingebauten Typen umfassen:

• NetworkError für Konnektivitäts- und API-Probleme

• FileError für Dateisystem-Operationen

• DatabaseError für Datenpersistenz-Probleme

• ValidationError für Eingabevalidierung

• PermissionError für Autorisierungsprobleme

• Und einige mehr…

Jeder eingebaute Typ konformiert bereits zu Throwable und liefert lokalisierte, benutzerfreundliche Meldungen direkt mit – das spart dir Zeit bei gleichzeitiger Klarheit.

Schnelle Einmal-Fehler mit GenericError

Für Situationen, in denen du eine individuelle Meldung brauchst, ohne gleich einen neuen Fehlertyp zu definieren, bietet ErrorKit GenericError:

func quickOperation() throws {
    guard condition else {
        throw GenericError(userFriendlyMessage: "The operation couldn't be completed because a specific condition wasn't met.")
    }

    // Weitere Implementierung...
}

Das ist perfekt für die frühe Entwicklung oder einzigartige Fehlerfälle, die keinen eigenen Fehlertyp rechtfertigen.

Vorteile über bessere Meldungen hinaus

Die Nutzung von Throwable behebt nicht nur Fehlermeldungen – es bringt mehrere zusätzliche Vorteile:

1. Klarheit für neue Entwickler: Das Protocol zeigt klar, wie Fehlermeldungen definiert werden

2. Compile-time-Sicherheit: Die nicht-optionale Anforderung stellt sicher, dass alle Fälle Meldungen haben

3. Lokalisierungssupport: Funktioniert perfekt mit String(localized:) für Internationalisierung

4. Weniger Boilerplate: Besonders mit Raw-String-Werten und eingebauten Typen

5. Verbesserte Nutzererfahrung: Klare Fehlermeldungen helfen Nutzern zu verstehen, was schiefgelaufen ist

6. Besseres Debugging: Aussagekräftige Fehlermeldungen machen das Debuggen schneller

Der Umstieg

Das Beste daran? Throwable ist ein Drop-in-Ersatz für Error:

// Vorher
enum AppError: Error {
    case configurationFailed
}

// Nachher
enum AppError: Throwable {
    case configurationFailed

    var userFriendlyMessage: String {
        switch self {
        case .configurationFailed:
           return "Failed to load configuration."
        }
    }
}

Bestehender Code mit throws, do/catch und anderen Fehlerbehandlungsmustern funktioniert exakt gleich – der einzige Unterschied ist, dass deine Fehlermeldungen jetzt tatsächlich wie beabsichtigt angezeigt werden.

Fazit

Swifts Fehlerbehandlung ist leistungsstark, aber die Meldungsverarbeitung ist viel zu lange ein verwirrender Schmerzpunkt gewesen. Das Throwable-Protocol bietet eine einfache, intuitive Lösung, die mit Swifts Designprinzipien übereinstimmt und gleichzeitig ein langjähriges Problem behebt.

Indem du Throwable für deine Fehlertypen verwendest, bekommst du klarere Fehlermeldungen, weniger Boilerplate und eine intuitivere Entwicklererfahrung. Zusammen mit den eingebauten Fehlertypen und dem GenericError-Fallback ergibt das einen umfassenden Ansatz für Fehlerbehandlung, der so funktioniert, wie du es erwarten würdest.

Wenn du diesen Ansatz in deinen eigenen Projekten ausprobieren möchtest, schau dir ErrorKit an, das das Throwable-Protocol, eingebaute Fehlertypen und viele weitere Verbesserungen für die Swift-Fehlerbehandlung enthält:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Bist du auch schon auf diese Verwirrung mit Fehlermeldungen in deiner Swift-Entwicklung gestoßen? Wie hast du das gelöst? Schreib mir auf den sozialen Kanälen (Links unten)!

Folgende Artikel in dieser Serie:

1. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

2. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

3. Making Swift Error Messages Human-Friendly—Together

Swift Macros, eingeführt in Xcode 15 mit Swift 5.9, sind ein mächtiges Feature, das Code-Generierung und Metaprogrammierung zur Compile-Zeit ermöglicht. Während sie hervorragende Produktivitätsvorteile bieten, haben sie eine neue Herausforderung für CI/CD-Pipelines geschaffen – insbesondere in Xcode Cloud.

Wenn du ein Macro zum ersten Mal lokal verwendest, zeigt Xcode einen Dialog an, der dich auffordert, dem Package des Macros zu vertrauen, bevor es ausgeführt werden kann. Das funktioniert auf deinem Entwicklungsrechner problemlos, wird aber in automatisierten Umgebungen wie Xcode Cloud zum Problem, wo es eben keine Möglichkeit gibt, auf “OK” in einem Dialogfenster zu klicken.

Wenn du schon mal versucht hast, ein Projekt mit Swift Macros in Xcode Cloud zu bauen, bist du wahrscheinlich auf diesen frustrierenden Fehler gestoßen:

Target must be enabled before it can be used.

Die vollständige Lösung

Nach einiger Recherche habe ich eine zuverlässige Lösung gefunden, die bei Xcode Cloud Builds mit Swift Macros konsistent funktioniert. So implementierst du sie:

Schritt 1: Einen CI-Scripts-Ordner erstellen

Erstelle zunächst einen eigenen Ordner für unsere CI-Skripte:

1. Rechtsklick auf dein Projekt in Xcode

2. Wähle “New Group”

3. Benenne ihn ci_scripts

Schritt 2: Das Post-Clone-Skript erstellen

Als Nächstes erstellen wir ein Post-Clone-Skript, das Xcode Cloud automatisch nach dem Klonen deines Repositories ausführt:

1. Rechtsklick auf den Ordner ci_scripts

2. Wähle “New File” -> “Empty File”

3. Benenne es ci_post_clone.sh

Schritt 3: Den Skriptinhalt hinzufügen

Kopiere den folgenden Code in deine neue Datei ci_post_clone.sh:

#!/bin/sh

# Bei Fehler abbrechen (-e), undefinierte Variablen (-u) und Pipeline-Fehler (-o pipefail)
set -euo pipefail

# Xcode-Macro-Fingerprint-Validierung deaktivieren, um fehlerhafte Build-Fehler zu vermeiden
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES

Dieses Skript tut eine entscheidende Sache: Es deaktiviert Xcodes Macro-Fingerprint-Validierung – also genau das, was den Vertrauensdialog überhaupt auslöst.

Schritt 4: Das Skript ausführbar machen

Öffne das Terminal, navigiere zu deinem Projektordner und führe aus:

chmod +x ci_scripts/ci_post_clone.sh

Dieser Befehl macht dein Skript ausführbar, was erforderlich ist, damit Xcode Cloud es korrekt ausführen kann.

Schritt 5: Committen und einen Build auslösen

Committe die neue Datei in dein Repository und pushe die Änderungen. Das löst einen neuen Build in Xcode Cloud aus, der jetzt ohne den Macro-Vertrauensfehler erfolgreich durchlaufen sollte.

So sieht es aus

Wenn alles korrekt eingerichtet ist, sollte deine Projektstruktur den CI-Scripts-Ordner mit dem Post-Clone-Skript enthalten:

Warum das funktioniert

Xcode Cloud führt automatisch jedes Skript mit dem Namen ci_post_clone.sh aus, das sich in einem ci_scripts-Verzeichnis im Root deines Projekts befindet. Unser Skript ändert die Xcode-Einstellungen, um die Macro-Fingerprint-Validierung zu deaktivieren und so die Vertrauensanforderung zu umgehen.

Der Befehl defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES ändert eine spezifische Xcode-Einstellung, die steuert, ob Macros explizit vertraut werden muss, bevor sie verwendet werden können.

Sicherheitsaspekte

Manche Entwickler schlagen vor, die Datei macros.json (die vertrauenswürdige Macro-Fingerprints enthält) von deinem lokalen Rechner in die CI-Umgebung zu kopieren. Ich bin allerdings der Meinung, dass dieser Ansatz nicht unbedingt sicherer ist als die Validierung einfach zu deaktivieren.

Der entscheidende Punkt ist hier der Kontext: Xcode Cloud läuft in einer Sandbox-Umgebung, die speziell zum Bauen deiner Anwendung dient. Es führt keinen beliebigen Code auf Produktionssystemen aus. Wenn du deinem Entwicklungsteam und deinem Release-Workflow nicht vertrauen kannst, hast du wahrscheinlich schwerwiegendere Sicherheitsprobleme als Macros, die in einer CI-Umgebung laufen.

Die wachsende Bedeutung dieser Lösung

Da Swift sich stetig weiterentwickelt, implementieren immer mehr Third-Party-Packages Macros, um leistungsstarke Features mit minimalem Boilerplate zu bieten. Zum Beispiel:

• TranslateKit SDK bietet Lokalisierungs-Macros

• Verschiedene Logging- und Debugging-Bibliotheken setzen auf Macros

• UI-Frameworks nutzen Macros, um View-Deklarationen zu vereinfachen

Dieser Trend wird sich nur beschleunigen, da Entwickler immer neue Einsatzmöglichkeiten für Compile-Zeit-Metaprogrammierung entdecken. Eine zuverlässige Lösung für den Umgang mit Macros in CI-Pipelines wird für Swift-Projekte zunehmend wichtig.

Jetzt, da du das Macro-Vertrauensproblem gelöst hast, kannst du die Möglichkeiten von Xcode Cloud voll ausschöpfen. Ich werde in meinem nächsten Artikel und dem dazugehörigen Video zeigen, wie man Xcode Cloud für App-Store-Deployments nutzt. Dieser Ansatz kann dir wertvolle Zeit beim Warten auf Builds sparen, besonders wenn du wie ich auf mehreren Apple-Plattformen (iOS, macOS, visionOS) veröffentlichst. Bleib dran und viel Spaß beim Coden!

Doch als ich mich tiefer in String Catalogs einarbeitete, fiel mir etwas Interessantes auf: Apples tiefe SwiftUI-Integration eröffnete Möglichkeiten, die über Xcode-Extensions nicht erreichbar waren. Anstatt gegen den Strom zu schwimmen, entschied ich mich, ihn zu nutzen. An einem einzigen Wochenende baute ich ein einfaches Tool, das String Catalogs parsen und maschinelle Übersetzungen durchführen konnte. Dieses Tool wurde TranslateKit.

Eine unerwartete Erfolgsgeschichte

Was als Wochenendprojekt für den Eigenbedarf begann, wurde schnell zu meiner bisher erfolgreichsten App. Entwickler weltweit schätzten TranslateKits Einfachheit und Effizienz. Das Feedback übertraf meine Erwartungen für eine so schnell geschriebene App, und damit kamen wertvolle Erkenntnisse darüber, was Entwickler von einem Lokalisierungstool wirklich brauchen. Erst kürzlich teilte ein Indie-Entwicklerkollege auf Bluesky:

1/ I've always wanted to localize @glusight.app, but I initially thought it'd require significant refactoring, which I wasn't prepared for. However, my new project, setup with localization from the start made it clear how easy Apple and tools like @translatekit.app make the process.

#BuildInPublic

— slowbrewed.studio (@creativewith.in) 2025-02-03T15:42:08.641Z

Das hat mich sehr angesprochen. Viele Entwickler überschätzen den Aufwand, der nötig ist, um ihre SwiftUI-Apps zu lokalisieren. Mit den heutigen Tools ist es überraschend unkompliziert, auf 90 % Lokalisierungsabdeckung zu kommen, und die letzten 10 % werden einfacher denn je.

Bedenke mal: Etwa 80 % der Weltbevölkerung sprechen kein Englisch. Fehlende Lokalisierung ist statistisch gesehen weltweit der Grund Nummer eins, warum eine App für Nutzer nicht zugänglich ist. Jede App sollte lokalisiert werden – es geht nicht nur darum, mehr Nutzer zu erreichen, sondern darum, deine App wirklich zugänglich zu machen. Und ich habe es mir zur Mission gemacht, das für Indie-Entwickler so einfach wie möglich zu machen.

Die Weiterentwicklung zu TranslateKit 3

Nach einem Jahr des Lernens aus Nutzerfeedback wurde mir klar, dass ich es viel besser machen könnte. Der größte Schmerzpunkt? Das Einrichten von API-Keys. Entwickler mussten sich bei verschiedenen Übersetzungsdiensten registrieren, mit Kreditkarten hantieren und API-Kontingente verwalten. Das war zu viel Reibung für etwas, das ein einfacher Prozess sein sollte.

Dann gab es die Probleme mit der Übersetzungsqualität. Meine Integrationen für maschinelle Übersetzung waren zwar gut, aber sie verfehlten oft den entscheidenden Kontext, weil sie jeden String isoliert übersetzten. Ein Button, der auf Englisch perfekt Sinn ergab, konnte in anderen Sprachen umständlich lang oder völlig am Kontext vorbei übersetzt werden. Durch die Verarbeitung von Strings in Batches und die Bereitstellung des vollständigen App-Kontexts für die KI gewährleistet TranslateKit 3 Konsistenz und einen angemessenen Ton in der gesamten App.

Projektweites Management war eine weitere wichtige Verbesserung. Zuvor mussten Entwickler daran denken, ihre InfoPlist.xcstrings-Datei separat per Drag-and-Drop hinzuzufügen – was dazu führte, dass Apps zwar lokalisiert waren, aber Berechtigungsdialoge immer noch auf Englisch erschienen. Jetzt kümmert sich TranslateKit um dein gesamtes Projekt auf einmal und stellt sicher, dass nichts übersehen wird.

Das führte zu einem kompletten Neuaufbau, fokussiert auf das, was Entwicklern am wichtigsten ist:

1. Kein Setup nötig – keine API-Keys oder Service-Registrierungen mehr

2. Kontextbewusste KI-Übersetzungen, die den Zweck deiner App verstehen

3. Projektweite Lokalisierung, die alles erfasst, einschließlich Berechtigungstexte

4. Intelligenter Umgang mit Markenbegriffen und Terminologie deiner App

5. Unterstützung von sprachspezifischen Nuancen wie Formalität und kulturellem Kontext

Die Ergebnisse? Übersetzungsfehler wurden im Vergleich zu herkömmlichen Diensten um etwa 90 % reduziert. Darüber hinaus führt TranslateKit 3 KI-Korrekturlesen ein – ein einzigartiges Feature, das bestehende Übersetzungen verbessern kann, egal ob sie von einer älteren Version von TranslateKit oder einer anderen Quelle stammen. Wähle einfach die zu prüfenden Sprachen aus und lass die KI deine Übersetzungen für noch bessere Genauigkeit feintunen.

Überzeuge dich selbst davon, was Noah, der Entwickler hinter Proxyman, sagt:

love this feature.

Meanwhile, Google Translate is so stupid, it tried to translate universal terms like HEAD, GET, Proxy, REST ... to Chinese, which is completely wrong pic.twitter.com/YaxCan3kUH

— Noah Tran (@_nghiatran) February 17, 2025

Noah über die Lokalisierung seiner sehr großen App Proxyman.

Und mit dem neuen Pay-what-you-need-Preismodell ist Lokalisierung endlich für alle Indie-Entwickler erschwinglich. Du kannst das Wasser testen, indem du eine einzelne Sprache für nur 1 $ hinzufügst (mit einem kostenlosen ersten Monat zum Ausprobieren), oder gleich voll einsteigen und 5x mehr Nutzer erreichen, indem du die Top 10 Sprachen einer durchschnittlich großen App in nur 4 Minuten hinzufügst – für weniger als 5 $. Ich hoffe, das macht App-Lokalisierung so erschwinglich wie möglich und beseitigt eine weitere Hürde für Entwickler, die darüber nachdenken.

Über iOS hinausdenken

Aber dabei habe ich nicht aufgehört. Wie ich in meinem kürzlichen Beitrag über das TranslateKit SDK geteilt habe, können SwiftUI-Entwickler jetzt von automatischer Key-Generierung mit dem #tk-Macro profitieren und auf über 2.000 vorlokalisierte gängige UI-Texte zugreifen – mit einem Aufruf wie TK.Action.cancel. Beides wird die Genauigkeit der Lokalisierung weiter verbessern. Und obwohl iOS-Entwicklung immer mein Hauptfokus bleiben wird, habe ich TranslateKits Kern-Übersetzungssystem plattformunabhängig konzipiert und damit den Weg für die Unterstützung anderer App-Plattformen geebnet – Android und Flutter als Erste.

Ich arbeite gerade an den letzten Details eines umfassenden Video-Guides, der zeigen wird, wie unkompliziert App-Lokalisierung inzwischen geworden ist. Denn manchmal hilft eben nur Sehen, um zu glauben – und ich möchte, dass jeder Entwickler weiß, dass er seine App global machen kann, ohne die Kopfschmerzen, die er vielleicht erwartet. Vorerst muss dieses 50-Sekunden-Video genügen:

Probier es selbst aus

Der beste Weg zu verstehen, wie einfach Lokalisierung inzwischen geworden ist, ist es selbst auszuprobieren. Füge einen String Catalog zu deinem Projekt hinzu, baue deine App, und du wirst vielleicht überrascht sein, dass sie bereits die meisten Einträge enthält, die lokalisiert werden müssen. Mit TranslateKit 3 kannst du sie mit kontextbewusster KI übersetzen, Konsistenz über dein gesamtes Projekt sicherstellen und Nutzer weltweit schneller denn je erreichen.

Die Reise von RemafoX zu TranslateKit hat mir gezeigt, dass etwas, das wie ein Rückschlag aussieht, manchmal dazu führen kann, etwas noch Besseres zu bauen. Indem ich neue Technologien angenommen und wirklich auf die Bedürfnisse der Entwickler gehört habe, konnte ich ein Tool schaffen, das App-Lokalisierung einfacher und besser macht. Geduld zahlt sich am Ende eben immer aus!

Um zu verstehen, wie weit die Lokalisierung gekommen ist – und wo sie noch Schwächen hat – werfen wir einen kurzen Blick zurück: In der Ära vor den String Catalogs verließen sich Entwickler auf eine Kombination aus .strings- und .stringsdict-Dateien, organisiert in sprachspezifischen Ordnern wie en.lproj. Dieses System war zwar funktional, hatte aber einige Nachteile:

1. Fehlende Sicherheitsprüfungen für ungenutzte oder fehlende Übersetzungen

2. Manuelle Synchronisierung zwischen verschiedenen Sprachdateien nötig

3. Keine eingebaute Unterstützung für die Extraktion von Strings aus dem Code

Tools wie SwiftGen und BartyCrouch entstanden, um diese Probleme zu lösen, und boten Typsicherheit und automatisierte Extraktion. Und die Community etablierte Best Practices rund um semantische Keys (z. B. "Onboarding.Page1.title"), um Kontext für Übersetzer zu liefern und verwandte Strings zu gruppieren.

String Catalogs: Ein Gamechanger mit Kompromissen

String Catalogs, 2023 von Apple eingeführt, lösten mehrere langjährige Probleme:

✅ Automatische Key-Extraktion aus dem Code ✅ Eingebaute Sicherheitsprüfungen für fehlende Übersetzungen ✅ Visuelles Fortschritts-Tracking in Xcode ✅ Einheitliches Dateiformat für alle Sprachen ✅ Abwärtskompatibilität mit älteren iOS-Versionen

Allerdings brachte Apples empfohlener Ansatz, englische Strings als Keys zu verwenden – obwohl er die Lesbarkeit im Code verbessert – neue Herausforderungen mit sich:

❌ Zusammengehörige Strings sind alphabetisch verstreut ❌ Weniger Kontext für Übersetzer ❌ Keine Gruppierung nach Feature oder Screen

Das Fehlen von Gruppierung in String Catalogs ist beim Übersetzen nicht hilfreich.

Ebenso wichtig: Es gibt eine erhebliche Lücke im iOS-Entwicklungs-Ökosystem rund um Lokalisierung, die der Situation bei Icons vor SF Symbols ähnelt. Vor SF Symbols musste jeder Entwickler eigene Icons erstellen oder beschaffen, was zu inkonsistenten Erlebnissen über Apps hinweg führte. SF Symbols löste das durch einen standardisierten, umfassenden Satz an Icons, die Konsistenz sicherstellen und enorm viel Entwicklungszeit sparen.

Der Lokalisierungsbereich braucht dringend eine ähnliche Lösung. Jede App braucht gängige UI-Strings wie “Speichern”, “Abbrechen”, “Fertig”, “Datenschutzrichtlinie” oder “Allgemeine Geschäftsbedingungen” – und diese sollten über Apps hinweg genauso konsistent sein wie Icons. Nutzer profitieren von dieser Konsistenz in gleicher Weise wie von konsistenter Ikonografie. Doch aktuell muss jeder Entwickler diese gängigen UI-Elemente unabhängig übersetzen, was zu unterschiedlichen Übersetzungen für die gleichen Konzepte in verschiedenen Apps und Sprachen führt.

TranslateKit: Das fehlende Puzzlestück

Das Open-Source-TranslateKit SDK schließt diese Lücken und bietet eine umfassende Lösung, die Best Practices beibehält und gleichzeitig die Vorteile von String Catalogs voll ausschöpft. So wie SF Symbols die Icon-Nutzung in iOS-Apps revolutioniert hat, will dieses neue Swift-Package dasselbe für die Lokalisierung tun.

1. Semantische Key-Generierung ohne Aufwand

Das #tk-Macro bringt semantische Keys zurück und hält den Code dabei sauber und lesbar:

struct OnboardingView: View {
  var body: some View {
    // Generates key: OnboardingView.Body.welcomeToMyApp
    Text(#tk("Welcome to MyApp"))
  }
}

Dieser Ansatz:

• Generiert automatisch semantische Keys basierend auf dem Code-Kontext

• Bewahrt die Lesbarkeit des Codes

• Liefert wichtigen Kontext für Übersetzer

• Gruppiert zusammengehörige Strings im String Catalog

Automatisch generierte semantische Keys, die zusammengehörige Strings natürlich gruppieren.

Und alles, was du schreiben musst, ist #tk() um deine String-Literale. Super einfach!

2. Vorlokalisierte gängige UI-Elemente

So wie SF Symbols die Icon-Nutzung standardisiert hat, brauchen wir Konsistenz bei UI-Texten. TranslateKit bietet über 2.000 Strings, die in alle 40 von Apple im iOS-Betriebssystem unterstützten Sprachen vorlokalisiert sind.

Sie sind in 4 Kategorien unterteilt, damit du leicht findest, was du brauchst:

// Actions
Button(TK.Action.save) { saveData() }
// => en: "Save", de: "Sichern", etc.

// Labels
Text(TK.Label.privacyPolicy)
// => en: "Privacy Policy", de: "Sichern", etc.

// Messages
Text(TK.Message.areYouSure)
// => en: "Privacy Policy", de: "Datenschutzerklärung", etc.

// Placeholders
ProgressView(TK.Placeholder.loadingDots)
// => en: "Loading…", de: "Laden…", etc.

Vorteile:

• Passt zu System-UI-Übersetzungen von Apple (Konsistenz)

• Garantiert professionelle Qualität für gängige UI-Elemente (Genauigkeit)

• Reduziert den Lokalisierungsaufwand (spart Zeit & Geld)

3. Kontextbewusste Übersetzungen

Moderne Lokalisierung bedeutet nicht nur, Wörter zu übersetzen – es geht darum, den Kontext zu verstehen. Während die automatische Key-Generierung in 90 % der Fälle dabei hilft, musst du in manchen Fällen zusätzlich den optionalen c-Parameter angeben:

struct DocumentView: View {
    let fileName: String

    var body: some View {
        Button(#tk("Delete '\(fileName)'?",
                   c: "Example: Delete 'MyStats.csv'?")) {
            handleDelete()
        }
    }
}

Dieser Kommentar-Parameter wird am häufigsten benötigt, wenn du dynamische Daten in deinem String hast, wie im obigen Beispiel. Es ist wichtig, immer typische Beispieldaten im Kommentar anzugeben, damit es klar wird. Sonst wissen Übersetzer möglicherweise nicht, wie sie korrekt übersetzen sollen.

Was kommt als Nächstes?

Dieser Artikel hat gezeigt, wie das TranslateKit SDK den grundlegenden Lokalisierungs-Workflow modernisiert. Wenn du dich für fortgeschrittenere Themen wie Pluralisierung, Formatter und mehr interessierst, abonniere meinen YouTube-Kanal, um dein Interesse an detaillierteren Videos zu signalisieren:

FlineDev

✨ TranslateKit SDK funktioniert perfekt zusammen mit TranslateKit for Mac, einem präzisen, KI-gestützten Übersetzungstool, um den Rest deiner App zu lokalisieren! Es ist superschnell und erschwinglich, probiere es kostenlos aus, um mehr Nutzer zu erreichen.

In diesem Artikel stelle ich eine Auswahl der Styles vor, die sich in meiner täglichen Arbeit an Apps wie TranslateKit, FreemiumKit und CrossCraft am meisten bewährt haben. HandySwiftUI enthält zwar noch viele weitere Hilfsfunktionen, aber diese Styles haben sich in der Praxis immer wieder als besonders wertvoll erwiesen und könnten auch für deine SwiftUI-Projekte nützlich sein.

Primary-, Secondary- und Pulsating-Buttons

Erstelle visuell ansprechende Buttons mit vorgefertigten Styles für verschiedene Anwendungsfälle:

struct ButtonShowcase: View {
   var body: some View {
       VStack(spacing: 20) {
           // Primary Button mit auffälligem Hintergrund
           Button("Get Started") {}
               .buttonStyle(.primary())

           // Secondary Button mit Rahmen
           Button("Learn More") {}
               .buttonStyle(.secondary())

           // Aufmerksamkeitsstarker pulsierender Button
           Button {} label: {
              Label("Updates", systemImage: "bell.fill")
                 .padding(15)
           }
           .buttonStyle(.pulsating(color: .blue, cornerRadius: 20, glowRadius: 8, duration: 2))
       }
   }
}

Horizontale, vertikale und Icon-Width-fixierte Labels

Mehrere Label-Styles für verschiedene Layout-Anforderungen:

struct LabelShowcase: View {
   var body: some View {
       VStack(spacing: 20) {
           // Horizontales Layout mit Icon rechts
           Label("Settings", systemImage: "gear")
               .labelStyle(.horizontal(spacing: 8, iconIsTrailing: true, iconColor: .blue))

           // Feste Icon-Breite für Ausrichtung
           Label("Profile", systemImage: "person")
               .labelStyle(.fixedIconWidth(30, iconColor: .green, titleColor: .primary))

           // Vertikales Stapel-Layout
           Label("Messages", systemImage: "message.fill")
               .labelStyle(.vertical(spacing: 8, iconColor: .blue, iconFont: .title))
       }
   }
}

Alle Parameter sind optional mit sinnvollen Standardwerten, du kannst sie also einfach wie .vertical() verwenden. Du musst nur angeben, was du anpassen möchtest.

Vertikal beschriftete Inhalte

Strukturierte Formulareingaben mit vertikalen Labels, wie sie in der API-Konfiguration von FreemiumKit verwendet werden:

struct APIConfigView: View {
    @State private var keyID = ""
    @State private var apiKey = ""

    var body: some View {
        Form {
            HStack {
                VStack {
                    LabeledContent("Key ID") {
                        TextField("e.g. 2X9R4HXF34", text: $keyID)
                            .textFieldStyle(.roundedBorder)
                    }
                    .labeledContentStyle(.vertical())

                    LabeledContent("API Key") {
                        TextEditor(text: $apiKey)
                            .frame(height: 80)
                            .textFieldStyle(.roundedBorder)
                    }
                    .labeledContentStyle(.vertical())
                }
            }
        }
    }
}

Der .vertical-Style ermöglicht die Anpassung von Ausrichtung (Standard: leading) und Abstand (Standard: 4). Übergib muteLabel: false, wenn du einen eigenen Label-Style verwendest, da Labels standardmäßig automatisch kleiner und grau dargestellt werden.

Zum Beispiel möchte ich im Feature-Lokalisierungsformular von FreemiumKit, dass das vertikale Label eine größere Schrift hat:

LabeledContent {
   LimitedTextField(
      "English \(self.title)",
      text: self.$localizedString.fallback,
      characterLimit: self.characterLimit
   )
   .textFieldStyle(.roundedBorder)
} label: {
   Text("English \(self.title) (\(self.isRequired ? "Required" : "Optional"))")
      .font(.title3)
}
.labeledContentStyle(.vertical(muteLabel: false))

Multi-Platform Toggle-Style

Während SwiftUI einen .checkbox-Toggle-Style bietet, ist dieser nur auf macOS verfügbar. HandySwiftUI ergänzt .checkboxUniversal, das Checkbox-artige Toggles auf allen Plattformen ermöglicht (und auf macOS als .checkbox gerendert wird):

struct ProductRow: View {
    @State private var isEnabled: Bool = true

    var body: some View {
       HStack {
           Toggle("", isOn: $isEnabled)
              .toggleStyle(.checkboxUniversal)

           Text("Pro Monthly")

           Spacer()
       }
    }
}

Das Beispiel stammt aus dem Produkte-Bildschirm von FreemiumKit, der für macOS optimiert ist, aber auch andere Plattformen unterstützt.

Leg noch heute los

Ich hoffe, du findest diese Styles genauso nützlich in deinen Projekten wie ich in meinen. Wenn du Ideen für Verbesserungen oder zusätzliche Styles hast, die der SwiftUI-Community zugutekommen könnten, trage gerne auf GitHub bei:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

Dies ist der letzte von vier Artikeln, die die Features von HandySwiftUI erkunden. Schau dir die vorherigen Artikel über Neue Typen, View Modifier und Extensions an, falls du sie noch nicht gelesen hast!

In diesem Artikel stelle ich eine Auswahl der Extensions vor, die sich in meiner täglichen Arbeit an Apps wie TranslateKit, FreemiumKit und CrossCraft am meisten bewährt haben. HandySwiftUI enthält zwar noch viele weitere Hilfsfunktionen, aber diese Extensions haben sich in der Praxis immer wieder als besonders wertvoll erwiesen und könnten auch für deine SwiftUI-Projekte nützlich sein.

Komfortfunktionen für optionale Bindings

Die Operatoren ?? und ! sowie der isPresent-Modifier vereinfachen die Arbeit mit optionalen Werten in Bindings:

struct EditableProfile: View {
   @State private var profile: Profile?
   @State private var showAdvanced = false

   var body: some View {
       Form {
           // Standardwert für optionales Binding über den `??`-Operator
           TextField("Name", text: $profile?.name ?? "Anonymous")

           // Binding-Wert mit `!`-Operator negieren
           Toggle("Hide Details", isOn: !$showAdvanced)
       }
       // Optionales Binding für Sheet-Präsentation nutzen
       .sheet(isPresented: $profile.isPresent(wrappedType: Profile.self)) {
           ProfileEditor(profile: $profile)
       }
   }
}

Die Operatoren sind in allen möglichen Views nützlich, wenn du zum Beispiel mit optionalen Daten in Models arbeitest.

Farbverwaltung

Die umfassenden Color-Extensions bieten leistungsstarke Werkzeuge zur Farbmanipulation und Nutzung von Systemfarben:

struct ColorfulView: View {
   @State private var baseColor = Color.blue

   var body: some View {
       VStack {
           // Variationen der Basisfarbe erzeugen
           Rectangle()
               .fill(baseColor.change(.luminance, by: -0.2))
           Rectangle()
               .fill(baseColor)
           Rectangle()
               .fill(baseColor.change(.luminance, by: 0.2))

           // Mit Hex-Farben arbeiten
           Circle()
               .fill(Color(hex: "#FF5733"))

           // Farbkomponenten verwenden
           Text("HSB: \(baseColor.hsbo.hue), \(baseColor.hsbo.saturation), \(baseColor.hsbo.brightness)")
           Text("RGB: \(baseColor.rgbo.red), \(baseColor.rgbo.green), \(baseColor.rgbo.blue)")
       }
       .padding()
       // Semantische Systemfarben für eigene systemähnliche Komponenten nutzen
       .background(Color.systemBackground)
   }
}

Wenn du die Helligkeit einer Farbe anpasst, verwende .luminance statt .brightness aus dem HSB-Farbsystem. Luminanz bildet besser ab, wie Menschen Licht und Dunkelheit wahrnehmen – deshalb unterstützt HandySwiftUI auch den HLC-Farbraum.

Rich-Text-Formatierung

Die Textformatierungs-Extensions bieten eine praktische Möglichkeit, Rich Text mit gemischten Styles zu erstellen, inspiriert von XML-artigen Tags:

struct FormattedText: View {
   var body: some View {
       Text(
           format: "A <b>bold</b> new way to <i>style</i> your text with <star.fill/> and <b>mixed</b> <red>formatting</red>.",
           partialStyling: Dictionary.htmlLike.merging([
               "red": { $0.foregroundColor(.red) },
               "star.fill": { $0.foregroundColor(.yellow) }
           ]) { $1 }  // $1 zurückgeben (statt $0) bedeutet, dass hinzugefügte Keys bestehende überschreiben
       )
   }
}

Im obigen Beispiel wird das mitgelieferte .htmlLike-Styling von HandySwiftUI mit eigenen Tags kombiniert. Beachte, dass .htmlLike einfach Folgendes zurückgibt:

[
   "b": { $0.bold() },
   "sb": { $0.fontWeight(.semibold) },
   "i": { $0.italic() },
   "bi": { $0.bold().italic() },
   "sbi": { $0.fontWeight(.semibold).italic() },
   "del": { $0.strikethrough() },
   "ins": { $0.underline() },
   "sub": { $0.baselineOffset(-4) },
   "sup": { $0.baselineOffset(6) },
]

Alle XML-artigen Einträge, die mit /> enden, wie <star.fill/> im Beispiel oben, werden als SFSymbol gerendert. So kannst du SFSymbols ganz einfach direkt in deinem Text verwenden.

Bildverarbeitung

Einheitliche Extensions für die Bildverarbeitung mit UIImage und NSImage:

class ImageProcessor {
   func processImage(_ image: UIImage) {
       // Bild unter Beibehaltung des Seitenverhältnisses skalieren
       let resized = image.resized(maxWidth: 800, maxHeight: 600)

       // In verschiedene Formate konvertieren
       let pngData = image.webpData()
       let jpegData = image.webpData(compressionQuality: 0.8)
       let heicData = image.heicData(compressionQuality: 0.8)
   }
}

Beachte, dass all diese APIs optionale Werte zurückgeben – für Grenzfälle wie extrem niedrigen Speicher – aber in den meisten Fällen erfolgreich durchlaufen.

Komfortable Model-zu-View-Konvertierungen

HandySwiftUI bietet Initializer-Komfortfunktionen, die es einfach machen, deine Model-Typen direkt in SwiftUI-Views darzustellen:

enum Tab: CustomLabelConvertible {
    case home, profile, settings

    var description: String {
        switch self {
        case .home: "Home"
        case .profile: "Profile"
        case .settings: "Settings"
        }
    }

    var symbolName: String {
        switch self {
        case .home: "house.fill"
        case .profile: "person.circle"
        case .settings: "gear"
        }
    }
}

struct ContentView: View {
    @State private var selectedTab: Tab = .home

    var body: some View {
        TabView(selection: $selectedTab) {
            HomeView()
                // Tab-Item direkt aus Enum-Case erstellen
                .tabItem { Label(convertible: Tab.home) }
                .tag(Tab.home)

            ProfileView()
                .tabItem { Label(convertible: Tab.profile) }
                .tag(Tab.profile)

            SettingsView()
                .tabItem { Label(convertible: Tab.settings) }
                .tag(Tab.settings)
        }

        // Funktioniert auch mit Text- und Image-Views
        Text(convertible: selectedTab)  // Zeigt den Tab-Namen
        Image(convertible: selectedTab) // Zeigt das Tab-Icon
    }
}

Statt manuell Strings und Symbolnamen aus deinen Models zu extrahieren, kannst du sie auf CustomStringConvertible für Text, CustomSymbolConvertible für SF Symbols oder CustomLabelConvertible für beides konformieren. Dann nutze die komfortablen Initializer, um SwiftUI-Views direkt zu erstellen:

• Text(convertible:) – Erstellt Text aus jedem CustomStringConvertible

• Image(convertible:) – Erstellt SF-Symbol-Bilder aus jedem CustomSymbolConvertible

• Label(convertible:) – Erstellt Text+Icon-Labels aus jedem CustomLabelConvertible

Dieses Muster funktioniert besonders gut mit Enums, die UI-Zustände, Menüoptionen oder Tabs repräsentieren, wie im Beispiel oben gezeigt.

Suchprefix-Hervorhebung

HandySwiftUI bietet eine elegante Möglichkeit, übereinstimmenden Text in Suchergebnissen hervorzuheben, damit Nutzer sofort sehen, welche Teile des Textes zu ihrer Suchanfrage passen:

struct SearchResultsView: View {
    @State private var searchText = ""
    let translations = [
        "Good morning!",
        "Good evening!",
        "How are you?",
        "Thank you very much!"
    ]

    var body: some View {
        List {
            ForEach(translations.filtered(by: searchText), id: \.self) { translation in
                // Bei Suche nach "go mo" wird "Go mo" in "Good morning!" hervorgehoben
                Text(translation.highlightMatchingTokenizedPrefixes(in: searchText))
            }
        }
        .searchable(text: $searchText)
    }
}

extension [String] {
    func filtered(by searchText: String) -> [String] {
        guard !searchText.isEmpty else { return Array(self) }
        return filter { $0.localizedCaseInsensitiveContains(searchText) }
    }
}

Diese Hervorhebungsfunktion wurde ursprünglich für das „Common Translations”-Feature in der Menüleiste von TranslateKit entwickelt, wo sie Nutzern hilft, passende Phrasen in bestätigten Übersetzungen schnell zu erkennen. Die Funktion zerlegt den Suchtext in Tokens und hebt jeden passenden Prefix hervor – perfekt für:

• Hervorhebung von Suchergebnissen in Listen oder Menüs

• Autocomplete-Vorschläge mit visuellem Feedback

• Filtern durch Textsammlungen mit sichtbarem Trefferkontext

• Bessere Sichtbarkeit von Suchtreffern in Dokumentvorschauen

Die Hervorhebung ist standardmäßig case-insensitive und diakritik-insensitive, aber du kannst die Locale und den Font für die Hervorhebung anpassen. Das macht sie zu einem vielseitigen Werkzeug für jede Suchoberfläche, in der du übereinstimmende Textabschnitte betonen möchtest.

Leg noch heute los

Ich hoffe, du findest diese Extensions genauso nützlich in deinen Projekten wie ich in meinen. Wenn du Ideen für Verbesserungen oder zusätzliche Extensions hast, die der SwiftUI-Community zugutekommen könnten, trage gerne auf GitHub bei:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

Dies ist der dritte von vier Artikeln, die die Features von HandySwiftUI erkunden. Schau dir die vorherigen Artikel über Neue Typen und View Modifier an, falls du sie noch nicht gelesen hast, und bleib dran für den letzten Beitrag über Styles!

In diesem Artikel stelle ich eine Auswahl der View Modifier vor, die sich in meiner täglichen Arbeit an Apps wie TranslateKit, FreemiumKit und CrossCraft am meisten bewährt haben. HandySwiftUI enthält zwar noch viele weitere Hilfsfunktionen, aber diese Modifier haben sich in der Praxis immer wieder als besonders wertvoll erwiesen und könnten auch für deine SwiftUI-Projekte nützlich sein.

Intelligenter Farbkontrast

Der foregroundStyle(_:minContrast:)-Modifier sorgt dafür, dass Text lesbar bleibt, indem er den Farbkontrast automatisch anpasst. Das ist nützlich für dynamische Farben oder Systemfarben wie .yellow, die in bestimmten Farbschemata schlechten Kontrast haben können:

struct AdaptiveText: View {
    @State private var dynamicColor: Color = .yellow

    var body: some View {
        HStack {
            // Ohne Kontrastanpassung
            Text("Maybe hard to read")
                .foregroundStyle(dynamicColor)

            // Mit automatischer Kontrastanpassung
            Text("Always readable")
                .foregroundStyle(dynamicColor, minContrast: 0.5)
        }
    }
}

Dieser Warnungsindikator in TranslateKit nutzt .yellow, stellt aber einen guten Kontrast auch im Light Mode sicher, um lesbar zu bleiben. Im Dark Mode bleibt es gelb.

Der minContrast-Parameter (Bereich von 0 bis 1) bestimmt das minimale Kontrastverhältnis gegenüber Weiß (im Light Mode) oder Schwarz (im Dark Mode) anhand des Luminanzwerts (wahrgenommene Helligkeit). So bleibt Text unabhängig vom aktuellen Farbschema lesbar.

Tasks mit Error-Handling

Der throwingTask-Modifier vereinfacht das asynchrone Error-Handling in SwiftUI-Views. Anders als SwiftUIs eingebauter .task-Modifier, der manuelle do-catch-Blöcke erfordert, bietet throwingTask einen dedizierten Error-Handler-Closure:

struct DataView: View {
    @State private var error: Error?

    var body: some View {
        ContentView()
            .throwingTask {
                try await loadData()
            } catchError: { error in
                self.error = error
            }
    }
}

Der Task verhält sich ähnlich wie .task – er startet, wenn die View erscheint, und wird abgebrochen, wenn sie verschwindet. Der catchError-Closure ist optional, du kannst ihn also weglassen, wenn du Fehler nicht behandeln musst – und füllst damit genau die Lücke, die der task-Modifier offengelassen hat.

Plattformspezifisches Styling

Ein vollständiger Satz plattformspezifischer Modifier ermöglicht präzise Kontrolle über Multi-Platform-UI:

struct AdaptiveInterface: View {
    var body: some View {
        ContentView()
            // Padding nur auf macOS hinzufügen
            .macOSOnlyPadding(.all, 20)
            // Plattformspezifische Styles
            .macOSOnly { $0.frame(minWidth: 800) }
            .iOSOnly { $0.navigationViewStyle(.stack) }
    }
}

Das Beispiel zeigt Modifier für plattformspezifisches Styling:

• .macOSOnlyPadding fügt Padding nur auf macOS hinzu, wo Container wie Form kein Standard-Padding haben

• .macOSOnlyFrame setzt die auf macOS nötigen Mindestfenstergrößen

• Plattform-Modifier (.iOSOnly, .macOSOnly, .iOSExcluded, etc.) sind für iOS, macOS, tvOS, visionOS und watchOS verfügbar und erlauben die gezielte Anwendung von View-Modifikationen auf bestimmten Plattformen

Diese Modifier helfen dir, plattformgerechte Oberflächen zu erstellen und dabei den Code sauber und wartbar zu halten.

Border mit Eckenradius

SwiftUI bietet keinen einfachen Weg, einer View eine Border mit Eckenradius hinzuzufügen. Der Standardansatz erfordert umständlichen Overlay-Code, den man sich schwer merken kann:

Text("Without HandySwiftUI")
    .padding()
    .overlay(
        RoundedRectangle(cornerRadius: 12)
            .strokeBorder(.blue, lineWidth: 2)
    )

HandySwiftUI vereinfacht das mit einem praktischen Border-Modifier:

Text("With HandySwiftUI")
    .padding()
    .roundedRectangleBorder(.blue, cornerRadius: 12, lineWidth: 2)

Badges in TranslateKit nutzen das zum Beispiel für abgerundete Rahmen.

Bedingte Modifier

Eine Reihe von Modifiern für den sauberen Umgang mit bedingten View-Anpassungen:

struct DynamicContent: View {
    @State private var isEditMode = false
    @State private var accentColor: Color?

    var body: some View {
        ContentView()
            // Unterschiedliche Modifier je nach Bedingung anwenden
            .applyIf(isEditMode) {
                $0.overlay(EditingTools())
            } else: {
                $0.overlay(ViewingTools())
            }

            // Modifier nur anwenden, wenn Optional einen Wert hat
            .ifLet(accentColor) { view, color in
                view.tint(color)
            }
    }
}

Das Beispiel zeigt .applyIf, das verschiedene View-Modifikationen basierend auf einer Boolean-Bedingung anwendet, und .ifLet, das wie Swifts if let-Statement funktioniert – es bietet nicht-optionalen Zugriff auf optionale Werte innerhalb des Closures. Beide Modifier helfen, Boilerplate-Code in SwiftUI-Views zu reduzieren.

App-Lifecycle-Handling

Reagiere elegant auf App-Zustandsänderungen:

struct MediaPlayerView: View {
    @StateObject private var player = VideoPlayer()

    var body: some View {
        PlayerContent(player: player)
            .onAppResignActive {
                // Wiedergabe pausieren, wenn die App in den Hintergrund geht
                player.pause()
            }
            .onAppBecomeActive {
                // Zustand wiederherstellen, wenn die App aktiv wird
                player.checkPlaybackState()
            }
    }
}

Diese Modifier arbeiten zusammen, um eine flüssigere und wartbarere SwiftUI-Entwicklung zu ermöglichen, indem sie Boilerplate-Code reduzieren und gleichzeitig Qualität und Konsistenz deiner Benutzeroberfläche verbessern.

Löschbestätigungs-Dialoge

SwiftUIs Bestätigungsdialoge erfordern bei Löschaktionen immer wieder den gleichen Boilerplate-Code, besonders beim Löschen von Elementen aus einer Liste:

struct TodoView: View {
    @State private var showDeleteConfirmation = false
    @State private var todos = ["Buy milk", "Walk dog"]
    @State private var todoToDelete: String?

    var body: some View {
        List {
            ForEach(todos, id: \.self) { todo in
                Text(todo)
                    .swipeActions {
                        Button("Delete", role: .destructive) {
                            todoToDelete = todo
                            showDeleteConfirmation = true
                        }
                    }
            }
        }
        .confirmationDialog("Are you sure?", isPresented: $showDeleteConfirmation) {
            Button("Delete", role: .destructive) {
                if let todo = todoToDelete {
                    todos.removeAll { $0 == todo }
                    todoToDelete = nil
                }
            }
            Button("Cancel", role: .cancel) {
                todoToDelete = nil
            }
        } message: {
            Text("This delete action cannot be undone. Continue?")
        }
    }
}

HandySwiftUI vereinfacht das mit einem dedizierten Modifier:

struct TodoView: View {
    @State private var todoToDelete: String?
    @State private var todos = ["Buy milk", "Walk dog"]

    var body: some View {
        List {
            ForEach(todos, id: \.self) { todo in
                Text(todo)
                    .swipeActions {
                        Button("Delete", role: .destructive) {
                            todoToDelete = todo
                        }
                    }
            }
        }
        .confirmDeleteDialog(item: $todoToDelete) { item in
            todos.removeAll { $0 == item }
        }
    }
}

Puzzle-Löschung in CrossCraft mit einem Bestätigungsdialog, um versehentliches Löschen zu vermeiden.

Das Beispiel zeigt, wie .confirmDeleteDialog den gesamten Lösch-Workflow – von der Bestätigung bis zur Ausführung – mit einem einzigen Modifier abwickelt. Der Dialog wird automatisch in ca. 40 Sprachen lokalisiert und folgt den Plattform-Designrichtlinien. Du kannst einen optionalen message-Parameter angeben, falls du eine andere Nachricht anzeigen möchtest. Es gibt auch eine Overload-Variante, die einen Boolean für Situationen nimmt, in denen keine Liste involviert ist.

Leg noch heute los

Ich hoffe, du findest diese Modifier genauso nützlich in deinen Projekten wie ich in meinen. Wenn du Ideen für Verbesserungen oder zusätzliche Modifier hast, die der SwiftUI-Community zugutekommen könnten, trage gerne auf GitHub bei:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

Dies ist der zweite von vier Artikeln, die die Features von HandySwiftUI erkunden. Schau dir den vorherigen Artikel über Neue Typen an, falls du ihn noch nicht gelesen hast, und bleib dran für die kommenden Beiträge über Extensions und Styles!

In diesem Artikel stelle ich eine Auswahl der neuen Typen vor, die sich in meiner täglichen Arbeit an Apps wie TranslateKit, FreemiumKit und CrossCraft am meisten bewährt haben. HandySwiftUI enthält zwar noch viele weitere Hilfsfunktionen, aber diese Typen haben sich in der Praxis immer wieder als besonders wertvoll erwiesen und könnten auch für deine SwiftUI-Projekte nützlich sein.

Plattformspezifische Werte

HandySwiftUI bietet eine elegante Möglichkeit, plattformspezifische Werte zu handhaben:

struct AdaptiveView: View {
    enum TextStyle {
        case compact, regular, expanded
    }

    var body: some View {
        VStack {
            // Unterschiedliche Zahlenwerte pro Plattform
            Text("Welcome")
                .padding(Platform.value(default: 20.0, phone: 12.0))

            // Unterschiedliche Farben pro Plattform
            Circle()
                .fill(Platform.value(default: .blue, mac: .indigo, pad: .purple, vision: .cyan))
        }
    }
}

Ein ähnliches Erscheinungsbild über Plattformen hinweg für einen Titel in FreemiumKit via .font(Platform.value(default: .title2, phone: .headline)).

Platform.value funktioniert mit jedem Typ – von einfachen Zahlen über Farben und Fonts bis hin zu eigenen Typen. Du gibst einfach einen Standardwert an und überschreibst bei Bedarf bestimmte Plattformen. Das kann enorm nützlich sein, vor allem weil es sogar einen eigenen Case für iPad namens pad gibt – so kannst du Phones und Tablets separat ansprechen.

Das ist mit Abstand mein meistgenutzter HandySwiftUI-Helfer und spart mir massenhaft Boilerplate durch #if-Abfragen. Einfach, aber extrem wirkungsvoll!

Lesbare Preview-Erkennung

Stelle Fake-Daten bereit und simuliere Ladezustände während der Entwicklung:

Task {
   loadState = .inProgress

   if Xcode.isRunningForPreviews {
       // Netzwerkverzögerung in Previews simulieren
       try await Task.sleep(for: .seconds(1))
       self.data = Data()
       loadState = .successful
   } else {
       do {
           self.data = try await loadFromAPI()
           loadState = .successful
       } catch {
           loadState = .failed(error: error.localizedDescription)
       }
   }
}

Xcode.isRunningForPreviews ermöglicht es dir, echte Netzwerk-Requests zu umgehen und stattdessen sofortige oder verzögerte Fake-Antworten nur in SwiftUI-Previews bereitzustellen – perfekt fürs Prototyping und die UI-Entwicklung. Es ist auch nützlich, um begrenzte Ressourcen während der Entwicklung zu schonen, etwa API-Rate-Limits, Analytics-Events, die Statistiken verzerren könnten, oder Services, die pro Request abrechnen – packe diese einfach in eine if !Xcode.isRunningForPreviews-Abfrage.

Effizientes Laden von Bildern

CachedAsyncImage bietet effizientes Laden von Bildern mit eingebautem Caching:

struct ProductView: View {
    let product: Product

    var body: some View {
        VStack {
            CachedAsyncImage(url: product.imageURL)
                .frame(width: 200, height: 200)
                .clipShape(RoundedRectangle(cornerRadius: 10))

            Text(product.name)
                .font(.headline)
        }
    }
}

Beachte, dass .resizable() und .aspectRatio(contentMode: .fill) bereits auf die Image-View im Inneren angewandt werden.

Erweiterte Auswahl-Controls

Mehrere ausgefeilte Picker-Typen für verschiedene Anwendungsfälle:

struct SettingsView: View {
    @State private var selectedMood: Mood?
    @State private var selectedColors: Set<Color> = []
    @State private var selectedEmoji: Emoji?

    var body: some View {
        Form {
            // Vertikaler Option-Picker mit Icons
            VPicker("Select Mood", selection: $selectedMood)

            // Horizontaler Picker mit individuellem Styling
            HPicker("Rate your experience", selection: $selectedMood)

            // Mehrfachauswahl mit plattformadaptiver UI
            MultiSelector(
                label: { Text("Colors") },
                optionsTitle: "Select Colors",
                options: [.red, .blue, .green],
                selected: $selectedColors,
                optionToString: \.description
            )

            // Durchsuchbarer Grid-Picker für Emoji- oder SF-Symbol-Auswahl
            SearchableGridPicker(
                title: "Choose Emoji",
                options: Emoji.allCases,
                selection: $selectedEmoji
            )
        }
    }
}

HandySwiftUI enthält Emoji- und SFSymbol-Enums mit gängigen Emojis und Symbolen. Du kannst auch eigene Enums erstellen, indem du SearchableOption konformierst und searchTerms für jeden Case angibst, um die Suchfunktion zu unterstützen.

Async-State-Management

Verfolge asynchrone Operationen mit typsicherem State-Handling über ProgressState:

struct DocumentView: View {
    @State private var loadState: ProgressState<String> = .notStarted

    var body: some View {
        Group {
            switch loadState {
            case .notStarted:
                AsyncButton("Load Document") {
                    loadState = .inProgress
                    try await loadDocument()
                    loadState = .successful
                } catchError: { error in
                    loadState = .failed(error: error.localizedDescription)
                }

            case .inProgress:
                ProgressView("Loading document...")

            case .failed(let errorMessage):
                VStack {
                    Text("Failed to load document:")
                        .foregroundStyle(.secondary)
                    Text(errorMessage)
                        .foregroundStyle(.red)

                  AsyncButton("Try Again") {
                      loadState = .inProgress
                      try await loadDocument()
                      loadState = .successful
                  } catchError: { error in
                      loadState = .failed(error: error.localizedDescription)
                  }
                }

            case .successful:
                VStack {
                    DocumentContent()
                }
            }
        }
    }
}

Das Beispiel zeigt, wie alle Zustände typsicher behandelt werden:

• .notStarted zeigt den initialen Lade-Button

• .inProgress zeigt einen Ladeindikator

• .failed zeigt den Fehler mit einer Wiederholungsoption

• .successful zeigt den geladenen Inhalt

NSOpenPanel in SwiftUI nutzen

Eine Brücke von nativem macOS-Dateizugriff zu SwiftUI, besonders nützlich für den Umgang mit sicherheitsbezogenen Ressourcen:

struct SecureFileLoader {
    @State private var apiKey = ""

    func loadKeyFile(at fileURL: URL) async {
        #if os(macOS)
        // Auf macOS brauchen wir die Zustimmung des Nutzers für den Dateizugriff
        let panel = OpenPanel(
            filesWithMessage: "Provide access to read key file",
            buttonTitle: "Allow Access",
            contentType: .data,
            initialDirectoryUrl: fileURL
        )
        guard let url = await panel.showAndAwaitSingleSelection() else { return }
        #else
        let url = fileURL
        #endif

        guard url.startAccessingSecurityScopedResource() else { return }
        defer { url.stopAccessingSecurityScopedResource() }

        do {
            apiKey = try String(contentsOf: url)
        } catch {
            print("Failed to load file: \(error.localizedDescription)")
        }
    }
}

Das Beispiel direkt aus FreemiumKit zeigt, wie OpenPanel den Umgang mit sicherheitsbezogenem Dateizugriff für gezogene Elemente auf macOS vereinfacht und dabei die plattformübergreifende Kompatibilität beibehält.

Vertikale Tab-Navigation

Eine Alternative zu SwiftUIs TabView, die eine Sidebar-Navigation implementiert, wie sie häufig in macOS- und iPadOS-Apps zu sehen ist:

struct MainView: View {
    enum Tab: String, CaseIterable, Identifiable, CustomLabelConvertible {
        case documents, recents, settings

        var id: Self { self }
        var description: String {
            rawValue.capitalized
        }
        var symbolName: String {
            switch self {
            case .documents: "folder"
            case .recents: "clock"
            case .settings: "gear"
            }
        }
    }

    @State private var selectedTab: Tab = .documents

    var body: some View {
        SideTabView(
            selection: $selectedTab,
            bottomAlignedTabs: 1  // Platziert Einstellungen unten
        ) { tab in
            switch tab {
            case .documents:
                DocumentList()
            case .recents:
                RecentsList()
            case .settings:
                SettingsView()
            }
        }
    }
}

SideTabView bietet eine vertikale Sidebar mit Icons und Labels, optimiert für größere Bildschirme mit Unterstützung für am unteren Rand angeordnete Tabs. Die View übernimmt automatisch das plattformspezifische Styling und Hover-Effekte.

Leg noch heute los

Ich hoffe, du findest diese Typen genauso nützlich in deinen Projekten wie ich in meinen. Wenn du Ideen für Verbesserungen oder zusätzliche Typen hast, die der SwiftUI-Community zugutekommen könnten, trage gerne auf GitHub bei:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

Dies ist der erste von vier Artikeln, die die Features von HandySwiftUI erkunden. Bleib dran für die kommenden Beiträge über View Modifier, Extensions und Styles!

In seinem Artikel beschreibt Ole einen unkomplizierten Ansatz, Swift-Code in einer Linux-Umgebung mit einem einzigen Befehl auszuführen. Du musst dafür lediglich die kostenlose Docker Desktop App auf deinem Mac installieren. Aber der Befehl schien mir recht lang und schwer zu merken, also wollte ich das Ganze noch weiter vereinfachen. Am Ende hatte ich einen Ansatz, bei dem ich mir nur swift-linux merken musste. So geht’s:

Den Docker-Befehl vereinfachen

Zunächst habe ich Oles Befehl für Kürze weiter vereinfacht:

docker run --rm -it -v "$(pwd):/src" -w "/src" swift

Erklärung des Befehls (falls es dich interessiert):

• docker run: Dieser Befehl erstellt und startet einen Container.

• --rm: Entfernt den Container automatisch, wenn er beendet wird.

• -it: Führt den Container im interaktiven Modus mit angeschlossenem Terminal aus.

• -v "$(pwd):/src": Bindet das aktuelle Verzeichnis ($(pwd)) an /src im Container ein, sodass du auf deine Swift-Dateien zugreifen kannst.

• -w "/src": Setzt das Arbeitsverzeichnis im Container auf /src.

• swift: Gibt das zu verwendende Swift-Docker-Image an.

Beachte, dass ich auch die Option --privileged aus Oles Befehl aus Sicherheitsgründen entfernt habe, da sie zum Testen von Swift Packages selten benötigt wird.

Einen praktischen Alias hinzufügen

Um das Ausführen dieses Befehls einfacher zu machen, habe ich einen Alias zu meiner ~/.zshrc-Datei hinzugefügt (z.B. über touch ~/.zshrc). Das ist eine Konfigurationsdatei für die Zsh-Shell, die heutzutage die Standard-Shell auf macOS ist. So geht’s:

• Terminal öffnen

• Die ~/.zshrc-Datei bearbeiten Du kannst TextEdit verwenden, den vorinstallierten Texteditor auf macOS. Führe einfach aus: open ~/.zshrc

• Den Alias hinzufügen Scrolle zum Ende der Datei und füge die folgende Zeile hinzu:

alias swift-linux='docker run --rm -it -v "$(pwd):/src" -w "/src" swift'

• Datei speichern und schließen

• Änderungen anwenden Führe den folgenden Befehl aus, um deine Konfigurationsdatei neu zu laden: source ~/.zshrc

Befehle in einer Linux-Umgebung ausführen

Jetzt, da der Alias eingerichtet ist, kannst du deinen Swift-Code ganz einfach direkt von deinem Mac aus in einer Linux-Umgebung testen. Navigiere einfach im Terminal zu deinem Projektverzeichnis und führe aus:

swift-linux

Beim ersten Mal dauert der Download des Linux-Containers etwas.

Dieser Befehl versetzt dich in eine Linux-Umgebung, in der du je nach Bedarf swift build oder swift test ausführen kannst. Tippe einfach exit ein, um zu deinem Mac zurückzukehren. So kannst du schnell überprüfen, ob alles wie erwartet funktioniert, und Fehler erkennen, bevor du auf deinen Server deployest.

Und alles, was du dir merken musst, ist swift-linux!

Warum ich LinksKit gebaut habe

Nach dem Launch mehrerer Apps auf verschiedenen Apple-Plattformen ist mir ein Muster aufgefallen. Jede App brauchte ähnliche Link-Bereiche:

1. Rechtliche Links (Datenschutzrichtlinie, Nutzungsbedingungen)

2. Support-Links (FAQs, Kontakt-E-Mail)

3. App-Review-Deep-Link

4. Social-Media-Links

5. Cross-Promotion für meine anderen Apps

Diese Links zu implementieren wurde zu einem zeitaufwändigen und repetitiven Prozess. Und auf dem Mac war alles ganz anders, was zusätzliche Arbeit für Multi-Plattform-Apps bedeutete. Da wurde mir klar, dass ich eine wiederverwendbare Lösung brauchte, und LinksKit war geboren.

Warum jede neue App LinksKit nutzen sollte

1. Zeitersparnis: LinksKit bietet eine sofort einsetzbare Lösung für gängige Link-Anforderungen, sodass sich Entwickler auf die Kernfunktionen der App konzentrieren können.

2. Compliance: Es stellt sicher, dass deine App alle notwendigen rechtlichen Links enthält und hilft dir, die App-Store-Richtlinien mühelos einzuhalten.

3. Cross-Promotion: LinksKit macht es einfach, deine anderen Apps zu präsentieren und so die Sichtbarkeit deines gesamten App-Portfolios zu steigern.

4. Networking-Möglichkeiten: Das Package ermöglicht es dir, Apps von befreundeten Entwicklern zu bewerben, was eine unterstützende Community und potenzielle Cross-Promotion-Partnerschaften fördert.

5. Anpassbarkeit: Neben den vorgefertigten Lösungen bietet LinksKit auch volle Anpassungsmöglichkeiten für deine spezifischen Bedürfnisse.

6. Plattform-Anpassung: Es funktioniert nahtlos auf iOS, macOS und visionOS und passt sich den UI-Konventionen jeder Plattform an.

So verwendest du LinksKit

Der Einstieg mit LinksKit ist unkompliziert, aber bevor wir in den Code eintauchen, besprechen wir ein wichtiges Konzept: den providerToken.

Den providerToken verstehen

Der providerToken ist eine entscheidende Komponente in App-Store-Marketingkampagnen. Es handelt sich um eine eindeutige Kennung für dein Entwicklerkonto, die dabei hilft, die Wirksamkeit deiner Marketingmaßnahmen zu verfolgen. Wenn Nutzer auf Links mit deinem providerToken klicken, kann Apple diese Klicks deinen Kampagnen zuordnen und wertvolle Einblicke in die Nutzergewinnung deiner App liefern. Das Wort “Kampagne” klingt übertrieben kompliziert, aber es ist eigentlich nur ein Parameter, der angibt, woher die Nutzer kommen.

So findest du deinen providerToken

Den providerToken zu finden ist nicht sofort offensichtlich, aber so geht’s:

1. Melde dich bei App Store Connect an

2. Navigiere zu Analytics > Acquisition > Campaigns

3. Klicke auf “Create Campaign Link”

4. Gib einen beliebigen Text in das Formular ein (du musst nicht wirklich eine Kampagne erstellen)

5. In der Kampagnen-Link-Vorschau suchst du den Parameter pt – der Wert nach pt= ist dein providerToken

Merke dir: Dieser Token ist für alle deine Apps gleich, du musst ihn also nur einmal nachschlagen.

Grundkonfiguration

Jetzt, da du den providerToken verstehst, richten wir LinksKit in deiner App ein:

LinksKit.configure(
   providerToken: "123456",
   linkSections: [
      .helpLinks(appID: "123456789", supportEmail: "support@example.com"),
      .legalLinks(privacyURL: URL(string: "https://example.com/privacy")!)
   ]
)

Diese grundlegende Einrichtung fügt deiner App die wesentlichen Hilfe- und Rechts-Links hinzu, einschließlich der Nutzungsbedingungen.

Umfassendes Beispiel

Schauen wir uns ein umfassenderes Beispiel an, das alle integrierten Features von LinksKit zeigt – mit Social-Links und Links zu deinen Apps und den Apps deiner Freunde:

// App-Links
let ownApps = LinkSection(entries: [
   .link(.ownApp(id: "6502914189", name: "FreemiumKit", systemImage: "cart")),
   .link(.ownApp(id: "6480134993", name: "FreelanceKit", systemImage: "timer")),
   .link(.ownApp(id: "6472669260", name: "CrossCraft", systemImage: "puzzlepiece")),
   .link(.ownApp(id: "6477829138", name: "FocusBeats", systemImage: "music.note")),
])

let friendsApps = LinkSection(entries: [
   .link(.friendsApp(id: "1249686798", name: "NFC.cool Tools", systemImage: "tag", providerToken: "106913804")),
   .link(.friendsApp(id: "6503256642", name: "App Exhibit", systemImage: "square.grid.3x3.fill.square")),
])

// LinksKit konfigurieren
LinksKit.configure(
   providerToken: "549314",
   linkSections: [
      .helpLinks(
         appID: "6476773066",
         faqURL: URL(string: "https://translatekit.app/#faq")!,
         supportEmail: "translatekit@fline.dev"
      ),
      .socialMenus(
         appLinks: .appSocialLinks(
            platforms: [.twitter, .mastodon(instance: "mastodon.social"), .threads],
            handle: "TranslateKit",
            handleOverrides: [.twitter: "TranslateKitApp"]
         ),
         developerLinks: .developerSocialLinks(
            platforms: [.twitter, .mastodon(instance: "iosdev.space"), .threads],
            handle: "Jeehut"
         )
      ),
      .appMenus(ownAppLinks: [ownApps], friendsAppLinks: [friendsApps]),
      .legalLinks(privacyURL: Constants.legalPrivacyPolicyURL)
   ]
)

Die obige Konfiguration habe ich (vereinfacht) aus meiner App TranslateKit übernommen:

1. Richtet Hilfe-Links mit FAQ und Support-E-Mail ein

2. Fügt Social-Media-Links sowohl für die App als auch den Entwickler hinzu

3. Erstellt ein Menü zur Bewerbung meiner anderen Apps

4. Enthält einen Bereich für die Apps von Freunden (großartig fürs Networking!)

5. Stellt sicher, dass alle notwendigen rechtlichen Links vorhanden sind

Um diese konfigurierten Links zu verwenden, füge einfach LinksView() zu deinem Einstellungsbildschirm hinzu:

Form {
   // Andere Einstellungen...
   LinksView()
}

Das Ergebnis sieht auf iOS etwa so aus:

Auf dem Mac ist es üblicher, Links im Hilfe-Menü zu platzieren. So geht’s:

WindowGroup {
   // dein UI-Code
}
.commands {
   CommandGroup(replacing: .help) {
      LinksView()
         .labelStyle(.titleAndIcon)
   }
}

Es erscheint dann so im Menü:

Eigene Link-Bereiche

Neben den vorgefertigten Bereichen kannst du mit LinkSection auch komplett eigene Bereiche erstellen. Diese Flexibilität ermöglicht es dir, beliebige Link-Typen oder verschachtelte Menüstrukturen hinzuzufügen.

Hier ein Beispiel für einen eigenen Bereich:

let customSection = LinkSection(
    title: "Custom Links",
    entries: [
        .link(Link(title: "Our Website", systemImage: "globe", url: URL(string: "https://www.example.com")!)),
        .menu(LinkMenu(
            title: "Social Media",
            systemImage: "network",
            linkSections: [
                LinkSection(entries: [
                    .link(Link.followUsOn(socialPlatform: .twitter, handle: "YourAppHandle")),
                    .link(Link.followUsOn(socialPlatform: .instagram, handle: "YourAppHandle"))
                ])
            ]
        ))
    ]
)

Dieses Beispiel zeigt, wie du Menüs verschachteln und eine Hierarchie von Links erstellen kannst, die zu den Anforderungen deiner App passt.

Eigene Label-Styles

LinksKit bietet Flexibilität nicht nur beim Inhalt, sondern auch bei der Darstellung. Du kannst das Erscheinungsbild deiner Links ganz einfach mit SwiftUIs labelStyle-Modifier anpassen. LinksKit stellt drei eigene Label-Styles bereit, um die visuelle Gestaltung deiner Links zu verbessern:

1. .titleAndTrailingIcon: Ähnlich dem Standard-.titleAndIcon-Style, aber platziert das Icon am Ende des Labels.

2. .titleAndIconBadge(color:): Imitiert den Style von Apples Einstellungen-App, indem den führenden Icons ein farbiger Hintergrund hinzugefügt wird.

3. .titleAndTrailingIconBadge(color:): Kombiniert die Icon-Platzierung am Ende mit dem farbigen Hintergrund.

Um diese Styles anzuwenden, füge einfach den labelStyle-Modifier zu deiner LinksView hinzu:

LinksView()
    .labelStyle(.titleAndIconBadge(color: .blue))

Diese einfache Anpassung kann das Erscheinungsbild deiner Links deutlich verändern und dir ermöglichen, sie an die Design-Sprache deiner App anzupassen oder eine klare visuelle Hierarchie zu schaffen. Hier ein visueller Vergleich dieser Styles:

Durch den Einsatz eigener Label-Styles kannst du einen einzigartigen und ausgefeilten Look für den Link-Bereich deiner App schaffen und so die gesamte Nutzererfahrung verbessern.

Fazit

LinksKit ist mehr als nur ein zeitsparendes Tool – es ist eine umfassende Lösung für die Verwaltung von App-Links, die Einhaltung rechtlicher Vorgaben und die Förderung von Entwickler-Networking. Indem es alles von rechtlichen Anforderungen bis hin zu Cross-Promotion abdeckt, ermöglicht dir LinksKit, dich auf das zu konzentrieren, was wirklich zählt – großartige Apps zu entwickeln.

Egal ob du ein erfahrener Entwickler mit mehreren Apps bist oder gerade dein erstes Projekt startest, LinksKit kann deinen Entwicklungsprozess erheblich vereinfachen. Probiere es in deinem nächsten Projekt aus und erlebe die Vorteile eines vereinfachten Link-Managements auf allen Apple-Plattformen! Ich hoffe, es hilft dir weiter.

github.comFlineDev / LinksKitSwiftUI convenience view to show common links in apps settings/help menu

Ich hatte mehrere einzigartige App-Ideen, aber mir fehlten die APIs, die diese Konzepte überhaupt erst umsetzbar gemacht hätten. Ich hätte mehr Apps veröffentlicht, wenn visionOS die nötigen Werkzeuge für die AR/VR-Erlebnisse geliefert hätte, die das Gerät verspricht. Es geht mir dabei nicht um eine offenere Plattform wie macOS – ich verstehe den Wert der Sicherheit und Einfachheit im iOS/iPadOS-Ökosystem. Doch visionOS fühlt sich an wie iPadOS mit anderen Eingabemethoden. Was fehlt, sind einzigartige APIs, die speziell dafür entwickelt wurden, die immersiven Erlebnisse voll auszuschöpfen, die die Vision Pro bieten kann.

Hier sind die fünf APIs, die meiner Meinung nach visionOS von einem vielversprechenden Experiment in eine Plattform verwandeln könnten, für die es sich wirklich lohnt zu entwickeln:

1. Magnetisches Anheften von Fenstern und Objekten an Oberflächen

Foto von Kristyna Squared.one / Unsplash

Stell dir vor, du könntest Fenster oder 3D-Objekte an Wänden oder Möbeln in einem Raum anheften – dauerhaft. Dieses Feature würde es Nutzern ermöglichen, persistente Setups in ihrer Umgebung zu erstellen, und Entwicklern die Möglichkeit geben, die Anheftungsfunktion je nach Kontext ihres Erlebnisses ein- und auszuschalten. Zum Beispiel würde meine Posters-App dann endlich Sinn ergeben! Noch wichtiger: Diese angehefteten Objekte sollten auch nach einem Systemneustart an Ort und Stelle bleiben, ähnlich wie Desktop-Umgebungen oder Fokusmodi. Diese Funktionalität sollte sich auch über verschiedene Nutzer hinweg erstrecken – beim Wechsel in den Gastmodus sollten alle angehefteten Elemente genau dort bleiben, wo sie platziert wurden.

Derzeit fühlt sich die Erweiterung der Realität auf der Vision Pro vorübergehend an, weil diese API fehlt, was sie eher zu einem reinen VR-Gerät macht – und ich glaube nicht, dass das Apples Vision für die Plattform ist. Diese Einschränkung begrenzt das volle Potenzial von Mixed-Reality-Erlebnissen, da Nutzer sich nicht darauf verlassen können, dass ihre digitalen Objekte an ihrem Platz im physischen Raum bleiben. Die Möglichkeit, Fenster und Objekte magnetisch anzuheften, ist daher die wichtigste API, die nötig ist, um die Vision Pro über ein VR-Erlebnis hinauszuheben und ihr wahres Mixed-Reality-Potenzial zu verwirklichen.

2. Erweitertes Raum-Scanning mit editierbaren 3D-Modellen

Foto von Dynamic Wang / Unsplash

Eine hybride API, die die Leistung von RoomPlan und dem auf iOS verfügbaren 3D-Scanner kombiniert, könnte die Möglichkeiten von Entwicklern zur Erstellung immersiver Inhalte revolutionieren. Während das Scannen eines Raums derzeit möglich ist, fehlt die nötige Tiefe für vollständig interaktive Räume. Der nächste Schritt sollte es ermöglichen, nicht nur die Abmessungen, sondern auch die Farben und Texturen zu erfassen, um hochdetaillierte 3D-Modelle zu erzeugen.

Warum sind diese Scanning-APIs nicht auf der Apple Vision Pro verfügbar? Sie benötigen einen LiDAR-Sensor, den die Vision Pro hat. Die Erstellung auf der Vision Pro wäre komfortabler und würde es Nutzern ermöglichen, die Ergebnisse sofort in 3D zu sehen. Idealerweise könnte Apple auch eine App für Entwickler bereitstellen, um diese Umgebungen direkt in der Vision Pro mit Handgesten zu bearbeiten. Wenn ich zum Beispiel einen Tisch verschiebe und den Raum erneut scanne, sollte das System die Änderung erkennen und den Tisch als bewegliches Objekt behandeln. Apples KI-Tools könnten Lücken mit realistischen Texturen und Objekten füllen, die 3D-Umgebungserstellung intuitiver machen und den Bedarf an komplexen CAD-Tools reduzieren.

3. Eine Skelett-Erkennungs-API für spaßige AR-Interaktionen

Eine meiner liebsten App-Ideen beinhaltete die Erkennung von Körperteilen mithilfe von Apples AR-Frameworks, um ein bisschen Die Sims in die reale Welt zu bringen. Stell dir vor, du gehst herum und siehst einen schwebenden grünen Diamanten (wie den Plumbob aus den Sims) über jeder Person, der es dir ermöglicht, auf einzigartige und spielerische Weise mit ihnen zu interagieren. Um das möglich zu machen, wäre eine einfache Skelett-Tracking-API ein Gamechanger, die es Entwicklern ermöglichen würde, Körperbewegungen und Gesten zu erkennen. Selbst eine grobe Schätzung der Kopfposition oder Armbewegung könnte Features wie interaktive Sprechblasen ermöglichen, basierend auf dem, was jemand sagt oder fühlt. Fortgeschrittene APIs könnten Gesichtsausdrücke erkennen und so die Möglichkeit für schwebende Emotions-Icons oder Interaktionsvorschläge schaffen, ähnlich wie in Die Sims.

Ich verstehe, dass Apple keinen vollen Kamerazugriff gewähren möchte – und ehrlich gesagt würde ich die Vision Pro auch nicht nutzen, wenn sie es täten. Da die Kamera aber bereits an ist, könnte das System erkannte Weltinformationen teilen, die die Privatsphäre der Nutzer respektieren und gleichzeitig solche Erlebnisse ermöglichen. Es gibt noch viel ungenutztes Potenzial, das AR-Interaktionen deutlich verbessern könnte.

4. Interaktive räumliche 360°- und 180°-Videoelemente

Foto von Roger Ce / Unsplash

Während die Vision Pro immersive Video-Erlebnisse verspricht, ist es derzeit unmöglich, interaktive Buttons oder Objekte in diese räumlichen 180°/360°-Videos zu integrieren. Entwickler sollten in der Lage sein, klickbare Elemente im Raum zu platzieren, während man sich in einem Video befindet – stell dir interaktive Touren oder geführte Erlebnisse vor, bei denen Nutzer auf Objekte klicken können, um mehr Informationen zu erhalten oder zwischen Videos zu wechseln, die verschiedene Zeiten oder Perspektiven zeigen.

Dieses Feature könnte es Nutzern auch ermöglichen, innerhalb eines Ortes zu „Zeitreisen”, indem sie nahtlos zwischen Videoaufnahmen desselben Ortes zu verschiedenen Zeiten wechseln. Derzeit erfordern solche Interaktionen das mühsame Erstellen von 3D-Umgebungen von Grund auf. Eine einfache API zum Platzieren interaktiver Elemente in Videos würde den Prozess enorm vereinfachen und endlose Möglichkeiten für interaktives Storytelling, Bildungstools und mehr eröffnen. Aktuell ist viel Aufwand nötig, um auch nur annähernd ein solches Erlebnis zu schaffen, einschließlich des Baus eines eigenen Videoplayers in RealityKit mit verschiedenen Bildern für jedes Auge. Solche Hacks sollten nicht nötig sein.

5. Die Welt entdecken: Die Zukunft von Apple Maps

Foto von Jezael Melgoza / Unsplash

Eine der überraschendsten Lücken in visionOS ist das Fehlen einer nativen Maps-App, die für die Vision Pro optimiert ist. Während Umsehen auf anderen Geräten immersive Straßenansichten bietet, könnte die Vision Pro dieses Erlebnis auf ein neues Level heben, indem Nutzer direkt in 3D-Umgebungen versetzt werden, in denen sie in Echtzeit mit ihrer Umgebung interagieren können. Apples KI-Technologie, die Fotos in 3D-Szenen verwandelt, könnte genutzt werden, um die bestehenden Umsehen-Bilder in interaktive Umgebungen umzuwandeln und neue Möglichkeiten für immersive, standortbasierte Apps zu erschließen.

Eine richtige Vision Pro Maps-API könnte dieses Erlebnis komplett verändern. Stell dir vor, du gehst (oder besser gesagt beamst dich) durch eine Stadt und interagierst mit virtuellen Objekten, die an bestimmte Orte gebunden sind – sei es für ein Spiel, zu Bildungszwecken oder sogar einen immersiven Reiseplaner. Entwickler könnten Erlebnisse schaffen, bei denen Nutzer durch historische Rekonstruktionen navigieren, zukünftige Stadtpläne erkunden oder mit dynamischen Inhalten interagieren, während sie durch die Straßen streifen.

Der Schlüssel zum Erfolg der Vision Pro

Foto von Razvan Chisu / Unsplash

Das sind genau die Art von APIs, die nicht nur Entwickler wie mich bei visionOS halten würden, sondern auch die Erstellung immersiverer und fesselnderer Inhalte vorantreiben würden. Im Moment fehlen der Vision Pro die Killer-Apps, die Nutzer zum Kauf bewegen, und ohne genügend Nutzer zögern Entwickler, signifikant Zeit in die Plattform zu investieren. Es ist ein Kreislauf, der durchbrochen werden muss, und die Lösung liegt auf der Hand – Apple muss die Inhaltserstellung für Entwickler so einfach wie möglich machen.

Ich verlange kein offenes System oder realitätsferne Features – ich verlange APIs, die das echte Potenzial der Vision Pro für Entwickler und Nutzer gleichermaßen entfesseln können. Ohne sie ist es schwer zu sehen, wie die Plattform die nötige Dynamik gewinnen soll. Aber wenn Apple auch nur einige dieser APIs einführt, wäre ich sofort bereit, wieder einzusteigen und Apps zu bauen, die die Grenzen von AR und VR verschieben könnten – und die Vision Pro letztlich zu dem bahnbrechenden Gerät machen, das sie sein sollte.

Ich arbeite seit etwa anderthalb Jahren an einer Diabetes-Management-App, die ich Glu Sight genannt habe. Als der Veröffentlichungstermin näher rückte, musste ich anfangen, Features zu reduzieren, lose Enden zusammenzuführen und mich endlich auf das Release vorzubereiten. Nicht alles muss vom ersten Tag an fertig sein, erinnerte ich mich. Manche Features können warten, aber mit einem soliden Fundament zu launchen war essentiell. Und genau hier kam mein Entscheidungsprozess bezüglich der Handhabung von In-App-Abos und -Käufen ins Spiel.

RevenueCat: Ein schwieriger Start

Als ich an dem Punkt war, In-App-Käufe zu integrieren, hörte ich massenhaft Positives über RevenueCat. Es schien die Lösung schlechthin für App-Entwickler zu sein, besonders mit seinen leistungsstarken Features und seinem Ruf in der Community. Also zog ich natürlich in Betracht, RevenueCat oder die StoreKit-2-API direkt zu verwenden. Ich wandte mich an andere, die RevenueCat benutzt hatten, um Tipps für den Einstieg zu bekommen.

Was ich allerdings schnell feststellte, war, dass der anfängliche Einrichtungsprozess für RevenueCat deutlich herausfordernder war als erwartet. Die Abläufe waren komplex, und um die Sache noch schlimmer zu machen, war die Dokumentation genau dort lückenhaft, wo ich am dringendsten Hilfe brauchte. Die Grundeinrichtung kostete Zeit und fühlte sich wie ein Kampf an, besonders weil ich schon unter Druck stand, meine App startfertig zu machen. Ich habe es zwar irgendwie durch die Einrichtung geschafft, aber die angenehmste Erfahrung war es nicht.

FreemiumKit entdecken: Eine Erleichterung

Dann stieß ich auf FreemiumKit. Nachdem ich einige positive Bewertungen gelesen hatte, beschloss ich, es auszuprobieren. Von Anfang an fiel mir ein deutlicher Unterschied auf. Die Einrichtung mit FreemiumKit war unglaublich einfach. Ich konnte es viel schneller in meine App integrieren als jede andere Lösung, die ich ausprobiert hatte. Die SDK-Integrationsdokumentation war glasklar – einmal lesen und ich war startklar. Es fühlte sich an, als würde einfach alles zusammenpassen.

FreemiumKit machte nicht nur den Einrichtungsprozess einfach – es kam auch vollgepackt mit smarter Automatisierung und Standardwerten, die sofort mit App Store Connect funktionierten. Und trotzdem bot es die Flexibilität, alles an meine speziellen Bedürfnisse anzupassen. Das Pricing stimmte auch, besonders für einen App-Entwickler wie mich, der gerade erst anfängt. Der Support von den Entwicklern? Herausragend. Ich hatte einen Call mit dem Entwickler, der sich als eine großartige Erfahrung herausstellte. Er führte mich durch den Prozess, und innerhalb von 45 Minuten hatte ich Klarheit über Aspekte von In-App-Käufen, die selbst Apples Dokumentation nicht im Detail abdeckte.

Der Einfluss auf meinen Entwicklungsprozess

Der Wechsel zu FreemiumKit hatte einen unglaublichen Einfluss auf meinen Entwicklungsprozess. Ich konnte eine erhebliche Menge an Code aufräumen und Extra-Klassen sowie unnötige Komplexität entfernen, die RevenueCat erfordert hatte. Dieses Aufräumen war nicht nur kosmetisch – es machte meine App effizienter und einfacher zu verwalten. Das ganze RevenueCat-Zeug war weg, ersetzt durch FreemiumKit, und ich war begeistert.

Eingebaute SDK-Komponenten wie PaidFeatureView und PaidStatusView waren unglaublich anpassbar und ermöglichten es mir, mich auf die User Experience zu konzentrieren, ohne mir über die technischen Details den Kopf zu zerbrechen. Statt ein ganzes ViewModel für die Handhabung von In-App-Käufen schreiben zu müssen, konnte ich einen Einzeiler von FreemiumKit verwenden. Das gab mir die Freiheit, mich auf das zu konzentrieren, was wirklich zählt: eine großartige App zu bauen.

Darüber hinaus machte FreemiumKit die einschüchternden Aspekte von StoreKit2 handhabbar. Durch das Experimentieren mit FreemiumKit gewann ich ein besseres Verständnis von StoreKit2, was ein enormer Mehrwert war. Es verwandelte etwas, das wie eine überwältigende Aufgabe schien, in etwas Angenehmes und sehr Lehrreiches.

Ein klarer Weg zum Launch

Rückblickend war der Hauptgrund, warum ich meine App nicht früher gelauncht hatte, der überwältigende Aufwand zur Integration von RevenueCat. Ich hatte angefangen, die Paywall zu bauen und alles zu programmieren, aber die Komplexität hatte mich aufgerieben. Am Ende prokrastinierte ich, weil es sich nach zu viel Arbeit anfühlte, diesen Teil der App noch mal anzufassen.

FreemiumKit änderte das alles. Es ermöglichte mir, mich sowohl auf die Entwicklung neuer Features zu konzentrieren als auch die Abo-Verwaltung ohne Angst zu integrieren. Ich schaffte es sogar, Änderungen an meinen Testzeiträumen in App Store Connect vorzunehmen, und FreemiumKit übernahm alles nahtlos. Die Angst und die „Entwicklerblockade” waren verschwunden, und ich freute mich wieder darauf, meinen Launch-Tag zu erreichen.

Abschließende Gedanken

FreemiumKit war ein Gamechanger für mich. Es hat nicht nur meinen Entwicklungsprozess vereinfacht, sondern auch meine Leidenschaft für den Launch von Glu Sight neu entfacht. Die Einrichtung war reibungslos, die Dokumentation erstklassig und der Support von den Entwicklern unglaublich. Für alle, die vor ähnlichen Herausforderungen bei der In-App-Kauf-Verwaltung stehen – ich kann FreemiumKit nur wärmstens empfehlen. Es hat mir geholfen, die Hindernisse zu überwinden, die RevenueCat mir in den Weg gelegt hatte, und mich darauf zu konzentrieren, ein Produkt abzuliefern, auf das ich stolz bin.

Während ich mich dem Launch im September 2024 nähere, bin ich aufgeregt und bereit – dank FreemiumKit. Ich habe auf dem Weg neue Freunde gewonnen, eine Menge gelernt und – am wichtigsten – ich bin endlich auf dem Weg, anderen zu helfen, ihr Diabetes einfacher zu managen.

Bleibt dran für den Launch!

👨‍💻 Verpasse nicht den Launch-Beitrag! Folge mir auf Threads und Mastodon.

💁 Hat dir dieser Artikel gefallen? Schau dir FreemiumKit an! Einfache In-App-Käufe mit Paywalls, A/B-Tests und Live-Push! Jetzt holen oder das Video-Setup-Tutorial ansehen, um es in Aktion zu sehen.

Pleydia Organizer ordnet Filme nach Drag & Drop automatisch zu

Mühelose Organisation mit Drag & Drop

Deine Medienbibliothek zu organisieren war noch nie so einfach. Mit Pleydia Organizer ziehst du deine TV- oder Filmdateien einfach per Drag & Drop in die App, und sie durchsucht automatisch The Movie Database (TMDb), um deine Dateien korrekt zu identifizieren und zuzuordnen. Ein weiterer Klick, und alle deine Dateien werden in ordentliche, standardisierte Dateinamen umbenannt – ohne seltsame Zeichen oder Formatierungsprobleme.

Pleydia Organizer nach dem Umbenennen zugeordneter TV-Episoden-Dateien

Warum Pleydia Organizer anderen Tools vorziehen?

Pleydia Organizer hebt sich von anderen Umbenennungs-Tools wie FileBot ab:

• Blitzschneller App-Start: Pleydia Organizer startet fast sofort, während FileBot auf einem M1 Pro Mac etwa 10 Sekunden braucht.

• Genaue Film-Zuordnung: Pleydia Organizer glänzt bei der Film-Zuordnung, besonders wenn internationale Erscheinungsjahre von denen in deinem Land abweichen.

• Präzise TV-Episoden-Zuordnung: Die App behandelt Sonderfälle bei der Staffelgruppierung von Serien besser, etwa bei Animes wie One Piece, wo Episoden wöchentlich erscheinen – ein Bereich, in dem FileBot Schwierigkeiten hat.

• Gespeicherte TV-Serien-Auswahl: Pleydia Organizer merkt sich deine Staffelgruppierungswahl für Serien und erspart dir wiederholte Auswahl bei jeder Nutzung.

• Kostenloses Umbenennen: Du kannst einzelne Dateien kostenlos umbenennen, was die App für Gelegenheitsnutzer zugänglich macht. FileBot erfordert selbst für eine einzige Datei einen Kauf.

• Günstiger Multi-Datei-Support: Wenn du Multi-Datei-Support brauchst, kostet er die Hälfte von FileBot – eine wirtschaftliche Wahl für größere Bibliotheken.

• Drag & Drop-Einfachheit: Anstatt dass du die App erst erlernen und viele Buttons klicken musst, ist Pleydia Organizer super einfach zu bedienen.

Schau dir an, wie einfach es in Aktion ist, in diesem GIF:

Ziehe deine Dateien einfach per Drag & Drop in Pleydia Organizer, und die Zuordnung erfolgt automatisch.

Wenn du deinen eigenen Plex-, Kodi-, Jellyfin- oder Infuse-Medienserver hast, ist Pleydia Organizer definitiv einen Versuch wert. Lade es sicher aus dem Mac App Store herunter:

Pleydia Organizer: File Rename

Ich freue mich über jedes Feedback – lass mich doch wissen, wenn du auf Probleme stößt!

Ein Nutzer, der seine Gefühle in einer negativen App-Store-Bewertung ausdrückt.

Es ist wirklich schwer, der Versuchung zu widerstehen, einfach ihrer Forderung nachzugeben und den Preis zu senken. Und ich konnte nicht immer widerstehen, wie du hier sehen kannst:

Ein Nutzer auf Reddit beschwert sich über den Preis einer Einmalkauf-App.

Ich bin eben auch nur ein Mensch und ich möchte, dass den Leuten gefällt, was ich mache. Aber ich muss als Indie-Entwickler auch Geld verdienen, sonst kann ich die App nicht weiter verbessern. Es liegt also sogar im Interesse der Nutzer, dass ich einen fairen Preis ansetze – nicht nur in meinem. Aber was ist fair?

„Faire” Preisgestaltung

Man kann das aus vielen verschiedenen Perspektiven betrachten.

Aus wirtschaftlicher Sicht sollte mein Ziel sein, meine Einnahmen zu maximieren. Wenn du nach einem Artikel über verschiedene Strategien dafür suchst, liest du besser einen Artikel wie diesen hier. Für mich ist Profit nur ein Mittel, um mich motiviert zu halten, weiter Apps zu bauen. Er ist nicht das Ziel. Die User Experience ist alles, was zählt. Und Probleme lösen. Ein fairer Preis gehört für mich zu einer guten UX dazu.

Eine reine Entwickler-Perspektive könnte sein, eine App nach dem Aufwand zu bepreisen, der nötig war, um sie zu bauen. Klingt fair, oder? Aber das funktioniert nicht in einem freien Markt. Und das aus gutem Grund! Was, wenn du etwas super Komplexes, aber total Irrelevantes gebaut hast? Warum sollte jemand dafür einen hohen Preis zahlen? Würdest du das?

Das bringt mich dazu, wie ich meine Anfangspreise meistens wähle: Was würde ich zahlen, wenn diese App von jemand anderem gebaut wäre und ich sie einfach nutzen wollte? Da ich ausschließlich Apps baue, die ich selbst brauche, bin ich auch Kunde! Es ist also quasi eine Ein-Personen-Kundenrecherche, auf der meine anfängliche Preisgestaltung basiert. Aber ist das eine gute Idee?

Zumindest nicht, wenn ich schlechte Bewertungen wie die 2-Sterne-Bewertung oben vermeiden will. Warum? Weil ich nicht nur Kunde bin, sondern auch genau weiß, was meine App bietet. Die Nutzer aber nicht. Sie wissen nur das, was ich ihnen auf der App-Store-Seite und in meinem Onboarding präsentiert habe. Und wahrscheinlich nicht mal alles davon.

Die Nutzer-Perspektive

Was sich für einen Nutzer fair anfühlt, hängt also stark davon ab, wie der Nutzer den Wert einer App wahrnimmt. Zum Beispiel die schlechte Bewertung oben, die ich für TranslateKit bekommen habe. Mein Vorschauvideo auf der App-Store-Seite kommuniziert die einfache Bedienbarkeit des Drag-&-Drop-Workflows zum Übersetzen von Apps. Aber der Nutzer hat sich beschwert, weil er sich bei einem Drittanbieter-Übersetzungsdienst registrieren musste, um die beworbenen Funktionen zu nutzen.

Natürlich erwähne ich diese Anforderung in meiner App-Store-Beschreibung. Aber wer liest Beschreibungen? Niemand! Ich könnte tun, was der Nutzer gefordert hat, und eingebaute Unterstützung für diese Übersetzungsdienste anbieten. Aber dann müsste ich für diese Dienste bezahlen und den Preis darauf aufschlagen. Und ich müsste zusätzlich einen Proxy-Server betreiben, um sicherzustellen, dass meine API-Keys nicht offengelegt werden, was weitere Kosten verursacht.

Das ist für die meisten meiner anderen Kunden aber nicht gut. Schließlich hat jeder Übersetzungsdienst, den ich unterstütze, ein großzügiges kostenloses Kontingent, das mehr als ausreicht, um eine App beliebiger Größe in viele Sprachen zu lokalisieren! Das einzige Problem ist die zusätzliche Hürde, ein kostenloses Konto zu erstellen und die API-Keys zu holen. Ich versuche zu helfen, indem ich auf die richtigen Seiten verlinke:

Alle Drittanbieter-Dienste ausgeklappt mit Links zur Registrierung & API-Key-Dokumentation.

Diese Hürde hat wahrscheinlich beim Nutzer Frust verursacht, der erwartet hatte, seinen String Catalog nach dem Herunterladen der App einfach „per Drag & Drop” reinzuziehen, wie im Vorschauvideo gezeigt. Aber das ging nicht sofort. Und als Konsequenz drückte er seine Gefühle aus, indem er das Einzige kritisierte, worüber er tatsächlich Bescheid wusste: den Preis. Denn den sieht man, wenn man im Hauptfenster auf „Upgrade” klickt.

Der obere Bereich des Hauptfensters in TranslateKit.

Die Beschwerde adressieren

Das Einfachste, was ich tun könnte, um Beschwerden über den Preis zu vermeiden, wäre, die Information über die kostenpflichtige Stufe zu verstecken, bis der Nutzer das kostenlose Limit überschreitet. Aber das betrachte ich als Dark Pattern, also würde ich das nie tun. Und selbst wenn ich es täte, würden sie sich wahrscheinlich einfach über etwas anderes beschweren – es löst das Problem nicht.

Viel nützlicher, um schlechte Bewertungen zu verhindern, wäre es, wenn ich mehr Anleitung und Hilfe beim Erstellen dieser Konten bieten würde, vielleicht mit Schritt-für-Schritt-Anleitungen oder Videos. Aber das senkt nur den Aufwand – es könnte für manche immer noch zu viel sein!

Die obige Analyse bringt mich zu dem Schluss, dass es eigentlich nicht der Preis meiner App war, der zur schlechten Bewertung geführt hat, sondern meine Unfähigkeit, ihren Wert zu kommunizieren. Nutzer können nicht wissen, dass meine App die String Catalogs nicht nur mit Übersetzungsdiensten verbindet, sondern auch unter der Haube allerlei Cleveres tut, um sicherzustellen, dass die Übersetzungen akkurat sind. Ein einfacher Weg, das zu kommunizieren, ist ein Beispiel:

Neues Fenster beim ersten App-Start zur Kommunikation des App-Werts.

Indem ich die verschiedenen Stufen zeige, die eine Übersetzung beim App-Start durchlaufen kann, erkläre ich meinen Nutzern, welchen zusätzlichen Mehrwert meine App bietet – über das hinaus, was schon auf der Store-Seite offensichtlich ist. Zusätzlich sollte ich diese Stufen & Anpassungen wahrscheinlich auch in der Übersetzungs-UI meiner App sichtbar machen, was ich in einem zukünftigen Update tun könnte. Aber es hätte die schlechte Bewertung sowieso nicht verhindert, da man die Übersetzungs-UI erst sieht, nachdem man mindestens einen API-Key eingerichtet hat.

Fazit

Preisgestaltung ist tatsächlich schwer und ich bin mir immer noch nicht zu 100 % sicher, ob das, was ich tue, richtig ist. Und das werde ich wahrscheinlich nie sein. Aber zumindest fühle ich mich nicht schlecht wegen meines Preises, da meine App viele Stunden Zeit spart und deutlich weniger kostet als der durchschnittliche Stundensatz. Und ich weiß, dass Leute die App abonnieren – das sehe ich an den Zahlen in App Store Connect. Jedes gekaufte Abo ist jemand, der mir sagt: „Der Preis ist nicht zu hoch.”

Nur weil ein Kunde sich über den Preis beschwert hat, heißt das nicht, dass er falsch ist. Die deprimierendsten Bewertungen können manchmal die nützlichsten Einblicke in die Schwächen deines App-Onboardings liefern. Ignoriere sie nicht einfach. Versuche zuerst zu verstehen, woher deine Nutzer kommen könnten. Und kommuniziere den Wert deiner App!

Du besitzt eine Apple Vision Pro? Mach deine Demos noch besser! Freunde durch die Funktionen zu navigieren kann schwierig sein, und man vergisst schnell mal, einige der besten Aspekte zu zeigen. Aber damit ist jetzt Schluss!

Guided Guest Mode ist dafür gemacht, deinen Freunden & deiner Familie eine reibungslose Einführung in die Zukunft von Spatial Computing zu bieten. Nutze die eingebauten Anleitungen – inspiriert von Apples eigenen Demos – um die besten Erlebnisse zu präsentieren, oder erstelle deine eigenen Guides. Eine riesige Zeitersparnis!

Ein kurzes Demo-Video von Guided Guest Mode.

Jetzt herunterladen:

Guided Guest Mode

Press Kit herunterladen

FocusBeats: Pomodoro + Music

Auch verfügbar auf iPhone, iPad und Mac

Du arbeitest gerne mit Hintergrundmusik? Und du möchtest deine Produktivität mit der Pomodoro-Technik (25 Min./5 Min.) verbessern? Dann ist das die App, auf die du gewartet hast: Sie bietet ausgewählte Musik-Themen wie Filmmusik oder klassische Musik. Und spielt die Musik während der Fokus- & Pausenzeiten automatisch ab & pausiert sie. Entdecke Fokus-Musik für jede Stimmung!

Für die automatische Musikwiedergabe benötigt diese App ein Apple Music-Abo. Ohne Abo ist sie trotzdem einer der besten Pomodoro-Timer da draußen. Das Standard-25/5-Pomodoro-System und ausgewählte Musik-Themen sind kostenlos nutzbar.

Ein kurzes Demo-Video von FocusBeats auf Vision Pro.

Jetzt kostenlos testen:

FocusBeats: Pomodoro + Music

Press Kit herunterladen

FreelanceKit bietet eine günstige, einfach zu bedienende Zeiterfassungslösung, die sich auf deinen Apple-Geräten wie zu Hause anfühlt. Mit SwiftUI entwickelt, ist die App intuitiv gestaltet und bietet ein reibungsloses, natives Erlebnis auf allen Apple-Plattformen.

FreelanceKit auf dem Mac.

Wichtigste Features:

• Nahtlose Synchronisierung: Starte die Zeiterfassung auf dem Mac und stoppe sie auf dem iPhone. iCloud-Sync stellt sicher, dass deine Daten auf allen Geräten verfügbar sind.

• Mini-Timer-Modus: Ein ablenkungsfreier Timer, der das Pausieren und Fortsetzen der Arbeit mühelos macht, ohne zu viel Bildschirmplatz einzunehmen.

• Mehrsprachige Unterstützung: Verfügbar in über 30 Sprachen, damit sie für alle zugänglich ist.

• Live-Verdienst-Tracking: Gib deinen Stundensatz ein, um deinen Verdienst in Echtzeit zu sehen – das motiviert!

• CSV-Export: Exportiere deine erfasste Zeit, um sie in anderen Tools mit allen erwartbaren Daten zu öffnen. Du kannst sogar das Datumsformat und das Trennzeichen anpassen!

FreelanceKit auf Apple Vision.

Perfekt für alle:

Ob du freiberuflich arbeitest, studierst oder Projekte verwaltest – FreelanceKit ist für alle gemacht, die ihre Zeit in den Griff bekommen wollen. Die Einfachheit und geräteübergreifende Kompatibilität sorgen dafür, dass du dich auf das Wesentliche konzentrieren kannst, ohne den Überblick über deine Zeit zu verlieren. Lade FreelanceKit jetzt herunter und entfalte dein Produktivitätspotenzial. Manage deine Projekte und deine Zeit effizienter!

Jetzt holen:

FreelanceKit: Time Tracking

Lade FreelanceKit jetzt herunter und entfalte dein Produktivitätspotenzial. Manage deine Projekte und deine Zeit effizienter!

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:

1. Einfache App-Modularisierung in Xcode ohne den ganzen Aufwand

2. Tortendiagramme gibt es jetzt, aber Spinnendiagramme fehlen noch!

3. 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ür ScrollView in 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?

Aber es waren mehr als 2 Jahre seit dem letzten Release vergangen. Natürlich hatte ich über die Zeit hinweg einige Funktionalitäten zum main-Branch hinzugefügt, damit ich sie leicht in meinen Apps wiederverwenden konnte. Doch undokumentierte Features, die nicht Teil eines neuen Releases sind, kann man als “intern” betrachten, selbst wenn die APIs selbst als public markiert sind.

Also habe ich mir in den letzten Tagen die Zeit genommen, den gesamten Code aufzuräumen, alles an die neuesten Swift-Erweiterungen anzupassen, ungenutzten Code zu entfernen, @available-Attribute für Umbenennungen hinzuzufügen (damit Xcode Fix-its anbieten kann) und eine ganze Reihe neuer APIs zu dokumentieren. Ich habe sogar ein komplett neues Logo entworfen!

Zusätzlich habe ich mich entschieden, Swift-DocC zu nutzen, wodurch ich meine README-Datei auf das Minimum reduzieren und stattdessen meine Dokumentation auf der Swift Package Index-Seite hosten konnte. Mit etwas Hilfe von ChatGPT konnte ich sogar die bestehende Dokumentation ausbauen, was zur am besten dokumentierten Bibliothek führte, die ich je veröffentlicht habe!

Ich werde einen eigenen Beitrag über die Details der Migration schreiben. Aber weil ich noch nie über HandySwift geschrieben habe, möchte ich einige der Annehmlichkeiten erklären, die du bei der Nutzung bekommst. Ich empfehle, es jedem Projekt hinzuzufügen. Es hat keine Abhängigkeiten, ist selbst leichtgewichtig, unterstützt alle Plattformen (einschließlich Linux und visionOS) und die Plattformunterstützung reicht bis iOS 12 zurück. Ein absoluter No-Brainer.

Extensions

Einige Highlights der über 100 Funktionen und Properties, die bestehenden Typen hinzugefügt werden – jeweils mit einem praktischen Anwendungsfall direkt aus einer meiner Apps:

Sicherer Index-Zugriff

In FocusBeats greife ich über einen Index auf ein Array von Musiktiteln zu. Mit subscript(safe:) vermeide ich Out-of-Bounds-Crashes:

var nextEntry: ApplicationMusicPlayer.Queue.Entry? {
   guard let nextEntry = playerQueue.entries[safe: currentEntryIndex + 1] else { return nil }
   return nextEntry
}

Du kannst es bei jedem Typ verwenden, der Collection konform ist, einschließlich Array, Dictionary und String. Statt den Subscript array[index] aufzurufen, der ein Non-Optional zurückgibt, aber bei einem ungültigen Index abstürzt, nutze das sicherere array[safe: index], das in solchen Fällen stattdessen nil zurückgibt.

Leere Strings vs. Blank Strings

Ein häufiges Problem bei Textfeldern, die nicht leer sein dürfen: Nutzer tippen versehentlich ein Leerzeichen oder Zeilenumbruch ein und bemerken es nicht. Wenn der Validierungscode nur .isEmpty prüft, bleibt das Problem unbemerkt. Deshalb stelle ich in TranslateKit bei der Eingabe eines API-Keys sicher, dass zuerst alle Zeilenumbrüche und Leerzeichen am Anfang und Ende des Strings entfernt werden, bevor die .isEmpty-Prüfung erfolgt. Und weil ich das sehr oft an vielen Stellen mache, habe ich einen Helfer geschrieben:

Image(systemName: self.deepLAuthKey.isBlank ? "xmark.circle" : "checkmark.circle")
   .foregroundStyle(self.deepLAuthKey.isBlank ? .red : .green)

Verwende einfach isBlank statt isEmpty für das gleiche Verhalten!

Lesbare Zeitintervalle

Immer wenn ich eine API verwendet habe, die ein TimeInterval erwartet (was nur ein Typealias für Double ist), fehlte mir die Einheit, was zu weniger lesbarem Code führte, weil man sich aktiv daran erinnern muss, dass die Einheit “Sekunden” ist. Und wenn ich eine andere Einheit wie Minuten oder Stunden brauchte, musste ich die Berechnung manuell durchführen. Nicht so mit HandySwift!

Statt einen einfachen Double-Wert wie 60 * 5 zu übergeben, kannst du einfach .minutes(5) schreiben. Zum Beispiel nutze ich in TranslateKit für die Vorschau der Ansicht bei einem abgelaufenen Abo Folgendes:

#Preview("Expiring") {
   ContentView(
      hasPremiumAccess: true,
      premiumExpiresAt: Date.now.addingTimeInterval(.days(3))
   )
}

Du kannst sogar mehrere Einheiten mit einem +-Zeichen verketten, um eine Uhrzeit wie “09:41 Uhr” zu erstellen:

let startOfDay = Calendar.current.startOfDay(for: Date.now)
let iPhoneRevealedAt = startOfDay.addingTimeInterval(.hours(9) + .minutes(41))

Beachte, dass dieses API-Design im Einklang mit Duration und DispatchTimeInterval steht, die beide bereits Dinge wie .milliseconds(250) unterstützen. Aber sie hören bei der Sekunden-Ebene auf, sie gehen nicht höher. HandySwift fügt für diese Typen auch Minuten, Stunden, Tage und sogar Wochen hinzu. So kannst du zum Beispiel Folgendes schreiben:

try await Task.sleep(for: .minutes(5))

Achtung: Das Voranschreiten der Zeit durch Intervalle berücksichtigt keine Komplexitäten wie die Sommerzeit. Verwende dafür einen Calendar.

Durchschnitte berechnen

Im Kreuzworträtsel-Generierungsalgorithmus von CrossCraft habe ich eine Health-Funktion für jede Iteration, die die Gesamtqualität des Rätsels berechnet. Zwei verschiedene Aspekte werden berücksichtigt:

/// Ein Wert zwischen 0 und 1.
func calculateQuality() -> Double {
   let fieldCoverage = Double(solutionBoard.fields) / Double(maxFillableFields)
   let intersectionsCoverage = Double(solutionBoard.intersections) / Double(maxIntersections)
   return [fieldCoverage, intersectionsCoverage].average()
}

In früheren Versionen habe ich mit verschiedenen Gewichtungen experimentiert, zum Beispiel Kreuzungen doppelt so stark gewichtet wie die Feldabdeckung. Das ließe sich immer noch mit average() erreichen – einfach so in der letzten Zeile:

return [fieldCoverage, intersectionsCoverage, intersectionsCoverage].average()

Fließkommazahlen runden

Beim Lösen eines Rätsels in CrossCraft siehst du deinen aktuellen Fortschritt oben auf dem Bildschirm. Ich nutze den eingebauten Prozent-Formatter (.formatted(.percent)) für numerische Werte, aber er erwartet ein Double mit einem Wert zwischen 0 und 1 (1 = 100%). Ein Int wie 12 zu übergeben, rendert unerwartet als 0%, also kann ich nicht einfach Folgendes machen:

Int(fractionCompleted * 100).formatted(.percent)  // => "0%" bis "100%"

Und einfach fractionCompleted.formatted(.percent) zu verwenden, ergibt manchmal sehr langen Text wie "0.1428571429".

Stattdessen nutze ich rounded(fractionDigits:rule:), um den Double-Wert auf 2 signifikante Stellen zu runden:

Text(fractionCompleted.rounded(fractionDigits: 2).formatted(.percent))

Es gibt auch eine mutierende round(fractionDigits:rule:)-Funktion, wenn du eine Variable direkt ändern möchtest.

Symmetrische Datenverschlüsselung

Bevor ich ein Kreuzworträtsel in CrossCraft hochlade, stelle ich sicher, dass es verschlüsselt wird, damit technisch versierte Leute die Antworten nicht einfach aus dem JSON auslesen können:

func upload(puzzle: Puzzle) async throws {
   let key = SymmetricKey(base64Encoded: "<base-64 encoded secret>")!
   let plainData = try JSONEncoder().encode(puzzle)
   let encryptedData = try plainData.encrypted(key: key)

   // Upload-Logik
}

Beachte, dass der obige Code zwei Extensions nutzt: Zuerst wird init(base64Encoded:) verwendet, um den Schlüssel zu initialisieren, dann verschlüsselt encrypted(key:) die Daten unter Verwendung sicherer CryptoKit-APIs unter der Haube, mit denen du dich nicht beschäftigen musst.

Wenn ein anderer Nutzer dasselbe Rätsel herunterlädt, entschlüssele ich es mit decrypted(key:):

func downloadPuzzle(from url: URL) async throws -> Puzzle {
   let encryptedData = // Download-Logik

   let key = SymmetricKey(base64Encoded: "<base-64 encoded secret>")!
   let plainData = try encryptedPuzzleData.decrypted(key: symmetricKey)
   return try JSONDecoder().decode(Puzzle.self, from: plainData)
}

HandySwift liefert außerdem praktischerweise encrypted(key:)- und decrypted(key:)-Funktionen für String, die eine Base-64-kodierte String-Repräsentation der verschlüsselten Daten zurückgeben. Verwende sie, wenn du mit String-APIs arbeitest.

Neue Typen

Neben der Erweiterung bestehender Typen führt HandySwift auch 7 neue Typen und 2 globale Funktionen ein. Hier sind die, die ich in nahezu jeder einzelnen App verwende:

Gregorian Day und Time

Du möchtest ein Date aus Jahr, Monat und Tag konstruieren? Ganz einfach:

GregorianDay(year: 1960, month: 11, day: 01).startOfDay() // => Date

Du hast ein Date und möchtest nur den Datumsteil ohne die Uhrzeit speichern? Verwende einfach GregorianDay in deinem Model:

struct User {
   let birthday: GregorianDay
}


let selectedDate = // aus dem DatePicker
let timCook = User(birthday: GregorianDay(date: selectedDate))
print(timCook.birthday.iso8601Formatted)  // => "1960-11-01"

Du möchtest einfach das heutige Datum ohne Uhrzeit?

GregorianDay.today

Funktioniert auch mit .yesterday und .tomorrow. Für mehr einfach aufrufen:

let todayNextWeek = GregorianDay.today.advanced(by: 7)

GregorianDay konformiert zu allen Protocols, die du erwarten würdest, wie Codable, Hashable und Comparable. Für Encoding/Decoding wird das ISO-Format wie “2014-07-13” verwendet.

GregorianTimeOfDay ist das Gegenstück:

let iPhoneAnnounceTime = GregorianTimeOfDay(hour: 09, minute: 41)
let anHourFromNow = GregorianTimeOfDay.now.advanced(by: .hours(1))


let date = iPhoneAnnounceTime.date(day: GregorianDay.today)  // => Date

Delay und Debounce

Wolltest du schon mal Code verzögert ausführen und fandest diese API umständlich zu merken und einzutippen?

DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + .milliseconds(250)) {
   // dein Code
}

HandySwift bietet eine kürzere Version, die leichter zu merken ist:

delay(by: .milliseconds(250)) {
   // dein Code
}

Es unterstützt auch verschiedene Quality-of-Service-Klassen wie DispatchQueue (Standard ist die Main Queue):

delay(by: .milliseconds(250), qosClass: .background) {
   // dein Code
}

Während Verzögerungen großartig für einmalige Aufgaben sind, gibt es manchmal schnelle Eingaben, die Performance- oder Skalierungsprobleme verursachen. Ein Nutzer könnte zum Beispiel schnell in ein Suchfeld tippen. Es ist gängige Praxis, die Aktualisierung der Suchergebnisse zu verzögern und zusätzlich ältere Eingaben zu verwerfen, sobald der Nutzer eine neue macht. Diese Praxis nennt sich “Debouncing”. Und mit HandySwift ist es ganz einfach:

@State private var searchText = ""
let debouncer = Debouncer()


var body: some View {
    List(filteredItems) { item in
        Text(item.title)
    }
    .searchable(text: self.$searchText)
    .onChange(of: self.searchText) { newValue in
        self.debouncer.delay(for: .milliseconds(500)) {
            // Suchvorgang mit dem aktualisierten Suchtext nach 500 Millisekunden Nutzer-Inaktivität ausführen
            self.performSearch(with: newValue)
        }
    }
    .onDisappear {
        debouncer.cancelAll()
    }
}

Beachte, dass der Debouncer in einer Property gespeichert wurde, damit cancelAll() beim Verschwinden für die Bereinigung aufgerufen werden kann. Aber delay(for:id:operation:) ist der Ort, an dem die Magie passiert – und du musst dich nicht um die Details kümmern!

Die Frage war also, ob ich das in so kurzer Zeit schaffen würde. Aber zum Glück stellte sich heraus, dass es einfach genug war, und meine App war am Tag 1 bereit!

Die offizielle E-Mail von Apple, in der sie sich bei Day-1-App-Entwicklern bedanken.

Im Folgenden findest du alle meine Erkenntnisse, die dir bei der Migration deiner eigenen Apps helfen können!

Drittanbieter-Frameworks

Nachdem ich das „Apple Vision”-Ziel zu meinem Projekt hinzugefügt hatte, war mein erster Schritt, den „Apple Vision Pro”-Simulator auszuwählen und einen Build zu starten.

Wie erwartet schlug der Build fehl – denn nicht alle Frameworks unterstützen die visionOS-Plattform bereits. Aber grundlegende Unterstützung hinzuzufügen war einfach. Hier sind die 4 Schritte:

Schritt 2: Die Anpassung der Package.swift-Datei ist der wichtigste Schritt.

1. Forke die Dependency, entferne sie aus deinem Projekt und füge deinen Fork mit dem main-Branch stattdessen hinzu.

2. Öffne die Package.swift-Datei im Fork, erhöhe die Swift-Tools-Version oben in der Datei auf 5.9 und füge .visionOS(.v1) zum platforms-Array hinzu.

3. Suche nach Vorkommen von #if os(iOS) und ändere sie zu #if os(iOS) || os(visionOS), um den macOS-Pfad zu vermeiden und den iOS-Pfad zu bevorzugen.

4. Wähle den „Apple Vision Pro”-Simulator und baue das Projekt, um es zu bestätigen.

Wenn du einen Fehler wegen fehlender APIs bekommst, stelle sicher, dass du #if !os(visionOS)-Checks an den richtigen Stellen einfügst. Die meisten APIs sollten aber verfügbar sein, da visionOS ein Fork von iPadOS ist, wie Apple offiziell bestätigt hat. Wenn ein Feature nicht vorhanden ist, wird es entweder bald kommen oder es macht auf der Plattform eben keinen Sinn.

In meinem Fall musste ich nur bei meiner eigenen ReviewKit-Bibliothek etwas Code rund um SKReviewController deaktivieren, der auf visionOS nicht verfügbar ist. Meine Bibliothek macht also effektiv nichts beim Build für visionOS, aber meine iOS- & Mac-Apps fordern weiterhin Nutzer auf, die App zu bewerten. Ich hätte das mit einer eigenen UI lösen können, aber ich habe mich entschieden, erstmal die diesjährige WWDC abzuwarten – in der Hoffnung, dass es dort schon verfügbar wird.

Vergiss nicht, einen Pull Request an das Original-Repo zu stellen, wenn du es geforkt hast, damit auch andere in der Community von deinem Fix profitieren können. Je mehr Leute das machen, desto weniger Dependencies musst du selbst mit Plattform-Support versehen.

Testen meiner App im Simulator

Nachdem ich alle Dependencies behoben hatte, baute ich meine App und es funktionierte!

Leider war ich noch nicht fertig. Zunächst fiel mir auf, dass beim Start der App kein App-Icon angezeigt wurde, obwohl ich eines im Projekt habe. Außerdem entdeckte ich nach dem Start sofort eine Reihe weiterer Probleme. Hier eine Übersicht:

• Das App-Icon fehlte

• Beim Bewegen des Cursors (= Blick) war die Hover-Form an manchen Stellen falsch

• Das Layout & die Größen vieler Fenster, Modals und meiner UI-Elemente stimmten nicht

• Meine Accent Color hatte keinen lesbaren Kontrast zum gläsernen Hintergrund

Alle diese Punkte betreffen jede einzelne App, die nach visionOS migriert wird. Für mich halfen kleine Anpassungen, um sie zu beheben. Lass mich meine Erkenntnisse nacheinander teilen.

App-Icon

Es stellt sich heraus, dass visionOS seinen eigenen App-Icon-Stil hat. Sie sind rund wie auf watchOS, bestehen aber aus mehreren Ebenen, um einen Tiefeneindruck zu erzeugen, wie auf tvOS. Du fügst ein visionOS-App-Icon hinzu, indem du auf den +-Button drückst und „visionOS App Icon” auswählst. Dann musst du mindestens ein „Front”- und ein „Back”-Ebenenbild in der Größe 1024 x 1024 bereitstellen. Die „Middle”-Ebene ist optional.

In meinem Fall bestand mein App-Icon bereits aus einer Hintergrundebene und einem Icon im Vordergrund, also war es kein großes Problem, sie separat zu exportieren. Ich musste nur die „Middle”-Ebene im rechten Panel entfernen. Aber weil mein Vordergrund-Icon einen Schatten hatte und die Human Interface Guidelines besagen, dass man „weiche oder ausgeblendete Kanten” bei Nicht-Hintergrund-Ebenen vermeiden soll, musste ich den Schatten entfernen. Das System fügt beim Hover automatisch einen leichten Schatten hinzu.

Apropos Hover: Xcode bietet oben eine Vorschau, wie dein App-Icon aussehen wird, und wenn du mit der Maus darüber fährst, simuliert es den 3D-Hover-Effekt, den Nutzer sehen, wenn sie auf der Vision Pro auf dein App-Icon schauen – richtig praktisch!

Xcodes Vorschau deines App-Icons.

Hover-Effekte

In visionOS gehören die richtigen Hover-Effekte zu den Dingen, die man im Simulator leicht übersieht, die aber beim tatsächlichen Verwenden des Geräts extrem wichtig sind. Da man Elemente auf dem Gerät mit den Augen auswählt, ist es wichtig, dass deine App Feedback darüber gibt, welches Element gerade ausgewählt ist. Das funktioniert bei String-basierten Control-APIs in SwiftUI wie Button("Click me") { ... } von allein.

Aber sobald du einen eigenen label-Parameter für einen Button bereitstellst oder sogar komplett eigene Controls hast, musst du dem System die genaue Form deines Controls mitteilen. Zum Beispiel verwende ich ein eigenes Control namens HPicker, das ich anstelle des Standard-Dropdown-Picker nutze, wenn ich nur 2–4 Optionen zur Auswahl habe. Es sah beim Hovern über eine Option so aus:

Mein eigener HPicker-View ohne jegliche Hover-Effekt-Anpassungen.

Die Anpassung, damit er der Form der Optionen folgt, war einfach genug:

Button {
   // ...
} label: {
   Label(option.description, systemImage: option.symbolSystemName)
      // ...
      .clipShape(.rect(cornerRadius: 12.5))
      #if !os(macOS)
      .contentShape(.hoverEffect, .rect(cornerRadius: 12.5))
      .hoverEffect()
      #endif
}

Vereinfachte Version der Buttons in meinem HPicker-Komponenten.

Die .contentShape- und .hoverEffect-Modifier sind das, was ich für einen korrekten Hover-Effekt hinzugefügt habe. Ersetze .rect(cornerRadius: 12.5) durch die jeweilige Form deines eigenen Controls. Beachte, dass ich sie in einen #if !os(macOS)-Check eingeschlossen habe, da meine App macOS unterstützt, .hoverEffect dort aber nicht verfügbar ist. Außerdem wichtig: Diese Modifier außerhalb des Button zu platzieren hat bei mir nicht funktioniert – sie müssen innerhalb der Label-Definition stehen, um richtig zu funktionieren.

In manchen Situationen fällt dir vielleicht auf, dass du einen Hover-Effekt hast, wo du keinen erwartest. Bei mir war das der Fall, wenn ich einen Button innerhalb einer anderen View platziert hatte, die selbst schon als Control erkannt wird, wie diese DisclosureGroup:

Die gesamte „Show Clues”-Zeile ist ein Button, aber der Button darin ist ein weiterer Button.

Du kannst den Hover-Effekt abschalten, indem du einfach den .hoverEffectDisabled()-Modifier hinzufügst. In meinem Fall oben war der innere Button nur für macOS vorgesehen (weil eine DisclosureGroup auf dieser Plattform beim Klicken auf das Label nicht umschaltet). Meine Lösung war, nur auf macOS einen Button darin zu verwenden und sonst ein einfaches Label.

Alle Controls mit einem korrekten Hover-Effekt auszustatten war tatsächlich die zeitaufwendigste Aufgabe der Migration und dauerte etwa 40 Minuten. Es wäre wahrscheinlich viel schneller gegangen, wenn SwiftUI-Previews in meinem Projekt funktioniert hätten, aber aus irgendeinem Grund ließen sie sich bei mir nicht bauen, und wenn ich es versuchte, fing mein Mac an zu hängen.

Layoutsystem

Obwohl visionOS auf iPadOS basiert und daher Dinge wie Form-Views ähnlich wie auf dem iPad darstellt, ist es wichtig zu verstehen, dass es einen entscheidenden Unterschied beim Layoutsystem im Vergleich zu iOS/iPadOS gibt:

Das Sichtfeld einer Person in der Apple Vision Pro. Quelle: HIG

Auf Apple Vision werden Apps auf einer unendlichen Leinwand geöffnet – es gibt keine feste Bildschirmbreite oder -höhe, von der deine Views ihre Größe ableiten können. Das ist ein wesentlicher Unterschied, den du verstehen musst. Wenn du bereits Apps für macOS entwickelt hast, ist dir dieser Unterschied schon bekannt. In vieler Hinsicht ist das Layoutsystem dem von macOS viel ähnlicher, wo Monitore ebenfalls unterschiedliche Größen haben können und Fenster nur sehr selten im Vollbildmodus geöffnet werden, wie es auf iOS & iPadOS üblich ist.

Wenn deine App also bereits macOS unterstützt, kannst du einfach die #if os(macOS)-Branches nutzen, die du wahrscheinlich schon zahlreich hast, wenn es um Größenanpassungen oder Fensterverwaltung geht. Ersetze sie einfach durch #if os(macOS) || os(visionOS).

Der Hauptunterschied selbst zu macOS ist, dass Fenster abgerundete Ecken mit einem großen Corner Radius haben. Ich musste daher zusätzliches Padding oben und unten bei meinen Fenster-Root-Views hinzufügen, z. B. mit .padding(.vertical, 10).

Wenn deine App noch nicht für macOS optimiert ist, hier einige wichtige Erkenntnisse:

• Du musst überall .frame(minWidth: 400, minHeight: 300) für deine Views angeben, sonst könnten deine Fenster oder Modals Größen haben, die für deine UI nicht funktionieren. Prüfe sie alle und gib passende Werte an.

• Obwohl du minWidth und minHeight für deine Views angeben solltest, damit Nutzer sie nicht zu klein für deinen Inhalt machen können, möchtest du zusätzlich eine größere .defaultSize(width: 800, height: 600) auf deiner WindowGroup-Scene angeben, um standardmäßig eine größere Größe als das Minimum zu verwenden.

• Wenn du modale Views hast, die deinen gesamten Bildschirm abdecken und auch diesen Platz brauchen, solltest du erwägen, diese Modals in eigene Fenster auszulagern. Nutze die @Environment(\.openWindow) var openWindow-Property, um neue Fenster auf visionOS (und macOS) zu öffnen, und definiere zusätzliche WindowGroup-Views. Lies meinen Artikel über Fensterverwaltung in SwiftUI 4, um mehr zu erfahren.

• Du kannst dich bei der ersten Migration auch dafür entscheiden, die Modals beizubehalten, anstatt externe Fenster zu verwenden, was die sauberere Lösung wäre. Beachte aber, dass im Gegensatz zu macOS modale Sheets in visionOS nicht in der Größe veränderbar sind. Stelle also zumindest sicher, dass du eine Größe angibst, die gut für dein Sheet funktioniert – für alle Arten von möglicherweise dynamischen Daten, die im Modal angezeigt werden. Genau das habe ich für das „Puzzle spielen” in CrossCraft gemacht.

Farben

Beachte, dass Controls mit weißem Hintergrund nicht gut mit dem Hover-Effekt harmonieren, weil der Effekt ein weißes Overlay verwendet. Weiß auf Weiß ist eben nicht sichtbar. Dieses Problem trat bei meinem Kreuzworträtsel-Spielmodus auf, wo Nutzer auf Kacheln drücken, um Buchstaben einzugeben. Hier ist der Cursor auf einer Kachel, aber der Hover ist nicht sichtbar:

Hovers sind auf weißen Hintergrund-Buttons nicht sichtbar.

Meine schnelle Lösung war, den Modifier .opacity(0.85) hinzuzufügen, um meine weißen Hintergründe 15 % transparent zu machen, was schon geholfen hat. Mehr wäre besser, aber Weiß ist eben eine erwartete „Kreuzworträtsel”-Farbe, also habe ich versucht, es so weiß wie möglich zu halten.

Farben, die auf iOS lesbar sind, funktionieren auf visionOS möglicherweise nicht.

Mir ist auch aufgefallen, dass viele Farben mit mittlerem Kontrast, einschließlich der Standard-„Blue”-Accent Color, einen wirklich schlechten Kontrast auf dem Standard-Glas-Hintergrund des Fensters haben. Stelle sicher, dass du diese Farben für visionOS heller machst. Du kannst eine spezifische Variante für „Apple Vision” über den Attributes Inspector hinzufügen, wenn eine Farbe ausgewählt ist.

Um eine Farbe im HSB-System heller zu machen, musst du die Sättigung leicht verringern und die Helligkeit deutlich erhöhen. Zusätzlich kannst du den Farbton ein wenig in Richtung des nächsten hellen RGB-Werts verschieben. Lies diesen Artikel, um mehr darüber zu erfahren, wie man Farben mit HSB richtig heller/dunkler macht.

Fazit

Wenn du eine App hast, die bereits auf iPadOS & macOS läuft, bist du in einer sehr guten Ausgangslage, um visionOS-Unterstützung hinzuzufügen. Du kannst deinen gesamten SwiftUI-Code wiederverwenden. Bei der Fensterverwaltung solltest du die macOS-Variante wählen. Für alles andere die iPadOS-Variante. Stelle dann sicher, dass alle deine eigenen Controls einen korrekten Hover-Effekt haben. Nimm einige Layout- & UI-Anpassungen vor, wie Padding hinzufügen, Farben heller machen oder dein App-Icon in Front- und Back-Ebene aufteilen.

Der gesamte Prozess hat bei mir effektiv 2 Stunden gedauert. Ich habe den gesamten Vorgang live gestreamt – du findest meine Aufnahmen (ohne die „Warten auf Build”- und „Chat”-Phasen) in den folgenden zwei YouTube-Videos, jedes etwa eine Stunde lang. Ich habe Zeitmarken für die verschiedenen oben beschriebenen Schritte hinzugefügt, damit du gezielt in Einzelheiten eintauchen kannst:

Als ich meiner Frau einen Prototyp dieser Idee zeigte, fragte sie sofort, ob man die Poster anklicken kann, um einen Trailer anzusehen. Und so war die Idee geboren, sie interaktiv zu machen! In der gerade veröffentlichten App findet man neben Trailern auch Spielzeiten und Direktlinks zu Streaming-Diensten. Hier ein Demo-Video:

Um sicherzustellen, dass alles wie erwartet funktioniert, habe ich Anfang dieser Woche Apples Developer-Labs in München besucht, da ich das Gerät hier in Deutschland nicht selbst kaufen kann, um es zu testen. Leider bestätigten die Apple-Ingenieure, dass visionOS das Speichern der Fensterpositionen über App-Neustarts hinweg noch nicht unterstützt. Vorerst muss man das Gerät also am Strom lassen, um die Poster-Positionen über mehrere Tage zu behalten. Aber es ist einfach, sie zu platzieren, also habe ich mich entschieden, die App trotzdem zu veröffentlichen. Und ich habe diesen Mangel auf allen offiziellen Wegen an Apple gemeldet, auch direkt an die Ingenieure im Lab. Ich habe noch mehr Ideen als nur diese, die dieses Feature brauchen. Ich bin überzeugt, dass es das Nummer-1-Feature ist, das uns Entwickler in visionOS 2.0 dringend brauchen.

Lange Rede, kurzer Sinn – ich habe gerade die „Posters”-App veröffentlicht und würde mich freuen, wenn du sie mal ausprobierst:

‎Posters: Discover Movies @Home

Lass mich bitte wissen, wenn du auf Probleme stößt. Ich bin wirklich begeistert davon, weitere Apps auf dieser neuen Plattform zu veröffentlichen. Mehrere Apps sind in Arbeit, von denen 2 vielleicht schon nächste Woche fertig werden könnten. Das liegt an meiner Entscheidung, mit meinen zukünftigen Apps auf Spatial-first zu setzen (statt Mobile-first). Immerhin wurden mehr als 70 % meines Umsatzes im letzten Monat auf Apple Vision erzielt. Und das, obwohl das Gerät noch nicht mal einen vollen Monat auf dem Markt ist! Aufregende Zeiten für Indies.

Wenn du meine zukünftigen Apps nicht verpassen möchtest, folge mir doch einfach!

In den 6 Wochen seit dem ersten Release habe ich unermüdlich daran gearbeitet, die am meisten gewünschten Features umzusetzen, und ich freue mich, dir 7 große Verbesserungen vorzustellen:

#1: Kreuzworträtsel speichern und synchronisieren

Du kannst Kreuzworträtsel jetzt speichern, um sie später zu lösen! Und dein Fortschritt wird über iCloud auch geräteübergreifend synchronisiert. Das war das am meisten gewünschte Feature!

#2: 5 neue Kategorien und 30 neue Themen

Vor diesem Update wurden 22 Themen in 5 Kategorien unterstützt. Dieses Update verdoppelt die Anzahl der Kategorien und mehr als verdoppelt die Anzahl der Themen! Und alle sind in allen 7 Sprachen verfügbar (EN, FR, DE, IT, PT, ES, TR).

Hier ist eine vollständige Liste aller neuen Themen:

• Allgemeinwissen: Anime, Bollywood, Kultur & Religion

• TV-Serien (neu): Friends, Game of Thrones, SpongeBob, Die Simpsons

• Videospiele (neu): Grand Theft Auto, Minecraft, Pokemon, Die Sims

• Sport: Karate, Taekwondo

• Sprachenlernen: Italienisch, Portugiesisch (Brasilien), Türkisch

• Kultur & Religion (neu): Altes Ägypten, Christentum, Griechische Mythologie, Islam, Judentum

• Wissenschaft (neu): Astronomie, Biologie, Informatik, Wirtschaft, Medizin

• Technologie (neu): Apple, Autos & Motoren, Google, Microsoft

Weitere Themen sind bereits in Arbeit und werden in zukünftigen Updates hinzugefügt.

#3: (Begrenzte) Tipps erhalten

In jedem Rätsel gibt es diese paar Wörter, die man einfach nicht weiß oder sich nicht daran erinnert. Du kannst jetzt eine begrenzte Anzahl von Feldern aufdecken, damit du nicht bei einem zu 90 % gelösten Rätsel feststeckst, nur wegen eines seltsamen Hinweises – das kann echt nervig sein!

#4: Game Center Unterstützung

Verdiene Erfolge für die Nutzung verschiedener Features der App und tritt gegen Freunde und andere in globalen Bestenlisten an. Jede Kategorie hat ihre eigene Bestenliste – also zeig, was du draufhast, und beweise dein Können in deinem Lieblingsthema!

Mein Account ist dem deutschen App Store zugeordnet, daher sind meine Screenshots auf Deutsch.

#5: Native App für den Mac

Während die iPad-Version von CrossCraft von Anfang an auf Apple-Silicon-Macs verfügbar war, habe ich mir die zusätzliche Mühe gemacht, eine native Mac-App mit einem passenderen Look & Feel zu erstellen. Das bedeutet: CrossCraft ist jetzt zum ersten Mal auch auf Intel-Macs verfügbar!

#6: Native App für die neue Apple Vision Pro

Zusätzlich habe ich CrossCraft auf visionOS migriert, um ein natives Erlebnis zu bieten, und den gesamten Prozess sogar live gestreamt. Räumliches Kreuzworträtsel-Lösen ist da!

#7: Dasselbe Rätsel teilen und spielen

Teile dein Rätsel mit einem einfachen Link oder einem gedruckten QR-Code. So kannst du ein Rätsel erstellen und einen Freund herausfordern, dasselbe Rätsel zu lösen – wer ist schneller?

Wenn du ein Publikum von Lesern hast, teile ein Bild eines eigens vorbereiteten Rätsels, um sie herauszufordern, und füge einen QR-Code hinzu, der das Rätsel direkt in CrossCraft öffnet – für ein reibungsloses Lösen direkt in der App.

Ich habe Rätsel in 7 Sprachen für dich erstellt, damit du das neue Teilen-Feature ausprobieren kannst:

• Anime-Rätsel: EN | FR | DE | IT | PT | ES | TR

• *Apple-Rätsel: *EN | FR | DE | IT | PT | ES | TR

• *Informatik-Rätsel: *EN | FR | DE | IT | PT | ES | TR

• *Wirtschaft-Rätsel: *EN | FR | DE | IT | PT | ES | TR

Das waren die am meisten gewünschten Features – ich hoffe, dir gefällt, wie sie geworden sind!

Hol dir das Update jetzt:

‎CrossCraft: Custom Crosswords

Falls du noch weitere Features vermisst, schreib mir gerne eine E-Mail.

Gib ChatGPT den folgenden Prompt ein, aber vergiss nicht, THEMA durch das Thema zu ersetzen, zu dem du ein Kreuzworträtsel erstellen möchtest, und SPRACHE durch die Sprache, in der die Fragen und Antworten sein sollen:

Erstelle 50 Hinweis-Antwort-Paare für ein Kreuzworträtsel zum Thema “THEMA” für ein Publikum von Fans des Themas. Biete eine gute Mischung aus leichteren und schwierigeren Fragen. Biete eine gute Mischung aus historischen und aktuelleren Beispielen. Gib Hinweise und Antworten auf SPRACHE an. Vermeide Paare, bei denen die Antwort eine Zahl enthält. Vermeide Hinweise, die (Teile der) Antwort enthalten. Halte sowohl Hinweise als auch Antworten kurz, z.B. vermeide unnötige Artikel. Ersetze Sonderzeichen wie “+” in der Antwort durch das ausgeschriebene Wort, z.B. “plus”. Formatiere die Hinweis-Antwort-Paare als einen einzelnen Codeblock mit kommasepariertem CSV wie folgt:

"Dies ist der erste Hinweis","Antwort"
"Dies ist der zweite Hinweis","Antwort"

Das THEMA kann durch alles Mögliche ersetzt werden. Eine bestimmte Technologie, der Name eines Franchises, eine Sportart, die du magst, oder die URL einer Medienwebsite, die du täglich besuchst. Ich bin iOS-Entwickler und interessiere mich für die neuesten Nachrichten über Apple-Produkte. Also kann ich THEMA einfach durch Apple News und SPRACHE durch Englisch ersetzen. ChatGPT sollte dann etwa so antworten:

ChatGPT spart viel Zeit beim Erstellen passender Hinweise und Antworten.

Wenn du nicht sofort eine solche Antwort bekommst, versuch es einfach noch mal, indem du den 🔄 Wiederholen-Button unter der Antwort drückst.

Schritt 2: Den CSV-Text in eine Datei kopieren

Drücke oben rechts im Codeblock auf „Copy code”, erstelle eine neue Datei mit einem Klartexteditor deiner Wahl (z.B. SublimeText) und füge den Inhalt in die neue Datei ein. Achte darauf, die Datei im Klartextformat mit der Endung .csv zu speichern.

Dokumenteditoren wie Word oder TextEdit speichern ihre Dateien in speziellen Markup-Formaten wie .docx oder .rtf. Das sind keine Klartextdateien.

Schritt 3: Die Gültigkeit der generierten Paare prüfen

Obwohl der Prompt bereits vorgibt, keine Zahlenwerte in den Antworten zu verwenden und die Antworten nicht in den Fragen zu verraten, macht ChatGPT Fehler. Prüfe also nochmal, ob alles korrekt aussieht. Du kannst auch eigene Einträge mit eigenen Fragen hinzufügen, um das Ganze noch etwas aufzupeppen.

Schritt 4: Ein passendes Fallback-Thema in CrossCraft auswählen

Eine Auswahl an Themen, die du in der CrossCraft-App findest.

Stelle sicher, dass du CrossCraft kostenlos auf deinem iPhone, iPad oder Mac installiert hast:

‎CrossCraft: Custom Crosswords

Öffne die App und wähle eines der vielen Themen aus, die die App standardmäßig mitliefert – am besten das, das deinem Thema am nächsten kommt. Falls ein passendes Thema noch nicht vorhanden ist, drücke unbedingt „Thema vorschlagen” in der App. Du kannst auch oben „Ohne Thema, nur eigene Fragen” wählen, wenn du die Lücken nicht mit Fragen eines Fallback-Themas füllen möchtest. Für vollere Rätsel kannst du immer Allgemeinwissen-Themen wie „Berühmte Persönlichkeiten” oder „Popkultur” wählen, da diese weithin bekannt sind. Ich habe „Technologie” ausgewählt.

Schritt 5: Die CSV-Datei in CrossCraft importieren

Das Importieren von CSV-Dateien ist ein Premium-Feature.

Stelle sicher, dass du Zugriff auf die .csv-Datei von dem Gerät hast, auf dem du CrossCraft verwendest – z.B. indem du die Datei in iCloud Drive speicherst, um sie auf deinem iPhone oder iPad zu öffnen. Dann drücke im Assistenten, in dem du die Größe und Schwierigkeit des Kreuzworträtsels wählen kannst, im letzten Schritt auf „Aus Datei importieren…” und wähle CSV im Dialog.

Schritt 6: Kreuzworträtsel (neu) generieren, bis es passt

Drücke den Button „Kreuzworträtsel erstellen” unten rechts, um dein erstes individuelles Kreuzworträtsel zu generieren. Die Generierung stoppt automatisch, wenn der aktuelle Zustand des Rätsels nicht mehr verbessert werden kann. Unterhalb der Kreuzworträtsel-Vorschau siehst du Werte, die die Qualität des generierten Kreuzworträtsels anzeigen – also wie „gefüllt” es ist und wie viele Kreuzungen es hat. Der Qualitätsprozentsatz fasst diese Aspekte in einem einzigen Wert zusammen. Jeder Prozentsatz über 50 % kann als „gut gefülltes” Kreuzworträtsel betrachtet werden.

Auf demselben Bildschirm findest du einen „Neu generieren”-Button, um den zufälligen Generierungsalgorithmus neu zu starten, falls du mit der Qualität des Kreuzworträtsels oder der Auswahl der Hinweise unzufrieden bist. Die Hinweise kannst du dir über „Hinweise anzeigen” ansehen.

Schritt 7: Dein Kreuzworträtsel als Bild exportieren

Auf iPhone oder iPad empfehle ich, „Teilen…” zu drücken und dann „Bild sichern” auszuwählen, um das Kreuzworträtsel in der Fotos-App zu speichern. Von dort kannst du es bei Bedarf mit anderen Geräten teilen. So wird sichergestellt, dass das Bild nicht zu einem JPEG ohne Transparenz herunterkonvertiert wird. Alternativ kannst du „In Datei sichern” verwenden.

Du wirst gefragt, welchen Teil du teilen möchtest. Wähle „Kreuzworträtsel + Hinweise” für ein kombiniertes Einzelbild. Alternativ kannst du das Rätsel und die Hinweise separat exportieren, falls du sie zum Beispiel auf 2 separaten Seiten ausdrucken möchtest.

Schritt 8: (Optional) Ein Hintergrundbild deiner Wahl hinzufügen

Das resultierende exportierte personalisierte Kreuzworträtsel für MacRumors.com

Für eine besonders schöne Optik such dir ein passendes Hintergrundbild zu deinem Thema und platziere das exportierte PNG-Bild darüber – mit einem Designtool deiner Wahl (z.B. Figma). Du könntest sogar KI-Bildgeneratoren verwenden und sie bitten, eine „Szenerie” zu erstellen, die zu deinem Thema passt. Genau das habe ich mit DALL-E in ChatGPT Plus gemacht. Mein genauer Prompt für das obige Hintergrundbild war:

Erstelle eine Szenerie, die zum Thema „Apple News” passt, im Hochformat. Die untere Hälfte sollte eine einheitliche Farbe/Schattierung sein. Halte es insgesamt schlicht.

Das exportierte Bild hat praktischerweise eine eingebaute Transparenz von 5 % in den weißen Hintergründen der Felder und Hinweise, sodass etwas von deinem Hintergrundbild durchscheint. Das Endergebnis siehst du oben. Mit mehr Zeit und Kreativität kannst du sicher noch etwas Besseres erstellen!

Probier es selbst aus und überrasche jemanden, den du magst. Es ist das perfekte Geschenk!

‎CrossCraft: Custom Crosswords

Erstellt mit CrossCraft. Thema: Popkultur. Die letzte Frage ist personalisiert.

Volle Personalisierung möglich

CrossCraft ist nicht einfach nur eine weitere Kreuzworträtsel-App. Es ist ein Werkzeug, mit dem du eine unbegrenzte Anzahl abwechslungsreicher Kreuzworträtsel zu einem ausgewählten Thema erstellen kannst. Darüber hinaus kannst du eigene Hinweis-Antwort-Paare hinzufügen, um das Kreuzworträtsel zu personalisieren oder gezieltere Fragen für dein Publikum zu stellen. Die App platziert deine eigenen Fragen immer zuerst im Rätsel, bevor sie die Lücken mit dem ausgewählten Thema füllt. Das bedeutet: Wenn du genug eigene Fragen mitbringst, kannst du sogar komplett individuelle Kreuzworträtsel erstellen – fast ohne Füllwörter aus dem gewählten Thema. Perfekt für Lehrkräfte, die eine unterhaltsame Herausforderung für ihre Schüler vorbereiten.

Um umständliches Tippen auf dem Handy oder Tablet zu vermeiden, kann die App Listen von Hinweis-Antwort-Paaren aus CSV- oder JSON-Dateien importieren. So kannst du deine eigenen Inhalte bequem am Computer erstellen – zum Beispiel mit Google Sheets, das sogar die Zusammenarbeit mit anderen ermöglicht, um schneller mehr Inhalte zu erstellen. Wenn alles bereit ist, speichere das Sheet einfach als CSV-Datei und erstelle dein komplett individuelles Kreuzworträtsel.

Viele Themen zur Auswahl

Eine ausreichend große Sammlung von Hinweis-Antwort-Paaren zu erstellen, kann eine mühsame und zeitaufwändige Aufgabe sein. Für ein gut gefülltes mittelgroßes Kreuzworträtsel können je nach Länge der Antworten und ihrer Buchstaben Hunderte von Paaren nötig sein. Deshalb liefert CrossCraft eine große Auswahl an Themen mit, die du als Fallback verwenden kannst, um die Lücken zu füllen. Oder um einfach ein thematisches Kreuzworträtsel ganz ohne eigene Fragen zu erstellen. Der Personalisierungsschritt ist nämlich komplett optional!

Im ersten Release werden 20 verschiedene Themen aus 5 verschiedenen Kategorien unterstützt:

• Allgemeinwissen: Berühmte Persönlichkeiten, Geografie, Geschichte, Popkultur

• Film-Franchises: Harry Potter, Herr der Ringe, Marvel (MCU), Star Wars

• Sport: American Football, Basketball, Formel 1, Fußball

• Sprachenlernen: Englisch, Französisch, Japanisch, Spanisch

• Programmierung: Android-Entw., Apple-Plattf.-Entw., Flutter, Ruby on Rails

Mit jedem Update kommen weitere Themen in weiteren Kategorien hinzu. Einige der nächsten Themen auf meiner Roadmap sind Filmzitate, Game of Thrones, Anime, weitere Sprachen wie Deutsch oder Italienisch und viele mehr in neuen Kategorien wie Musik, Kunst, Literatur, Wissenschaft und Technologie.

Welche Themen als Nächstes kommen, hängt ganz davon ab, was sich die Nutzer am meisten wünschen: In der App gibt es einen „Thema vorschlagen”-Button – nutz ihn unbedingt für dein Lieblingsthema!

Weitere Features wie die Möglichkeit, ein Lösungswort zu definieren, sind bereits geplant.

In allen Formen und Größen

Beim Erstellen eines Kreuzworträtsels kannst du aus 5 verschiedenen Größen, 3 verschiedenen Formen und 3 verschiedenen Schwierigkeitsgraden wählen. Das Thema „Spanisch” enthält zum Beispiel die 600 häufigsten Wörter auf Spanisch. Wenn der leichteste Schwierigkeitsgrad ausgewählt wird, werden nur die 200 häufigsten Wörter verwendet, 400 beim mittleren und alle 600 beim schwierigsten Level. So kannst du einfach anfangen und die Schwierigkeit steigern, wenn du die leichten Antworten schon alle kennst.

Für Lehrkräfte kann es wichtig sein, ein ganzseitiges Kreuzworträtsel auszudrucken. Die Formen „Querformat” und „Hochformat” sind so dimensioniert, dass sie eine ganze Seite perfekt ausfüllen. Beim Teilen oder Drucken eines erstellten Kreuzworträtsels bietet CrossCraft die Möglichkeit, das Rätsel und die Hinweise separat zu exportieren. So kann das Rätsel auf einer Seite und die Hinweise auf einer zweiten gedruckt werden, was die Lesbarkeit besonders bei größeren Kreuzworträtseln verbessert.

Für alle und überall

Sowohl die App als auch alle Themeninhalte sind in 7 Sprachen verfügbar: Englisch, Französisch, Deutsch, Italienisch, Portugiesisch (Brasilien), Spanisch und Türkisch. Die Sprache für die Hinweise kann unabhängig von der App-Sprache gewählt werden, sodass du ganz einfach Kreuzworträtsel für verschiedene Sprachzielgruppen erstellen kannst. Wo es sinnvoll ist, wurden die Themeninhalte an das Publikum der jeweiligen Sprache angepasst. Wenn zum Beispiel nach berühmten Moderatoren gefragt wird, sind das auf Englisch „Oprah Winfrey” oder „David Letterman”, während auf Deutsch eher Namen wie „Günther Jauch” und „Anne Will” passender sind. Diese Anpassungen wurden für alle Sprachen vorgenommen.

Außerdem ist beim Erstellen und Spielen der Kreuzworträtsel kein Server beteiligt. Alles passiert auf dem Gerät, was bedeutet, dass die App auch komplett offline funktioniert. Perfekt zum Spielen im Zug oder im Flugzeug ohne Internet.

Worauf wartest du noch? Hol sie dir jetzt!

Unendlich viele personalisierte Kreuzworträtsel erstellen, spielen und teilen – komplett kostenlos. Keine Werbung. Kein Tracking. Keine Fallen. Nur einige Optionen und der Datei-Import sind „Pro-Features” und können für einen kleinen Betrag freigeschaltet werden.

Zusammenfassung

• Einfach anpassen Wähle aus vielfältigen Themen. Füge eigene Fragen hinzu. Importiere sie, um Zeit zu sparen.

• Lehrreich und unterhaltsam Ideal für Lehrkräfte und Lernende. Mit druckfreundlichen Exportgrößen.

• Mehrsprachig und offline Verfügbar in 7 Sprachen – erstellen und spielen auch ohne Internetverbindung.

Herunterladen und entdecken

CrossCraft ist verfügbar auf iPhone, iPad und Apple-Silicon-Macs. Eine native Mac-App für alle Macs ist fast fertig und folgt in Kürze.

Hol dir die App jetzt:

‎CrossCraft: Custom Crosswords

Für Journalisten und Blogger ist ein PressKit hier verfügbar.

1. Eine klare Schritt-für-Schritt-Anleitung zum Einstieg – einschließlich App Store Connect.

2. Ein einfaches, aber flexibles Berechtigungssystem basierend auf den Käufen des aktuellen Nutzers.

3. Ein einheitliches Paywall-Design-Framework für wiederverwendbaren, gemeinsam genutzten Paywall-UI-Code.

Die ersten beiden plane ich in der README der Bibliothek abzudecken. Dieser Artikel konzentriert sich auf den dritten Aspekt: Wie hilft dir FreemiumKit, schnell eine erfolgreiche Paywall zu bauen? Und wie kann es dir bei A/B-Tests helfen?

FreemiumKit macht die StoreKit-2-Integration kinderleicht. Mit eingebauten Paywalls & Berechtigungen.

Grundidee

Eines der Dinge, die ich von RevenueCat erwartet hatte – einfach weil die Leute immer sooo positiv darüber gesprochen haben – war, dass sie fertige UI-Komponenten in ihrem Swift SDK mitliefern. Tun sie aber nicht. (UPDATE: Nach meinen Beschwerden haben sie damit angefangen!) Stattdessen integrieren sie sich mit einem anderen Dienst, der sich auf Paywalls spezialisiert hat und Nutzern hilft, ihre Paywalls durch Ausprobieren verschiedener Designs zu optimieren: Superwall. Falls du übrigens nicht weißt, was A/B-Tests sind – verschiedene Designs auszuprobieren und die Daten auszuwerten, um zu sehen, was am besten funktioniert, ist so ziemlich die Definition davon. Eine Paywall ist wahrscheinlich der wichtigste Screen, den man A/B-testen sollte. Die Idee des Dienstes gefällt mir also sehr, aber das Pricing skaliert nicht so gut nach unten: Sie verlangen 0,20 $ pro Kauf, was bei einem monatlichen Abo von 1 $ ganze 20 % deiner Einnahmen sind – das ist sogar höher als die 15 %, die Apple bei Small Businesses einbehält!

Außerdem bin ich persönlich kein Fan davon, viele Drittanbieter-Dienste zu nutzen. Ich halte meine App-Datenschutzerklärungen gerne kurz und einfach, was mit jedem neuen Dienst schwieriger wird. Daher bevorzuge ich es, einen eher „universellen” Analytics-Dienst zu wählen, der unter anderem A/B-Testing unterstützt, und diesen sorgfältig auszuwählen, statt viele Microservices zu integrieren. Aber das ist natürlich nur mein persönlicher Geschmack und du kannst dich anders entscheiden. Eine Sache gibt es allerdings, die ich an Superwall wirklich liebe: Sie betreiben die Website PaywallScreens, auf der du eine schöne Übersicht von Tausenden realer Paywalls findest, sortiert nach dem geschätzten Umsatz jeder App – aktuell angeführt von YouTube, TikTok und Disney+.

Beim ersten Release von FreemiumKit wollte ich alles mitliefern, was man braucht, um schnell eine erfolgreiche Paywall-UI zu bauen. Also scrollte ich durch alle 312 Paywall-Screens von Apps mit einem geschätzten Umsatz von über 500.000 $ pro Monat, wählte die 20 Screens aus, die ich am einladendsten und aufgeräumtesten fand, und analysierte sie, um Gemeinsamkeiten zu finden. Basierend auf meinen Erkenntnissen entwickelte ich dann 2 verschiedene und hochgradig anpassbare UI-Komponenten, mit denen du die meisten der analysierten Varianten erstellen kannst!

Hier sind die 20 ausgewählten Screens in absteigender Umsatzreihenfolge:

Quelle: paywallscreens.com

Quelle: paywallscreens.com

Quelle: paywallscreens.com

Quelle: paywallscreens.com

Häufige Design-Entscheidungen

Alles, was mir aufgefallen ist und was mindestens 50 % (einer Art) gemeinsam haben:

1. 100 % bieten entweder einen monatlichen oder wöchentlichen „Kurzzeit”-Plan an.

2. 100 % bieten entweder einen jährlichen oder lebenslangen „Langzeit”-Plan an.

3. 100 % verwenden schlichten weißen oder schwarzen Text für die Pläne oder die Liste freigeschalteter Features.

4. 95 % füllen den gesamten Bildschirm ohne zusammenhanglose Navigationselemente.

5. 95 % bringen alle wichtigen Informationen auf einen Bildschirm, ohne dass gescrollt werden muss.

6. 90 % verwenden eine Hintergrundfarbe, um ihren Haupt-Call-to-Action-Button hervorzuheben.

7. 85 % haben die Preispläne in der unteren Bildschirmhälfte aufgelistet.

8. 80 % verwenden einen abgerundeten Rahmen, um die aktuell ausgewählte Option hervorzuheben.

9. 80 % haben entweder einen Zurück-Pfeil oder einen „X”-Button oben zum Schließen.

10. 61 % der „X”-Buttons befinden sich in der linken Ecke (schwerer erreichbar für die meisten).

11. 80 % haben einen deutlich hervorgehobenen Call-to-Action-Button ganz unten.

12. 75 % der Call-to-Action-Buttons sind kapselförmig (Enden zu 100 % abgerundet).

13. 56 % der Call-to-Action-Buttons verwenden exakt denselben Titel: „Continue”

14. 70 % verwenden eine vertikale Liste von Buttons für die verschiedenen Planoptionen.

15. 70 % derjenigen mit Vorauswahl entscheiden sich für die langfristige wiederkehrende Option.

16. 60 % verwenden einen weißen Hintergrund hinter der Planliste zur Auswahl.

17. 55 % erwähnen den App-Namen irgendwo in der oberen Hälfte.

18. 65 % bieten entweder eine Liste, ein Grid oder eine Seitenansicht mit 2–6 (durchschn. 4) freigeschalteten Features.

19. 77 % derjenigen mit Liste verwenden ein Häkchen-Symbol vor jedem Feature.

20. 55 % verwenden ein Hintergrundbild, das sich bis zum oberen Bildschirmrand erstreckt.

21. 50 % bieten eine kostenlose Testversion für mindestens einen bezahlten Plan an.

22. 50 % erwähnen einen Rabattprozentsatz im Vergleich zu anderen Optionen.

Weniger häufige Design-Entscheidungen

Dinge, die mir bei einigen Paywalls aufgefallen sind, die aber die Mehrheit nicht macht:

1. 45 % verwenden eine andere Hintergrundfarbe für den aktuell ausgewählten Plan.

2. 35 % haben ein „Beliebt”- / „Empfohlen”-Tag bei einer der Kaufoptionen.

3. 30 % haben einen Radio-Button wie einen Punkt oder eine Checkbox, um die Auswahl hervorzuheben.

4. 30 % verwenden eine horizontale Liste von Buttons für die verschiedenen Planoptionen.

5. 30 % bieten einen (weniger hervorgehobenen) „Wiederherstellen”-Button innerhalb der Paywall.

6. 30 % bieten einen (weniger hervorgehobenen) Link zu ihren Nutzungsbedingungen und ihrer Datenschutzerklärung.

7. 15 % verwenden eine Seitenansicht, um die durch den Kauf freigeschalteten Features zu präsentieren.

8. 10 % bieten ein Segmented Control zum Wechseln zwischen Monatlich/Jährlich usw.

9. 5 % haben eine Animation auf ihrem Call-to-Action-Button (oder anderswo).

Der Paywall-Bauplan

Mit den obigen Erkenntnissen habe ich einen „Bauplan” erstellt, der sie alle einbezieht:

Ich bin kein professioneller Designer, aber ich denke, es ist gut genug für das erste öffentliche Release von FreemiumKit. Bessere Designer als ich in der Community sind eingeladen, (ausgefallene) Verbesserungen oder ganz andere Designs beizusteuern. Die README hat einen eigenen Abschnitt, der beschreibt, wie man eigene Designs baut. Wenn man sich anschaut, wie dieser Screen insgesamt aussieht und die 20 Paywall-Designs betrachtet, die ich geprüft habe, denke ich, es ist klug für das Framework, sich auf den Teil mit der meisten Logik zu konzentrieren. Die gesamte obere Hälfte des Screens ist in SwiftUI sehr einfach umzusetzen (nur ein Image mit einem .overlay, ein Button und eine List von Text-Views). Und dasselbe gilt für die weniger hervorgehobenen „Nutzungsbedingungen”-, „Wiederherstellen”- und „Datenschutzerklärung”-Buttons ganz unten.

Das ist der einzige Teil im Paywall-Bauplan mit komplexer Logik.

Konzentrieren wir uns also auf den Teil, der die verfügbaren Produkte lädt und auflistet, die aktuelle Auswahl hervorhebt, potenziell verfügbare Testzeiträume anzeigt, Langzeitplan-Rabatte, das Preisschild, ein zweites Monatspreisschild für besseren Vergleich, ein „Bester Wert”- oder „Beliebteste”-Badge, die aktuelle Planauswahl handhabt und die Logik für die Anzeige & Deaktivierung des „Weiter”-Buttons bei Bedarf. Wie du sehen kannst, ist dieser Teil ziemlich komplex, um ihn richtig hinzubekommen, und weil (fast) all diese Informationen der App tatsächlich von StoreKit bereitgestellt werden, ist es eine großartige Gelegenheit, die Dinge zu vereinfachen. Indem der Rest des Screens dem Entwickler/Designer überlassen wird – mit all den Erkenntnissen und dem Bauplan von oben – sollten Nutzer der Bibliothek volle Freiheit & Flexibilität haben, ein einzigartiges Aussehen für die Paywall ihrer App zu gestalten.

Um die Sache etwas spaßiger zu machen und A/B-Tests schon im ersten Release von FreemiumKit zu ermöglichen, erstellen wir auch eine horizontale Listenvariante wie diese:

Beide nebeneinander in ihrer Vollbild-Ausdehnung sehen so aus:

Die vertikale (links) und horizontale (rechts) Paywall-Baupläne nebeneinander.

Vertikaler & Horizontaler Produkt-Stil

FreemiumKit liefert eine SwiftUI-View namens AsyncProducts, die ganz ähnlich wie AsyncImage funktioniert: Du gibst die Produkt-IDs an, die du in deiner Paywall anzeigen willst (wie du AsyncImage eine URL deines Bildes gibst), und AsyncProducts kümmert sich um das Abrufen der Produkte aus dem App Store (wie AsyncImage die Bilder aus dem Web abruft), zeigt einen Platzhalter während des Ladens an und zeigt sogar eine Fehlermeldung mit einem Neu-laden-Button an, falls es Netzwerkprobleme gibt. Mit anderen Worten: Es erledigt die ganze schwere Arbeit – du musst nur entscheiden, wo auf deiner Paywall du es platzieren willst und welche Größe am besten passt:

AsyncProducts(
   style: PlainProductsStyle(),
   productIDs: ProductID.allCases,
   inAppPurchase: AppDelegate.inAppPurchase
)

Beispielverwendung von AsyncProducts.

Die Parameter productIDs & inAppPurchase werden in der Schritt-für-Schritt-Anleitung Getting Started in der README erklärt. Was uns in diesem Artikel interessiert, ist der style-Parameter, der es dir ermöglicht, verschiedene Designs für die UI-Komponente zu übergeben. Der PlainProductsStyle ist nur ein Demo-Stil, der die minimale Implementierung eines Stils zeigt, für diejenigen, die eigene Stile erstellen wollen. Er ist nicht für die direkte Verwendung gedacht. Die zwei echten Stile, die FreemiumKit in 1.0 mitliefert, sind:

• VerticalPickerProductsStyle für das linke Design von oben

• HorizontalPickerProductsStyle für das rechte Design von oben (in Arbeit)

Außerdem plane ich, mindestens einen weiteren Stil hinzuzufügen, der etwa HorizontalButtonsProductStyle heißen könnte und ein UI ohne „Weiter”-Button implementiert, wie es in der Paywall von Apples neuester App Final Cut Pro für iPad verwendet wird:

Paywall in Apples neuer Final-Cut-Pro-App für iPad.

Aber konzentrieren wir uns auf die heute verfügbaren Stile und verwenden den vertikalen Picker:

AsyncProducts(
   style: VerticalPickerProductsStyle(
      preselectedProductID: ProductID.proYearly,
      tintColor: .blue
   ),
   ...
)

Er nimmt zwei Argumente entgegen: Eines, mit dem du das Produkt angeben kannst, das als Vorauswahl hervorgehoben werden soll. Erkenntnis Nr. 15 aus der obigen Analyse sagt uns, dass 70 % die langfristige wiederkehrende Option vorauswählen. Das andere Argument lässt dich die Akzentfarbe wählen, die sowohl für den „Weiter”-Button-Hintergrund als auch zur Hervorhebung der aktuellen Auswahl des Nutzers verwendet wird. Achte darauf, eine Farbe zu wählen, die gut mit Weiß kontrastiert, denn das ist die Textfarbe des Weiter-Buttons.

Wenn du verschiedene Paywall-Designs testen willst, ist es sehr einfach, den Stil für A/B-Tests auszutauschen: Ersetze einfach VerticalPickerProductsStyle durch HorizontalPickerProductsStyle und alles sollte einfach funktionieren. Diese beiden Stile nehmen sogar dieselben Argumente entgegen, es ist also wirklich einfach. Andere Stile wie der geplante HorizontalButtonsProductsStyle werden andere Argumente haben, da es bei einem reinen Button-Stil ohne Auswahl kein Konzept von „Selection” gibt – aber es sollte trotzdem einfach genug sein, das zu ändern. Alle Stile konformieren zum AsyncProductsStyle-Protokoll. Wenn du also eine Variable erstellen willst, der du je nach A/B-Test-Gruppe verschiedene Stile zuweisen kannst, kannst du any AsyncProductsStyle als Typ verwenden.

Fazit

Das waren meine Erkenntnisse aus der Analyse von 20 erfolgreichen Paywalls. Ich habe alle Erkenntnisse in den VerticalPickerProductsStyle eingebaut, der in FreemiumKit mitgeliefert wird. So kannst du einfach die AsyncProducts-View in SwiftUI nutzen, statt dich mit komplexer Logik herumzuschlagen. Du musst dir nur merken, die weniger komplexen Erkenntnisse anzuwenden – wie AsyncProducts in der unteren Bildschirmhälfte zu platzieren, sowohl ein Kurzzeit- als auch ein Langzeit-Abo anzubieten oder eine Liste der freigeschalteten Features in der oberen Hälfte bereitzustellen.

Aber die meisten Leute, mit denen ich seit der Dub Dub gesprochen habe, sind sich der Auswirkungen von String Catalogs auf ihre Projekte noch gar nicht bewusst. Also dachte ich, ich sollte die häufigsten Fragen beantworten, um klarer zu machen, wie großartig String Catalogs wirklich sind.

Was sind String Catalogs? Was ist mit Strings(dict)-Dateien?

String Catalogs sind Dateien mit der Endung .xcstrings, die ihren Inhalt in einem eigenen JSON-Format speichern. Das genaue Format ist nicht dokumentiert (Feedback eingereicht, um das zu ändern: FB12264877), und als Entwickler wirst du nie mit JSON-Code herumhantieren müssen, denn Xcode 15 liefert einen visuellen Editor mit:

String Catalogs ersetzen sowohl .strings- als auch .stringsdict-Dateien und unterstützen daher Pluralisierung von Haus aus. Anders als .strings(dict)-Dateien, die in sprachspezifischen Ordnern wie en.lproj abgelegt werden, kapseln String Catalogs die Übersetzungen aller unterstützten Sprachen in einer einzigen Datei. Das ermöglicht Sicherheitsprüfungen wie die Anzeige des Übersetzungsfortschritts direkt in Xcode, damit du über fehlende Übersetzungen informiert bist (ersetzt den RemafoX-Linter). Ebenso werden neue Keys automatisch für alle Sprachen hinzugefügt, was dir viel Zeit spart (ersetzt den RemafoX-Normalizer). Und in zukünftigen Updates könnten weitere Features folgen, wie eine Prüfung, ob deine Lokalisierungen die gleichen Parameter (z. B. %@) wie die Ausgangssprache haben (ein Feature, das ich für RemafoX geplant hatte, Feedback eingereicht: FB12264614).

Ich habe ein Projekt mit Strings(dict)-Dateien. Ist die Migration einfach?

Ja, absolut! Die Migration zu String Catalogs ist kinderleicht: Klicke einfach mit der rechten Maustaste auf eine deiner .strings(dict)-Dateien und wähle “Migrate to String Catalog…”. Das öffnet ein Modal mit einer Liste all deiner .strings(dict)-Dateien im Projekt, aus denen du auswählen kannst, welche zu einem String Catalog zusammengefasst werden sollen. Wenn du separate Strings-Dateien für verschiedene Teile deines Projekts hast, kannst du auch separate String Catalogs behalten – es ist nicht nötig, alles in einen String Catalog zu packen.

Aber mein Projekt unterstützt ältere OS-Versionen. Kann ich trotzdem migrieren?

Ja, absolut! Die Apple-Ingenieure haben hier etwas sehr Cleveres gemacht: Während wir als Entwickler alle Features von String Catalogs voll nutzen können, bekommt unsere App kein neues Dateiformat wie .xcstrings zu sehen. Stattdessen konvertiert Xcode den String Catalog während des Build-Prozesses zurück in die guten alten .strings- und .stringsdict-Dateien, was die Unterstützung aller OS-Versionen sicherstellt, die du potenziell anvisieren kannst. Das bedeutet: Sobald du für dein Projekt auf Xcode 15 wechseln kannst, kannst du String Catalogs uneingeschränkt nutzen, ohne jemals zurückblicken zu müssen!

💁‍♂️ Wenn du dir schon mal eine App wie SF Symbols gewünscht hast, aber für lokalisierte Strings im Code mit offiziellen Übersetzungen für alle Sprachen, in denen iOS verfügbar ist: Genau das habe ich gebaut, und das Feature ist komplett kostenlos! Lade einfach TranslateKit herunter und schau in deine Menüleiste. 🌐 👍

Ich nutze SwiftGen/RemafoX für sichere Lokalisierungs-Key-Referenzen mit Compiler-Checks. Verliere ich diese Sicherheit?

Nein, überhaupt nicht. Xcode führt nicht nur ein neues Dateiformat für deine Lokalisierungen ein, sondern bringt auch Tools mit, die automatisch neue Lokalisierungs-Keys aus deinem Projekt extrahieren. Wenn du eine von SwiftUIs Lokalisierungs-APIs mit LocalizedStringKey oder LocalizedStringResource verwendest, werden sie automatisch erkannt und deinem String Catalog hinzugefügt. Aber das beschränkt sich nicht auf SwiftUI – es funktioniert auch mit reinen Swift-String-APIs wie String(localized:), klassischen Obj-C-Style-APIs wie NSLocalizedString() (sogar mit eigenen Namen) und sogar mit Interface-Builder-Dateien wie .storyboard und .xib. Für Info.plist-Dateien musst du einen eigenen String Catalog namens InfoPlist.xcstrings erstellen, und die Extraktion funktioniert auch dort automatisch.

Beachte, dass du keine Auto-Completion für deine Keys im Code bekommst, wie du sie jetzt für Bilder und Farben in deinen Asset Catalogs mit Xcode 15 erhältst. Das liegt daran, dass bei Asset Catalogs die Source of Truth im Catalog selbst liegt, wo deine Assets platziert werden. Weil Xcode aber automatisch alle hinzugefügten Lokalisierungen aus deinem Quellcode extrahiert, ist die Source of Truth für deine Lokalisierungen umgekehrt und liegt in deinem Code. Daher ist es unmöglich, einen Text in deinem Code hinzuzufügen, für den es kein Gegenstück in einer Strings-Datei gibt (wie es vorher möglich war und zu defekten Übersetzungen führte). Stattdessen erstellt Xcode jedes Mal, wenn du einen lokalisierten String in deinem Projekt hinzufügst, automatisch einen neuen Übersetzungs-Key für alle unterstützten Sprachen, und du siehst im String Catalog, dass deine Übersetzungen unvollständig sind.

Das Fehlen eines grünen Häkchens bei der deutschen Sprache zeigt an, dass die Übersetzung unvollständig ist.

Was ist mit Tippfehlern? Kann ich den Key während der Entwicklung ändern?

Xcode extrahiert nicht nur neue Keys und fügt sie automatisch deinem String Catalog hinzu, sondern stellt auch sicher, dass Keys in deinem Catalog, die nicht mehr in deinem Projekt referenziert werden, gelöscht werden. Das geschieht auf sichere Weise: Wenn du einen Key hast, für den du noch keine Übersetzungen in irgendeiner Sprache bereitgestellt hast, wird er automatisch gelöscht, sobald er nicht mehr in deinem Projekt gefunden wird. Das passiert typischerweise, wenn du einen Tippfehler in deinem Key hast oder den Key während der Entwicklung einfach verbessern und ändern möchtest. Aber wenn du bereits einige Übersetzungen hast, markiert Xcode den Key im String Catalog stattdessen als “stale” mit einem gelben Warnsymbol. So lassen sich Keys, die nicht mehr referenziert werden, leicht erkennen, ihre Übersetzungen bei Bedarf zum neuen Key kopieren und danach löschen.

Was, wenn ich einen bestimmten Text in Code/IB-Dateien nicht lokalisieren möchte?

Derzeit scheint es keinen direkten Weg zu geben, die Extraktion aus der Source of Truth zu steuern. Ich habe ein Feedback speziell für IB-Dateien eingereicht (FB12264777), weil meine Tools RemafoX (und sein Vorgänger BartyCrouch) dort das Ausschließen unterstützen – der Wechsel zu String Catalogs wäre daher für Nutzer dieser Tools nur möglich, wenn Apple eine Lösung anbieten würde. Einen expliziten Weg, einen String im Code als “nicht übersetzbar” zu markieren, konnte ich auch nicht finden, aber in den meisten SwiftUI-Views findest du eine Überladung der gleichen API, die statt eines Strings ein Text-View entgegennimmt. Für Views, bei denen das zutrifft, kannst du Text(verbatim: "Your Text") verwenden, um ein Text-View zu erstellen, dessen Text nicht extrahiert wird, weil das Schlüsselwort verbatim ihn als nicht übersetzbar kennzeichnet. Da aber nicht immer eine Überladung mit Text existiert, habe ich ein Feedback für einen direkteren Weg zur Steuerung der Extraktion eingereicht (FB12469163). Vorläufig habe ich einen Workaround gefunden, indem ich einfach einen String-Initializer in SwiftUI-APIs verwende, die die LocalizedStringKey-Überladung bevorzugen – übergib einfach etwas wie String("Your Text").

Fazit

Die Einführung von String Catalogs in Xcode 15 bringt erhebliche Verbesserungen für den Lokalisierungs-Workflow, indem sie die Verwaltung von Übersetzungsdateien vereinfacht. Entwickler können ihre Projekte einfach zu String Catalogs migrieren und die Sicherheit von Lokalisierungs-Key-Referenzen beibehalten, während sie weiterhin ältere OS-Versionen unterstützen und Kontrolle über Key-Änderungen und Tippfehler haben. Obwohl es einige Einschränkungen und Verbesserungsmöglichkeiten gibt, sind String Catalogs ein riesiger Schritt nach vorne und haben gegenüber dem alten Strings-Dateisystem keine echten Nachteile. Jetzt migrieren!

Das Problem und die Lösung

Traditionell haben App-Entwickler einfache Aufforderungen verwendet, um Nutzer um Bewertungen zu bitten – oft direkt nach dem Öffnen der App oder in zufälligen Abständen. Dieser Ansatz kann aufdringlich und nervig sein, was dazu führt, dass Nutzer negative Bewertungen hinterlassen oder die App sogar deinstallieren.

Ich hatte eine ziemlich komplexe Logik entwickelt, um den richtigen Zeitpunkt für Review-Anfragen in meiner ersten App RemafoX zu bestimmen. Für meine neueste App (Twoot it!) habe ich dann auf das Wesentliche reduziert und die Logik noch weiter vereinfacht. ReviewKit ist das Ergebnis dieses Prozesses.

ReviewKit löst dieses Problem, indem es intelligent entscheidet, wann App-Reviews basierend auf der jüngsten positiven Aktivität des Nutzers angefragt werden. Es stellt sicher, dass nur Nutzer, die eine zufriedenstellende Erfahrung mit deiner App gemacht und bestimmte Aktivitäten durchgeführt haben, zur Abgabe einer Bewertung aufgefordert werden. Dadurch erhöht ReviewKit die Wahrscheinlichkeit positiver Bewertungen und minimiert gleichzeitig die Belästigung der Nutzer.

Natürlich ist jede App anders, daher musst du selbst festlegen, was eine “positive Aktivität” in deiner App bedeutet. Aber um den Rest kümmert sich ReviewKit – und es ist auch anpassbar!

ReviewKit einrichten

Der Einstieg mit ReviewKit ist einfach. Folge den Anweisungen unten, um es in deine iOS- oder macOS-App zu integrieren – das Deployment Target kann bis iOS 11 oder macOS 10.14 zurückreichen, was selbst die meisten Unternehmens-Apps abdecken sollte:

Schritt 1: ReviewKit zu deiner App hinzufügen

Um ReviewKit zu deinem Projekt hinzuzufügen, verwende den Swift Package Manager (SPM). Navigiere in Xcode zu deinem Projekt und gehe zum Tab “Swift Packages”. Klicke auf den “+”-Button und gib die ReviewKit-Repository-URL ein:

https://github.com/FlineDev/ReviewKit.git

Stelle abschließend sicher, dass du dein App-Target auswählst, um ReviewKit zu verlinken.

Schritt 2: Review-Kriterien anpassen (optional)

ReviewKit bietet Standardkriterien für die Anfrage von App-Reviews: Es erfordert mindestens 3 positive Events innerhalb der letzten 14 Tage. Wenn du diese anpassen möchtest, kannst du die Kriterien über ReviewCriteria wie folgt konfigurieren:

ReviewKit.criteria = ReviewCriteria(
   minPositiveEventsWeight: 5,
   eventsExpireAfterDays: 30
)

Im obigen Beispiel wurden die Kriterien so angepasst, dass Reviews erst angefragt werden, wenn Nutzer mindestens 5 positive Events haben, und die Events nach 30 Tagen ablaufen. Das gilt, wenn du das Standard-weight von 1 für die folgenden Aufrufe verwendest.

Schritt 3: Positive Events aufzeichnen und Review anfragen

Um die App-Review-Anfrage auszulösen, wenn Nutzer bestimmte Workflows oder Aktivitäten abschließen, musst du positive Events mit ReviewKit aufzeichnen. Rufe die folgende Methode auf, wann immer ein Nutzer eine dieser Aktivitäten abschließt:

ReviewKit.recordPositiveEventAndRequestReviewIfCriteriaMet()

Diese Methode bestimmt automatisch, ob der Nutzer die Kriterien für eine App-Review-Anfrage basierend auf seiner jüngsten positiven Aktivität erfüllt. Wenn die Kriterien erfüllt sind, wird die Review-Aufforderung angezeigt.

Schritt 4: Weitere positive Aktivitäten aufzeichnen (optional)

Neben den primären Workflows ist es wichtig, auch zusätzliche Aktivitäten zu berücksichtigen, die auf positive Nutzererfahrungen hindeuten. Allerdings könnte eine Review-Anfrage in diesen Momenten Nutzer unterbrechen, die gerade in einem Workflow sind, was potenziell zu Verärgerung und geringerer Bereitschaft führt, eine Bewertung abzugeben – oder sogar das Rating negativ beeinflusst. Um diese Events zu erfassen, kannst du die Funktion recordPositiveEvent() verwenden:

// Optional kannst du einen eigenen `weight`-Parameter übergeben (Standard ist 1)
ReviewKit.recordPositiveEvent()

Beachte, dass beide oben genannten Methoden optional einen weight: Int-Parameter akzeptieren, mit dem du die Kriterien für Review-Anfragen feinjustieren kannst. Wenn deine App zum Beispiel verschiedene Engagement-Stufen hat, könntest du ein Weight von 3 für die höchste Aktivitätsstufe festlegen und minPositiveEventsWeight auf etwas wie 10 setzen. Das Standard-weight für positive Events ist 1.

Beispielhafte Verwendung in einer iOS-App

Zum besseren Verständnis betrachten wir eine Beispiel-iOS-App und zeigen, wie ReviewKit effektiv eingesetzt werden kann. Stell dir vor, du hast eine Social-Media-App, in der Nutzer Beiträge posten und die Beiträge anderer liken können. Hier ein Beispiel:

import ReviewKit

func sendPost() {
  // ...

  // Positives Event nach dem Senden eines Beitrags aufzeichnen
  ReviewKit.recordPositiveEventAndRequestReviewIfCriteriaMet(weight: 3)
}

func handlePostLike() {
  // ...

  // Positives Event für das Liken eines Beitrags unauffällig aufzeichnen
  ReviewKit.recordPositiveEvent()
}

Im obigen Beispiel zeigen die Methoden sendPost() und handlePostLike(), wie positive Events für verschiedene Aktivitäten aufgezeichnet werden. Wir rufen recordPositiveEventAndRequestReviewIfCriteriaMet() auf, nachdem ein Beitrag gesendet wurde, da dies das Ende eines Workflows markiert, den der Nutzer in unserer App durchgeführt hat – ein guter Zeitpunkt für eine Review-Anfrage.

Wenn Nutzer einen Beitrag liken, befinden sie sich noch mitten im Anwendungsfall des Inhalte-Konsumierens, was zwar eine positive Aktivität ist, die wir aufzeichnen sollten, aber es wäre aufdringlich, zu diesem Zeitpunkt nach einer Bewertung zu fragen. Deshalb rufen wir einfach recordPositiveEvent() auf.

Beispielhafte Nutzung von ReviewKit in der Twoot it! App.

Fazit

ReviewKit bietet eine einfache und doch effektive Lösung, um Nutzer um eine Bewertung deiner App zu bitten. Durch die intelligente Bestimmung des richtigen Zeitpunkts basierend auf jüngster positiver Aktivität erhöht ReviewKit die Chancen auf positive Bewertungen und hilft deiner App beim Wachstum. Mit einfacher Integration und anpassbaren Kriterien ist ReviewKit ein wertvolles Werkzeug für jeden iOS-Entwickler und jedes Team.

Großer Sale: 50 % Rabatt auf alle Abo-Pläne!

Um die Begeisterung rund um die WWDC noch zu steigern, habe ich mich entschieden, einen zeitlich begrenzten Sale auf alle RemafoX-Abo-Pläne anzubieten. Ab sofort und bis zum Ende der WWDC-Woche gibt es satte 50 % Rabatt auf alle Abo-Preise. Das ist eine seltene Gelegenheit, das volle Potenzial von RemafoX zu einem unschlagbaren Preis zu nutzen. Aber hier kommt das Beste: Wenn du dich während dieser Woche abonnierst, behältst du den reduzierten Preis für immer – auch nach Ende des Sales. Lass dir diesen unglaublichen Deal nicht entgehen, um deine Entwicklerkarriere anzukurbeln.

Neue Features werden jeden Monat zu RemafoX hinzugefügt – ohne zusätzliche Kosten! Als Nächstes kommt Version 2.0 mit einer einfachen Möglichkeit, deine Nutzer einzuladen, bei der Übersetzung deiner App zu helfen, indem sie ein paar maschinell übersetzte Texte direkt in deiner App überprüfen. Und du hast die volle Kontrolle darüber, wie du deine Nutzer ansprechen möchtest – oder vielleicht willst du einfach ein paar Freunde um Hilfe beim Übersetzen bitten? All das wird bald mit einem aktiven Abo möglich sein. ✨

Update 1.6: Spannende neue Features zur WWDC!

Zusätzlich zum ganz besonderen Sale habe ich RemafoX 1.6 mit drei brandneuen Features ausgestattet, die dein Coding-Erlebnis verbessern sollen. Diese Features sind komplett kostenlos für alle und sind meine Art, die WWDC mit euch zu feiern.

Schauen wir sie uns genauer an:

Feature 1: “Sort Selection” – Organisiere deinen Code mit Leichtigkeit

Ich habe ein schmerzlich vermisstes Feature zu Xcode hinzugefügt: Einen “Sort Selection”-Button. Jetzt kannst du ganz einfach jeden markierten Code alphabetisch sortieren – das spart dir wertvolle Zeit und Mühe. Erlebe den Komfort von organisiertem Code und optimiere deinen Entwicklungsprozess.

Feature 2: “Multi-Line Code” – Vereinfache komplexe Collections

Komplexe Collections in deinem Code zu handhaben ist jetzt ein Kinderspiel. Mit dem “Multi-Line Code”-Button in RemafoX erkennt Xcode Collections wie Parameterlisten und formatiert sie automatisch mehrzeilig. Genieße bessere Übersichtlichkeit und Effizienz beim Umgang mit komplexen Code-Strukturen.

Feature 3: “One-Line Code” – Code sofort verdichten

Wenn du mehrzeiligen Code in eine einzige Zeile verdichten musst, kommt der “One-Line Code”-Button zur Rettung. Reduziere visuelles Rauschen und verbessere die Code-Lesbarkeit mit einem einzigen Klick. Perfekt zum Teilen von Snippets oder zum Erstellen kompakter Darstellungen von länglichem Code. Oder um einfache Enums lesbarer zu machen.

So startest du kostenlos mit RemafoX

1. Lade RemafoX herunter und starte die App: Lade RemafoX hier aus dem Mac App Store herunter, um vom Sale und den neuen Features von RemafoX 1.6 zu profitieren. Nach dem Download starte die App einmal, damit sich die Xcode-Extension im System registriert. Du kannst die App direkt wieder schließen, wenn du die Übersetzungs-Workflow-Verbesserungen nicht nutzen möchtest.

2. Aktiviere die Xcode Source Editor Extension: Um RemafoX nahtlos in Xcode zu integrieren, öffne die Einstellungen-App deines Geräts und suche nach “Extensions”. Aktiviere den Eintrag für RemafoX im Modal der Xcode Source Editor Extension, um die RemafoX-Buttons in Xcode zu aktivieren.

3. Richte Shortcuts in den Xcode-Einstellungen ein: Öffne Xcode und navigiere zum Einstellungen-Menü. Im Bereich Key Bindings richtest du eigene Shortcuts für die Buttons “Sort Selection”, “Multi-Line Code” und “One-Line Code” ein, die du einfach findest, indem du “remafox” in die Suchleiste eingibst. So kannst du die Möglichkeiten von RemafoX schnell und mühelos in Xcode nutzen. Wenn du unsicher bist, welche Shortcuts du verwenden sollst, hier sind meine: ⌥⌘S für “Sort Selection” ⌥⌘⬇ für “Multi-Line Code” ⌥⌘⬆ für “One-Line Code”

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Fazit

Hol dir RemafoX – entweder wegen der tollen kostenlosen Features oder um dir ein Abo zum reduzierten Preis zu sichern und von allen zukünftigen Updates zu profitieren. Steigere jetzt deine Produktivität! 🚀

‎RemafoX: Easy App Localization

Aber die gute Nachricht ist, dass Federico die Seite in so gut wie allen Aspekten automatisiert hat, sodass sie größtenteils „einfach läuft”. Hut ab vor ihm, dass er die Dinge so gestaltet hat, dass es so einfach wie möglich ist, das Projekt gesund zu halten. 💯👏 Außerdem hat er zum Glück Swift für im Grunde alles verwendet, einschließlich des Publishens der Website, oder sogar für Hilfsprogramme wie das automatische Twittern neuer Zusammenfassungen. Für einen Swift-Enthusiasten wie mich, der sogar einen Newsletter über Swift Evolution betreibt, war das eine riesige Erleichterung. Es sieht so aus, als müsste ich dieses Jahr nur 2 Dinge tun:

Erstens: Die grundlegenden Informationen zu jeder Session (wie Links zum Video oder Apples Session-Beschreibung) ins Projekt eintragen, nachdem die Platforms State of the Union (auch bekannt als die „Developer Keynote”) stattgefunden hat. Denn dann kündigt Apple die Session-Details für den Rest der Woche an.

Zweitens: PRs mergen, die Community-Mitglieder für die Sessions hier aufgelistet erstellt haben, die noch keine Zusammenfassung haben. Du kannst die Liste jetzt schon besuchen und wirst ca. 120 Sessions allein für das Jahr 2022 finden, für die noch niemand Notizen beigetragen hat – verglichen mit ca. 60 Sessions, die bereits Notizen für 2022 haben.

Obwohl es meine Hauptaufgabe für dieses Jahr ist, diese 2 Dinge zu tun, weil die Zeit für mehr Vorbereitung zu knapp ist, habe ich weitere Pläne für die Zukunft des Projekts. Und weil dies ein Community-Projekt ist, möchte ich meine Pläne mit euch teilen.

80 % Session-Abdeckung bis Ende der WWDC-Woche

Foto von Tuyen Vo / Unsplash

Wenn ich eine Lektion im Leben gelernt habe, dann diese: Es ist egal, was du tust – solange du aktiv bleibst, wirst du immer etwas lernen! Warum ich das erwähne? Nun, während meines Calls mit Federico hatte ich eine Idee für dieses Projekt, die auf einer Erfahrung beruhte, die ich gemacht habe, weil ich ein großer Fan der Harry-Potter-Bücher bin. (Keine Sorge, es hat nichts direkt mit Rowlings Schreiben zu tun.) Für einen Fan wie mich war es nämlich unerträglich zu wissen, dass ein neues Buch erschienen ist, aber noch 2,5 Monate auf die deutsche Übersetzung warten zu müssen. Ich war gerade 14 geworden, als Der Halbblutprinz erschien, und obwohl ich Englisch bis zu einem gewissen Grad verstand, reichte es nicht aus, um ein ganzes Buch durchzuarbeiten.

Zum Glück hörte ich in einem der Fan-Foren (wahrscheinlich diesem hier) von einem Projekt, bei dem sich Leute organisierten, um das gesamte Buch in nur 48 Stunden zu übersetzen. Ich war zunächst skeptisch. Aber der Plan war einfach: Die eine Hälfte der Teilnehmer übersetzte jeweils ungefähr eine Seite des Buches innerhalb der ersten 24 Stunden. Dann erhielt die andere Hälfte jeweils die Übersetzung eines Teilnehmers und überprüfte sie als Lektor, um die Qualität zu verbessern. Am Ende fügten die Organisatoren alles zusammen und schickten das Endergebnis als PDF-Datei an alle Teilnehmer. Es klang zu schön, um wahr zu sein. Aber es hat tatsächlich funktioniert: Ich nahm als Erstübersetzer teil und hatte das vollständig übersetzte Buch am Sonntagabend. Es fühlte sich damals wie Magie an. Und ich lernte meine Lektion über die Kraft der Masse und des gemeinsamen Einsatzes.

Diese transformative Erfahrung hat bei mir nachgewirkt und mich davon überzeugt, dass wir mit dem WWDC Notes-Projekt etwas ebenso Beeindruckendes erreichen können. Genauso wie das Harry-Potter-Übersetzungsprojekt die Kraft der Community-Zusammenarbeit nutzte, bin ich zuversichtlich, dass wir mit eurer Hilfe ein ambitioniertes Ziel anstreben können: 100 % Abdeckung aller WWDC-Sessions mit zumindest grundlegenden Notizen innerhalb der ersten Woche! Indem wir das kollektive Fachwissen und die Begeisterung der Community nutzen, können wir sicherstellen, dass wertvolle Einblicke und Zusammenfassungen schnell verfügbar sind und Entwickler weltweit unterstützen.

Okay, du hast den Abschnittstitel gelesen – warum strebe ich dann nur 80 % an? Erstens gibt es einige Sessions zu Nischenthemen, die für ein breiteres Entwicklerpublikum nicht von Interesse sein dürften, wie „What’s new in AVQT”. Ich denke nicht, dass diese innerhalb der ersten Tage verfügbar sein müssen – also reduzieren wir mal auf 90 %.

Zweitens ist eine der zentralen Erkenntnisse bei Best Practices für Code Coverage: „Wir sollten uns nicht darauf versteifen, von 90 % Code Coverage auf 95 % zu kommen. Die Gewinne durch eine Erhöhung der Code Coverage über einen bestimmten Punkt hinaus sind logarithmisch.” Ich glaube, etwas Ähnliches gilt für WWDC-Sessions: Sobald 80 % der Sessions abgedeckt sind, sind die fehlenden 10 % relevanter Themen wahrscheinlich solche, die niemand anschauen möchte, weil sie zu langweilig oder kompliziert klingen (auch wenn sie es nicht sind). Es kann sich anfühlen wie „der Aufwand zur Erhöhung der Session-Abdeckung über einen bestimmten Punkt hinaus ist logarithmisch.” Daher strebe ich 80 % Abdeckung bis Sonntag an. Passt auch zum Pareto-Prinzip.

Aber das alles kann nur mit deiner Hilfe funktionieren. Ja, deiner. Du schreibst nie Session-Notizen? Oder du machst es, aber nur spärlich, und teilst sie deshalb nie öffentlich? Dann ist das deine Chance, aktiver zu werden und nebenbei etwas Neues zu lernen! Es gibt keine Anforderungen an Länge oder Format der Notizen, alles hilft. Du kannst auch nur als Lektor beitragen, wenn du möchtest – das hilft ebenfalls!

Damit ich das organisieren kann, kontaktiere bitte @WWDCNotes auf Twitter oder Mastodon mit der Nachricht: „Ich melde mich freiwillig, um Notizen beizutragen und zu überprüfen. Mich interessieren am meisten die Themen” und nenne dann einige Themen von dieser offiziellen Liste. Wenn du nur beitragen oder nur reviewen möchtest, passe den Text entsprechend an.

Ich melde mich dann am zweiten Tag der WWDC-Woche mit Vorschlägen, bei welchen Sessions du helfen könntest, sodass du nur für diese Notizen machen musst. Vielen Dank im Voraus für eure Hilfe! 🙏 Wenn jeder ein bisschen mithilft, profitieren wir alle gemeinsam.

Kompakte Takeaways für Twitter und Mastodon

Foto von Khamkhor / Unsplash

Auch wenn es großartig ist, Zusammenfassungen für jede WWDC-Session zu haben – es gibt jedes Jahr immer noch über 100 Sessions, und es kann wirklich schwer sein zu entscheiden, welche Session deine Zeit wert ist, nicht nur für das Video, sondern sogar fürs Lesen oder Überfliegen der Notizen, was auch zeitaufwendig sein kann. Genau deshalb habe ich versucht, meine wichtigsten Takeaways aus jeder der 21 Sessions, die ich während der WWDC-Woche geschaut und zusammengefasst habe, auf das Wesentliche zu reduzieren und sie alle in einen einzigen Twitter-Thread zu packen – jede Session in einem einzigen Tweet mit weniger als 250 Zeichen (280 minus „More: ”).

Die Community schien das zu lieben – der Thread wurde 48 Mal retweetet (das sind mit Abstand meine meisten Retweets bisher) und in mehreren Newslettern erwähnt. Ich denke, das ist ein Beleg dafür, dass die Community genau solche kompakten Zusammenfassungen braucht, und deshalb plane ich, das Ganze dieses Jahr auf ein neues Level zu heben:

Natürlich werde ich, wie jedes Jahr, alle Sessions anschauen, die mich persönlich interessieren, und Notizen schreiben, damit ich später meine Erkenntnisse durchgehen kann. Selbstverständlich werde ich meine Notizen zum Projekt beitragen. Aber ich werde in der ersten Woche wahrscheinlich wieder nur ca. 20 Sessions abdecken können, was gerade mal etwa 10 % aller Sessions ist. Mit der Hilfe der Community möchte ich den Nutzen des #SessionSummary-Threads für #WWDC23 steigern, indem wir die Abdeckung erhöhen!

Ich werde also versuchen, jede bei WWDC Notes beigetragene Notiz auf eine Liste der wichtigsten Takeaways herunterzubrechen, und ich lade die Community-Beitragenden ein, mir dabei zu helfen. Wie diese Hilfe genau aussehen kann, werde ich vor der WWDC klären und auf den @WWDCNotes-Accounts auf Twitter und Mastodon verkünden. Folge ihnen, um die Ankündigung nicht zu verpassen!

Die Website Open Source machen

Aktuell besteht das WWDC Notes-Projekt aus 4 GitHub-Repositories: Content, Website, TwitterBot und SocialImages. Nur Content ist derzeit Open Source:

Screenshot der Repositories der WWDCNotes-Organisation.

Federico sagte mir, für die Zukunft des Projekts wollte er alles Open Source machen, ähnlich wie das Swift Package Index-Projekt öffentlich arbeitet. Obwohl er nicht bei diesem Ziel helfen kann, stimme ich zu 100 % damit überein, also werde ich versuchen, die Repositories so umzustrukturieren, dass ich alles als Open Source veröffentlichen kann – und vielleicht sogar alles in einem einzigen Repository halten, wenn das sinnvoll ist. Ich plane, dieses Thema später im Jahr anzugehen, wenn der WWDC-Trubel sich gelegt hat. Ich halte euch auf Twitter und Mastodon auf dem Laufenden, wenn es so weit ist.

Fazit

Das sind meine anfänglichen Ziele für dieses Projekt. Zusammengefasst:

1. 80 % aller WWDC-Sessions bis Sonntag mit Notizen abdecken

2. Twitter/Mastodon-Thread mit kompakten Takeaways für alle Sessions

3. Das komplette Projekt als Open Source veröffentlichen, inklusive Website und Social Bots (langfristig)

Was denkst du? Gefällt dir die Richtung, die das nimmt? Oder hast du Ideen, die du mit mir teilen möchtest? Lass es mich wissen!

Als iOS-Entwickler hatte ich gehofft, nicht alle Details von AppKit lernen zu muessen. Aber ich musste alle moeglichen Hacks schreiben, um die einfachsten Dinge zu tun – wie ein Fenster zu schliessen. Oder den Vollbild-Button an einem Fenster zu deaktivieren. Aber es gibt gute Neuigkeiten: Durch das Anheben meines App-Targets auf macOS 13.0 konnte ich die Fensterverwaltung endlich ueber SwiftUI erledigen und alle Hacks aus meiner App entfernen.

Endlich fuehlt sich meine App wirklich zu 100% SwiftUI-getrieben an. Und hier sind alle neuen APIs, die ich nutzen konnte – gruppiert und betitelt nach der Aufgabe, die ich erledigen wollte. Da die Fensterverwaltung wahrscheinlich der groesste Unterschied zwischen iOS- und macOS-Entwicklung in SwiftUI-Zeiten ist, koennte dieser Artikel auch jedem helfen, der von iOS zu macOS wechselt, um zu verstehen, wie Fensterverwaltung auf dem Mac funktioniert.

Ein Fenster oeffnen

Wenn du eine WindowGroup verwendest (die der einzige Fenstertyp in SwiftUI 3 war), hast du mit SwiftUI 4 zwei Optionen: Die erste, die auch vorher schon unterstuetzt wurde, ist die Methode handlesExternalEvents:

enum Window: String, Identifiable {
   case paywall
   // ...
   var id: String { self.rawValue }
}

@main
struct AppView: App {
   var body: some Scene {
      // ...
      WindowGroup("Plan Chooser") { ... }
         .handlesExternalEvents(matching: [Window.paywall.id])
      // ...
   }
}

Wenn du dieses Fenster dann oeffnen moechtest, muesstest du eine URL oeffnen – so wie du jede externe URL oeffnen kannst, aber mit einem Custom URL Scheme. Zum Beispiel:

@main
struct AppView: App {
   @Environment(\.openURL)
   var openURL

   var body: some Scene {
      // ...
      WindowGroup(...) { ... }
         .commands {
            CommandGroup(after: .windowArrangement) {
               Button("Show Plan Chooser") {
                  self.openURL(URL(string: "remafox://\(Window.paywall.id)")!)
               }
               .keyboardShortcut("1")
            }
         }
   }
}

Diese Methode funktioniert allerdings nicht mit dem neuen Window-Typ, obwohl sie dort vollstaendig verfuegbar ist. Die Dokumentation ist eindeutig:

This modifier is only supported for WindowGroup Scene types.

Aber die zweite Methode funktioniert sowohl fuer WindowGroup als auch Window: Der neue Environment-Wert \.openWindow! Zuerst definieren wir eine id im Initializer:

enum Window: String, Identifiable {
   case paywall
   // ...
   var id: String { self.rawValue }
}

@main
struct AppView: App {
   var body: some Scene {
      // ...
      WindowGroup("Plan Chooser", id: Window.paywall.id) { ... }
      // ...
   }
}

Dann uebergeben wir diese id einfach an openWindow, um die Praesentation manuell auszuloesen:

@main
struct AppView: App {
   @Environment(\.openWindow)
   var openWindow

   var body: some Scene {
      // ...
      WindowGroup(...) { ... }
         .commands {
            CommandGroup(after: .windowArrangement) {
               Button("Show Plan Chooser") {
                  self.openWindow(id: Window.paywall.id)
               }
               .keyboardShortcut("1")
            }
         }
      // ...
   }
}

Das ist viel schoener! Beachte, dass es auch \.openDocument fuer DocumentGroup gibt.

Doppelte Fenster verhindern

Die Verwendung einer id fuer ein Fenster verhindert nicht, dass mehrere davon erscheinen:

Zumindest nicht bei WindowGroup – du kannst aber einfach Window verwenden, um sicherzustellen, dass nie mehrere Fenster mit derselben id erstellt werden! Aber das ist nicht immer eine Option.

Ein Window ist in verschiedener Hinsicht viel eingeschraenkter als eine WindowGroup. Zum Beispiel kann man nicht .commands darauf aufrufen, wie ich es oben getan habe, um Buttons im Hauptmenue der App zu setzen. Ausserdem ist Window eine reine macOS-API – du kannst den Code also nicht auf iPadOS wiederverwenden. Der Grund, warum ich es fuer RemafoX nicht verwenden konnte, ist die Einschraenkung, die ich bereits erwaehnt habe: Window unterstuetzt kein handlesExternalEvents. Aber ich brauche diese API, weil RemafoX tief in Xcode integriert ist – sowohl ueber eine Extension als auch ein CLI-Tool –, und diese koennen \.openWindow nicht nutzen, weil sie einfach nicht Teil desselben Targets sind. Aber sie koennen trotzdem “externe” URLs oeffnen!

Was auch immer dein Grund sein mag, um Duplikate bei WindowGroup zu verhindern – mach Folgendes:

WindowGroup("Plan Chooser", id: Window.paywall.id, for: String.self) { _ in
   // ...
} defaultValue: {
   Window.paywall.id
}

Hier wird eine ueberladene Version des WindowGroup-Initializers verwendet, die zusaetzliche for type- und defaultValue-Argumente akzeptiert. Sie kann genutzt werden, um ein bestimmtes Fenster fuer einen beliebigen Datentyp zu oeffnen (wie einen Profile-Typ), aber ich verwende hier einfach die id vom Typ String, um das Fenster eindeutig zu machen.

In meinem Fall musste ich das an mehreren Stellen tun, also habe ich diese Extension erstellt:

extension WindowGroup {
   init<W: Identifiable, C: View>(_ titleKey: LocalizedStringKey, uniqueWindow: W, @ViewBuilder content: @escaping () -> C)
   where W.ID == String, Content == PresentedWindowContent<String, C> {
      self.init(titleKey, id: uniqueWindow.id, for: String.self) { _ in
         content()
      } defaultValue: {
         uniqueWindow.id
      }
   }
}

Damit wurde der obige Aufruf mit zwei Window.paywall.id-Aufrufen einfach zu:

WindowGroup("Plan Chooser", uniqueWindow: Window.paywall) {
   // ...
}

Zum Oeffnen eines Fensters uebergeben wir zusaetzlich den value-Parameter an openWindow:

Button("Show Plan Chooser") {
   self.openWindow(id: Window.paywall.id, value: Window.paywall.id)
}

Wieder haben mich die mehrfachen Aufrufe von Window.paywall.id gestoert, also habe ich einen Helper erstellt:

extension OpenWindowAction {
   func callAsFunction<W: Identifiable>(_ window: W) where W.ID == String {
      self.callAsFunction(id: window.id, value: window.id)
   }
}

Jetzt kann ich einfach aufrufen – sogar ohne das .id-Suffix:

self.openWindow(Window.paywall)

Ein Fenster schliessen

Jetzt, wo wir ein Fenster (eindeutig) oeffnen koennen, schliessen wir es auch. Und hier war die Situation vorher viel schlimmer als bei WindowGroup, wo wir zumindest einen Workaround innerhalb von SwiftUI hatten. Es gab einfach keine Moeglichkeit, ein Fenster direkt in SwiftUI zu schliessen. Ich musste diesen Hack mit AppKit implementieren:

struct WindowAccessor: NSViewRepresentable {
   @Binding
   var window: NSWindow?

   func makeNSView(context: Context) -> NSView {
      let view = NSView()
      DispatchQueue.main.async {
         self.window = view.window
      }
      return view
   }

   func updateNSView(_ nsView: NSView, context: Context) {}
}

@main
struct AppView: App {
   @State
   private var window: NSWindow?

   var body: some Scene {
      WindowGroup(...) {
         SomeView(...)
            .background(WindowAccessor(window: self.$window))
      }
   }
}

Wenn ich dann das Fenster schliessen wollte, rief ich self.window.close() auf.

2021 wurde der Environment-Wert \.dismiss hinzugefuegt, mit dem praesentierte Views wie sheet, popover oder fullScreenCover direkt von innen heraus geschlossen werden konnten. Ich bin mir nicht sicher, ob dieses Verhalten damals schon verfuegbar war oder 2022 hinzugefuegt wurde, aber heute steht in der Dokumentation zusaetzlich, dass die dismiss-Aktion genutzt werden kann, um:

Close a window that you create with WindowGroup or Window.

Das funktioniert natuerlich nur, wenn gerade keine modale View innerhalb des betreffenden Fensters praesentiert wird. Aber dann funktioniert es einwandfrei – wir koennen einfach schreiben:

@main
struct AppView: App {
   @Environment(\.dismiss)
   var dismiss

   var body: some Scene {
      WindowGroup(...) {
         // ...
         Button("Close") {
            self.dismiss()  // <= this closes the window if no modal
         }
      }
   }
}

Den Vollbild-Button deaktivieren

Zuvor habe ich denselben oben erwahnten Hack verwendet, der mir Zugriff auf ein NSWindow gab, um weitere Konfigurationen vorzunehmen – wie das Deaktivieren des Vollbild-Buttons fuer Views mit fester Groesse, etwa mein Willkommensfenster oder mein About-Fenster. Aber jetzt haben wir den neuen Modifier windowResizability, der es uns erlaubt, den Vollbild-Button indirekt zu deaktivieren. Standardmaessig ist er auf contentMinSize gesetzt fuer alle Fenster ausser Settings (das ein Scene-Typ wie WindowGroup ist). Aber wir koennen jetzt Folgendes tun:

@main
struct AppView: App {
   var body: some Scene {
      WindowGroup(...) {
         SomeView(...)
            .frame(maxWidth: 400, maxHeight: 400)
         }
         .windowResizability(.contentSize)
      }
   }
}

Indem wir windowResizability auf .contentSize setzen, sagen wir SwiftUI, den Groessen, die wir im frame-Modifier angeben, strenger zu folgen. Als logische Konsequenz: Wenn die von der View angegebene Maximalgroesse kleiner ist als die aktuelle Bildschirmgroesse des Nutzers, deaktiviert SwiftUI automatisch den Vollbild-Button fuer uns! Das ist keine besonders offensichtliche oder direkte API, aber es ergibt Sinn. Effektiv sollte der Button fuer die meisten Nutzer deaktiviert sein, wenn wir Werte unter 1366 mal 768 angeben – das ist die native Groesse eines 11-Zoll MacBook Air (von 2015).

TCA-Extras

Wenn du wie ich The Composable Architecture (TCA) fuer deine Apps verwendest, fragst du dich vielleicht, wie du diese neuen Environment-Werte am besten an deine Reducer weiterleiten kannst, da Logik wie das Oeffnen/Schliessen von Fenstern dort stattfinden sollte. Die grossartige Community rund um TCA hat mir geholfen, das elegant zu loesen – insbesondere Thomas Grapperon hat einen Typ bereitgestellt, den ich in OnChange umbenannt habe und den du einfach per Copy & Paste in deine Projekte uebernehmen kannst – von hier. Dann haenge in deiner View den .onChange-Modifier an und uebergib ihm einen beliebigen Wert, der an den Reducer weitergeleitet werden soll:

@Environment(\.openWindow)
var openWindow

var body: some View {
   WithViewStore(...) { viewStore in
      SomeView(...)
         .onChange(of: \.$openWindow, store: self.store) { window in
            self.openWindow(window)
         }
   }
}

Beachte, dass sich \.$openWindow auf ein Feld im State bezieht, also muessen wir es definieren:

struct SomeState {
   @OnChange
   var openWindow: Window?
}

Jetzt koennen wir in unseren Reducern einfach den State-Wert auf einen Window-Enum-Case setzen, und die View leitet die Aenderung automatisch an den @Environment-Wert weiter. Das funktioniert auch mit jedem anderen SwiftUI-Attribut – ich habe es auch fuer @FocusState verwendet!

Uebrigens: Obwohl TCA mit einer \.dismiss-Dependency ausgeliefert wird, wird der Aufruf von await self.dismiss() im Reducer sich (derzeit) nicht wie der SwiftUI-\.dismiss-Environment-Wert verhalten und das Fenster schliessen. Stattdessen passiert nichts und es wird sogar eine Warnung erzeugt. Als Workaround habe ich eine Dependency implementiert, die AppKit-APIs nutzt, indem sie die offenen Fenster durchlaeuft, den passenden Match findet und diesen schliesst. Du kannst das Gist von hier per Copy & Paste uebernehmen. Die Verwendung sieht so aus:

// add the dependency to your reducer
@Dependency(\.closeWindow)
var closeWindow

// close a window in a `run` effect
return .run { _ in await self.closeWindow(Window.paywall) }

Und das war alles, was ich heute ueber Fensterverwaltung in SwiftUI 4 zu teilen hatte!

Du fandest diesen Artikel hilfreich? Hol dir meinen Expertenrat!

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.

Swift 6 wird nicht mehr 2023 veroeffentlicht, das wurde von Doug Gregor aus der Swift Language Workgroup klargestellt. Aber wusstest du, dass Apple bereits Teile von Swift 6 in Version 5.8 ausgeliefert hat? Ja, das stimmt. Einige Teile von Swift, die mit Xcode 14.3 vor ein paar Wochen ausgeliefert wurden, sind standardmaessig deaktiviert. Sie werden eingeschaltet, sobald Swift 6 erscheint, was noch ein Jahr dauern koennte – oder sogar laenger.

Diese Features fuehren einige Breaking Changes in Swift ein, zum Beispiel durch Umbenennung bekannter APIs, Anpassung ihres Verhaltens oder neue Sicherheitspruefungen im Compiler. Aber sie werden alle irgendwann aktiviert, um unsere Codebasen zu verbessern. Und wir werden unsere Projekte entsprechend anpassen muessen.

Ich dachte mir, es waere eine gute Idee, alle Features in meinen Projekten zu aktivieren, um zu sehen, ob es Breaking Changes fuer meine Codebasis gibt, die ich kennen sollte. Und natuerlich koennte ich auch einige neue Features nutzen, wie BareSlashRegexLiterals, das die /.../-Regex-Literal-Syntax fuer kompakte Regex-Initialisierung verfuegbar macht.

Gluecklicherweise gibt es mit Swift 5.8 jetzt einen einheitlichen Weg, diese Optionen zu aktivieren: Wir muessen einfach -enable-upcoming-feature an Swift uebergeben, indem wir es in den OTHER_SWIFT_FLAGS in den Build Settings unseres Projekts in Xcode angeben. Aber wir muessen auch wissen, welche Features verfuegbar sind, und ich konnte keinen Ort mit einer guten Uebersicht finden (noch nicht). Der Vorschlag, der diese einheitliche Option eingefuehrt hat, enthaelt eine solche Liste, aber sie wird nicht mit neueren Optionen aktualisiert, die spaeter hinzugefuegt werden, wie die von SE-0384. Wo koennen wir also derzeit zuverlaessig eine Liste aller unterstuetzten Optionen bekommen?

UPDATE: Du kannst jetzt direkt auf Swift.org nach Upcoming Flags filtern.

Swift ist Open Source, also scheint der zuverlaessigste Ort das Swift-GitHub-Repository zu sein! Es enthaelt eine Features.def-Datei, die Eintraege (Link zum release/5.8-Branch) namens UPCOMING_FEATURE beinhaltet, einschliesslich der zugehoerigen Swift-Evolution-Vorschlagsnummer und der Swift-Version, in der sie aktiviert werden:

UPCOMING_FEATURE(ConciseMagicFile, 274, 6)
UPCOMING_FEATURE(ForwardTrailingClosures, 286, 6)
UPCOMING_FEATURE(BareSlashRegexLiterals, 354, 6)
UPCOMING_FEATURE(ExistentialAny, 335, 6)

Hier sind die Optionen mit einer kurzen Beschreibung, was sie tun:

• ConciseMagicFile: Aendert #file, sodass es #fileID statt #filePath bedeutet.

• ForwardTrailingClosures: Entfernt die Backward-Scan-Matching-Regel.

• ExistentialAny: Verlangt any fuer existenzielle Typen.

• BareSlashRegexLiterals: Macht die /.../-Regex-Literal-Syntax verfuegbar.

Aus irgendeinem Grund scheinen zwei Optionen dort nicht aufgefuehrt zu sein (ich untersuche es):

• StrictConcurrency: Fuehrt vollstaendige Concurrency-Pruefung durch.

• ImplicitOpenExistentials: Fuehrt implizites Oeffnen in zusaetzlichen Faellen durch.

Weitere Optionen werden mit spaeteren Versionen ausgeliefert, z. B. ImportObjcForwardDeclarations.

Um meinen Code zusaetzlich auf korrekte Concurrency-Unterstuetzung zu pruefen, habe ich mich entschieden, auch -warn-concurrency (das sollte eigentlich dasselbe wie StrictConcurrency sein, falls das tatsaechlich funktioniert) und -enable-actor-data-race-checks zu uebergeben.

Mein Projekt migrieren

Wenn du wie ich alle 5.8-Optionen in deinem Projekt aktivieren moechtest, kopiere (Cmd+C) den folgenden Textblock, gehe dann zum Tab “Build Settings” deines Xcode-Projekts, suche nach “Other Swift Flags”, waehle diese Option im Editor aus und fuege sie ein (Cmd+V):

//:configuration = Debug
OTHER_SWIFT_FLAGS = -enable-upcoming-feature BareSlashRegexLiterals -enable-upcoming-feature ConciseMagicFile -enable-upcoming-feature ExistentialAny -enable-upcoming-feature ForwardTrailingClosures -enable-upcoming-feature ImplicitOpenExistentials -enable-upcoming-feature StrictConcurrency -warn-concurrency -enable-actor-data-race-checks

//:configuration = Release
OTHER_SWIFT_FLAGS = -enable-upcoming-feature BareSlashRegexLiterals -enable-upcoming-feature ConciseMagicFile -enable-upcoming-feature ExistentialAny -enable-upcoming-feature ForwardTrailingClosures -enable-upcoming-feature ImplicitOpenExistentials -enable-upcoming-feature StrictConcurrency -warn-concurrency -enable-actor-data-race-checks

//:completeSettings = some
OTHER_SWIFT_FLAGS

Wenn du wie ich eine mit SwiftPM modularisierte App verwendest oder an einem Swift-Package arbeitest, musst du zusaetzlich ein Array von .enableUpcomingFeatures an jedes Target ueber swiftSettings uebergeben:

let swiftSettings: [SwiftSetting] = [
   .enableUpcomingFeature("BareSlashRegexLiterals"),
   .enableUpcomingFeature("ConciseMagicFile"),
   .enableUpcomingFeature("ExistentialAny"),
   .enableUpcomingFeature("ForwardTrailingClosures"),
   .enableUpcomingFeature("ImplicitOpenExistentials"),
   .enableUpcomingFeature("StrictConcurrency"),
   .unsafeFlags(["-warn-concurrency", "-enable-actor-data-race-checks"]),
]

let package = Package(
   // ...
   targets: [
      // ...
      .target(
         name: "MyTarget",
         dependencies: [/* ... */],
         swiftSettings: swiftSettings
      ),
      // ...
   ]

Vergiss nicht, deine Tools-Version am Anfang der Datei auf 5.8 zu aktualisieren:

// swift-tools-version:5.8

.enableUpcomingFeature ist erst ab Swift 5.8 verfuegbar

Das liegt daran, dass Swift die Optionen, die du fuer dein Projekt-Target angegeben hast, nicht automatisch an importierte Module weitergibt. Und das sind gute Neuigkeiten, denn so muessen Swift-Packages, die du moeglicherweise in dein Projekt einbindest, nicht angepasst werden, und du kannst diese Features trotzdem fuer deinen eigenen App-Code nutzen. Und umgekehrt: Package-Autoren koennen diese Features fuer ihre Projekte aktivieren, ohne den Code in Projekten zu beeinflussen, in die sie eingebunden werden.

Nachdem ich alles aktiviert und gebaut hatte, stiess ich auf vier Arten von Problemen:

1. Ich musste an mehreren Stellen das any-Keyword hinzufuegen – Xcode half mit einem Fix-It:

1. Aus irgendeinem Grund erhielt ich viele Fehler bei Views mit einem .sheet-Modifier. Die Fehlerpaare besagten: “Generic parameter ‘Content’ could not be inferred” und “Missing argument for parameter ‘content’ in call”. Diese Meldungen waren aber nicht sehr hilfreich, also versuchte ich zuerst, den .sheet-Inhalt durch eine einfache Text-View zu ersetzen – aber das half nicht. Also habe ich die Optionen einzeln deaktiviert und die Fehler verschwanden, als ich ForwardTrailingClosures ausschaltete – also liess ich es deaktiviert. Ich hoffe, dass zukuenftige Swift-Versionen eine bessere Fehlermeldung erzeugen, um die Fehler spaeter zu beheben. Es eilt nicht. Ich kann es mit Swift 5.9 erneut versuchen. Ich hatte jetzt keine Zeit zum Untersuchen.

1. Ich musste einige meiner Funktionen, die einen TCA-WithViewStore zurueckgeben, mit dem @MainActor-Attribut markieren – aber auch hier half Xcode mit Fix-Its.

1. An vielen Stellen wurden Warnungen angezeigt: “Non-sendable type ‘…’ passed in call to main actor-isolated function cannot cross actor boundary”. Also habe ich diese Typen dem Sendable-Protokoll konform gemacht (mehr ueber Sendable hier).

Alles andere schien fuer meine App RemafoX mit ~35.000 Zeilen Swift-Code problemlos zu bauen. Der gesamte Prozess hat mich weniger als 3 Stunden gekostet.

Mein Projekt ist jetzt bereit fuer die Zukunft von Swift und ich kann das neue Regex-Literal-Feature nutzen (let regex = /.*@.*/). Ausserdem kann ich keinen neuen Code einfuehren, den ich spaeter zu Swift 6 migrieren muesste, da ich sofort Fehler erhalte.

Wie sieht es bei deinem Projekt aus? Welche Upcoming Features moechtest du migrieren?

extension Binding: Equatable where Value: Equatable {
   static func == (left: Binding<Value>, right: Binding<Value>) -> Bool {
      left.wrappedValue == right.wrappedValue
   }
}

Obwohl ich mit dieser Loesung nicht zu 100% zufrieden war, funktionierte sie einwandfrei, als ich sie urspruenglich entwickelte – also habe ich sie ausgeliefert. Aber dann begann mit irgendeinem macOS-Update ein Bug in alle Picker-Views meiner App einzuschleichen. Die Picker funktionierten zwar die meiste Zeit noch, verhielten sich aber manchmal seltsam. Das einzige Verhalten, das ich immer reproduzieren konnte, war: Wenn ich einen ausgewaehlten Wert programmatisch auf das Binding setzte und der Nutzer ihn dann spaeter auf einen anderen Wert aenderte, wurden beide Werte mit einem Haekchen im Picker-Dropdown angezeigt – was wahrscheinlich ein Bug irgendwo in SwiftUI ist:

Es hat mich Stunden des Code-Auskommentierens gekostet, um die Ursache zu finden, und es stellte sich heraus, dass es die oben erwaehnte Binding-Extension war. Irgendwie scheint ihre Definition in meiner App die interne Implementierung der Picker-View in SwiftUI beeinflusst zu haben. Und wenn man das weiss – wer weiss, welche anderen Seiteneffekte sie moeglicherweise verursacht hat oder in zukuenftigen System-Updates verursachen koennte? Ich musste also eindeutig eine bessere Loesung finden, die das Verhalten in SwiftUI-Views nicht beeinflussen sollte.

Der Grund, warum ich Binding Equatable-konform machen wollte, war, dass ich Anforderungen an meine Datenschicht hatte – naemlich bestimmte State-Typen in der TCA-Architektur –, die verlangten, dass alle Daten, die ich darin speichere, ebenfalls Equatable konformieren. Etwas wie:

struct AppState: Equatable {
   // other properties

   var configFile: Binding<ConfigFile>
}

Moechtest du hier deine Werbung sehen? Kontaktiere mich unter ads@fline.dev.

Die Loesung, die ich gefunden habe, ist recht einfach, auch wenn ich erst “lernen” musste, wie man einen Property Wrapper schreibt, da es das erste Mal war, dass ich einen eigenen brauchte. Aber es war unkompliziert – ich glaube, du wirst es verstehen, auch wenn du noch nie einen geschrieben hast:

@propertyWrapper
public struct EquatableBinding<Wrapped: Equatable>: Equatable {
   public var wrappedValue: Binding<Wrapped>

   public init(wrappedValue: Binding<Wrapped>) {
      self.wrappedValue = wrappedValue
   }

   public static func == (left: EquatableBinding<Wrapped>, right: EquatableBinding<Wrapped>) -> Bool {
      left.wrappedValue.wrappedValue == right.wrappedValue.wrappedValue
   }
}

Die einzige Anforderung des @propertyWrapper ist die wrappedValue-Property, und weil ich diesen Wrapper in meiner gesamten modularisierten Anwendung teilen wollte, musste ich auch einen public Initializer schreiben – aber alles ist unkompliziert. Die ==-Funktion ist die einzige Anforderung des Equatable-Protokolls und auch sie ist unkompliziert.

Damit kann ich jetzt alle meine Binding-Properties mit @EquatableBinding markieren:

struct AppState: Equatable {
   // other properties

   @EquatableBinding<ConfigFile>
   var configFile: Binding<ConfigFile>
}

Und das war’s – der Typ AppState ist jetzt vollstaendig Equatable, das seltsame Dropdown-Problem ist geloest, und es besteht kein Risiko fuer Seiteneffekte, weil ich keine bestehenden Typen aus anderen Frameworks mit neuen Protokollen konform mache. Stattdessen habe ich einfach einen neuen Typ eingefuehrt, von dem andere Frameworks nicht einmal wissen – sie koennen also nicht davon betroffen sein.

Die Lektion daraus: Erweitere nie Typen, die du nicht besitzt, um Protokolle, die du nicht besitzt. Es gibt sogar einen Swift-Vorschlag, der das zu einer Compiler-Warnung machen soll. Beachte, dass die Loesung nicht immer ein Property Wrapper ist. Es gibt viele Moeglichkeiten, eigene Typen einzubeziehen, wenn man Protokolle konformiert – vergiss einfach nicht, es zu tun.

Was ist RemafoX? Eine native Mac-App, die sich in Xcode integriert, um beim Uebersetzen deiner App zu helfen. Jetzt herunterladen, um beim Entwickeln Zeit zu sparen und Lokalisierung einfach zu machen.

Ich habe gerade meine App RemafoX migriert, die auf The Composable Architecture (TCA) Version 0.35.0 aufgebaut war, auf den neuen API-Stil von 1.0. Obwohl zwischen dem Release von 0.35.0 und der aktuellen Beta von 1.0 weniger als ein Jahr liegt, ist es wichtig zu beachten, dass in diesem kurzen Zeitraum nicht weniger als 27 Feature-Releases mit teilweise erheblichen Aenderungen veroeffentlicht wurden. Das Point-Free-Team arbeitet wirklich auf Hochtouren daran, die App-Entwicklung fuer Swift-Entwickler zu verbessern, und TCA ist die Kulmination des Grossteils ihrer Arbeit. Nahezu jedes Thema, das sie in ihrer grossartigen Advanced-Swift-Videoreihe besprechen, hat Auswirkungen auf TCA. Obwohl sie es geschafft haben, alle Aenderungen bis zur aktuellen Version 0.52.0 weitgehend quellcode-kompatibel zu halten, wird das 1.0-Release viele aeltere APIs entfernen, die schon seit einiger Zeit als deprecated markiert sind.

Weil ich es sehr ineffizient finde, staendig jede Entscheidung bezueglich der Architektur oder der Konventionen meines App-Codes zu hinterfragen, habe ich in den letzten Monaten nicht viel Zeit investiert, um alle Verbesserungen an TCA nachzuholen – auch wenn ich immer ein Auge darauf hatte, um die allgemeine Richtung mitzubekommen. Aber das nahende Release der Meilenstein-Version 1.0 der Library und die Tatsache, dass ich als Naechstes an einigen groesseren Features fuer RemafoX arbeiten will, machen es zu einem guten Zeitpunkt, um neu zu ueberlegen und zu lernen, wie ich meine Apps kuenftig am besten strukturiere.

Gluecklicherweise hat sich das grundlegende Konzept von TCA ueberhaupt nicht geaendert. Aber die APIs zur Beschreibung, wie Features verbunden werden, wie Navigation funktionieren soll, wie asynchrone Arbeit deklariert wird und sogar wie Dependencies weitergegeben werden – all das hat seitdem erhebliche Aenderungen erfahren, alles zum Besseren, unter Nutzung der neuesten Swift-Features. Es gab also viel herauszufinden und zu migrieren, und ich habe alle diese Aenderungsbereiche auf einmal angegangen. Um es aber handhabbar zu halten, habe ich die Aenderungen Modul fuer Modul auf alle 33 UI-Features meiner mit SwiftPM modularisierten App angewendet.

Hier sind die wichtigsten Erkenntnisse des Migrationsprozesses vorab:

1. Es hat mich eine volle Arbeitswoche (~5 Tage) gekostet, die Migration abzuschliessen.

2. Meine Codebasis ist um 2.500 Zeilen Code geschrumpft, was einer Reduktion von ~7% entspricht.

3. Einige Navigations-Bugs, Threading-Probleme und SwiftUI-Glitches sind jetzt behoben.

4. Mein Code ist deutlich einfacher zu verstehen, zu navigieren und nachzuvollziehen.

Was die Teststory meiner App angeht: Alle meine Tests bestehen tatsaechlich weiterhin und ich musste keinerlei Aenderungen am Testcode vornehmen. Der Grund dafuer ist, dass ich derzeit nur Tests fuer Nicht-UI-Features habe, wie das Parsen von Daten, das Suchen nach Dateien oder das Vornehmen von Aenderungen an Strings-Dateien – und in einigen Teilen recht umfangreiche Tests. Als ich aber auch Tests fuer mein UI in Betracht zog, lag ich bereits Monate hinter meiner urspruenglichen Timeline fuer das App-Release, und zusaetzlich war TCA noch einige Wochen davon entfernt, nicht-erschoepfendes Testen zu unterstuetzen. Also entschied ich mich gegen das Hinzufuegen von UI-Tests, da ich nicht wirklich zufrieden damit war, wie oft man Tests aendern musste, nur wegen eines Refactorings auf der UI-Ebene, das das allgemeine Verhalten eigentlich nicht aenderte, aber gefuehlt ein Umschreiben der zugehoerigen Tests erforderte, weil sie so erschoepfend waren. Aber mit dem jetzt verfuegbaren nicht-erschoepfenden Testen plane ich, Schritt fuer Schritt UI-Tests fuer meine App zu schreiben, angefangen mit den wichtigsten: Mein Feature mit der meisten Business-Logik und alle meine Onboarding-Features. Moeglicherweise schreibe ich darueber in einem zukuenftigen Artikel.

Aber fuer jetzt konzentrieren wir uns darauf, wie ich die Migration meiner App-Codebasis angegangen bin.

Vor der Migration (Praxisbeispiel)

Ich denke, der beste Weg zu erklaeren, welche Aenderungen noetig waren und welche weiteren Aenderungen ich zur Vereinfachung vorgenommen habe, ist, echten Code zu zeigen. Im Folgenden zeige ich dir also, wie der tatsaechliche Code des einfachsten Features meiner App vor der Migration aussah und wie ich ihn zum neuen TCA-1.0-Stil weiterentwickelt habe.

Das Feature heisst in meiner Codebasis AppInfo und sieht in der App so aus:

Der “About RemafoX”-Screen (Cmd+I).

Vor der Migration war der Feature-Code auf 7 verschiedene Dateien aufgeteilt:

Feature-Teile: Action, ActionHandler, Error, Event, Reducer, State und View.

AppInfoState und AppInfoAction definieren die Daten und moeglichen Interaktionen:

import AppFoundation
import AppUI

public struct AppInfoState: Equatable {
   public typealias Action = AppInfoAction
   public typealias Error = AppInfoError

   @BindingState
   var showEnvInfoCopiedToClipboard: Bool = false
   var selectedAppIcon: AppIcon

   var errorHandlingState: ErrorHandlingState?

   public init() {
      self.selectedAppIcon = Defaults[.selectedAppIcon]
   }
}

AppInfoState.swift

import AppFoundation
import AppUI

public enum AppInfoAction: Equatable, BindableAction {
   public typealias State = AppInfoState
   public typealias Error = AppInfoError

   case onAppear
   case onDisappear
   case selectedAppIconChanged
   case copyEnvironmentInfoPressed

   case binding(BindingAction<State>)

   case errorOccurred(error: Error)
   case setErrorHandling(isPresented: Bool)
   case errorHandling(action: ErrorHandlingAction)
}

AppInfoAction.swift

Beachte, dass ich immer Typealiases fuer verwandte Teile des Features definiert habe, auf die ich irgendwo innerhalb der Typen verweisen koennte – auch wenn ich sie nicht wirklich genutzt habe. Ausserdem hatte ich eine zusaetzliche Action set<Name des Childs>(isPresented:), wann immer ich eine Child-View hatte, die ich spaeter per Sheet praesentieren wollte. Falls du dich fragst, was diese Imports von AppFoundation und AppUI sind – das habe ich in diesem Artikel erklaert. Sie helfen, die Anzahl der Imports in meiner App zu reduzieren.

Als Naechstes schauen wir uns an, wie die AppInfoView-Datei aussieht:

import AppFoundation
import AppUI

public struct AppInfoView: View {
   public typealias State = AppInfoState
   public typealias Action = AppInfoAction

   let store: Store<State, Action>

   public init(store: Store<State, Action>) {
      self.store = store
   }

   public var body: some View {
      WithViewStore(self.store) { viewStore in
         VStack(alignment: .leading, spacing: 20) {
            VStack(alignment: .center, spacing: 10) {
               viewStore.selectedAppIcon.image
                  .resizable()
                  .aspectRatio(contentMode: .fit)
                  .frame(width: 128, height: 128)
                  .onChange(of: Defaults[.selectedAppIcon]) { newValue in
                     viewStore.send(.selectedAppIconChanged)
                  }

               Text(Constants.appDisplayName)
                  .font(.system(size: 33, weight: .light, design: .rounded))

               Text("Copyright © 2022 Cihat Gündüz")
                  .font(.footnote)
                  .foregroundColor(.secondary)
            }
            .frame(maxWidth: .infinity)

            Divider()

            VStack(alignment: .center, spacing: 10) {
               Text("Environment Info")
                  .font(.headline)

               Text("Provide these info when reporting bugs or use Help menu.")
                  .frame(maxWidth: .infinity, alignment: .leading)
                  .font(.subheadline)
                  .padding(.bottom, 5)

               HStack {
                  Text("App Version:").foregroundColor(.secondary)
                  Spacer()
                  Text(Bundle.main.versionInfo)
               }

               HStack {
                  Text("System Version:").foregroundColor(.secondary)
                  Spacer()
                  Text(ProcessInfo.processInfo.operatingSystemVersionString.replacingOccurrences(of: "Version ", with: ""))
               }

               HStack {
                  Text("System CPU:").foregroundColor(.secondary)
                  Spacer()
                  Text(KernelState.getStringValue(for: .cpuBrandString))
               }

               HStack {
                  Text("Tier:").foregroundColor(.secondary)
                  Spacer()
                  Text(Plan.loadCurrent().tier.displayName)
               }

               Button {
                  viewStore.send(.copyEnvironmentInfoPressed)
               } label: {
                  Label("Copy", systemSymbol: .docOnClipboard)
               }
               .padding(.top, 10)
               .popover(isPresented: viewStore.binding(\.$showEnvInfoCopiedToClipboard), arrowEdge: Edge.top) {
                  Text("Copied!").padding(10)
               }
            }
         }
         .frame(width: 320)
         .padding()
         .onAppear { viewStore.send(.onAppear) }
         .onDisappear { viewStore.send(.onDisappear) }
         .sheet(
            isPresented: viewStore.binding(
               get: { $0.errorHandlingState != nil },
               send: Action.setErrorHandling(isPresented:)
            )
         ) {
            IfLetStore(
               self.store.scope(state: \State.errorHandlingState, action: Action.errorHandling(action:)),
               then: ErrorHandlingView.init(store:)
            )
         }
      }
   }
}

#if DEBUG
   struct AppInfoView_Previews: PreviewProvider {
      static let store = Store(
         initialState: .init(),
         reducer: appInfoReducer,
         environment: .mocked
      )

      static var previews: some View {
         AppInfoView(store: self.store)
      }
   }
#endif

AppInfoView.swift

Beachte, dass ich fuer das Praesentieren eines Sheets nicht weniger als 11 Zeilen Code brauche und die Action setErrorHandling(isPresented:) manuell zurueck ins System senden muss. Erfahrene Entwickler werden auch bemerken, dass ich tatsaechlich globale Dependencies in meinem View-Code verwende, zum Beispiel mit Plan.loadCurrent(), was meinen UI-Code nicht besonders testbar macht. Aber ich werde sie als richtige Dependencies einfuehren, sobald ich mit dem Schreiben von UI-Tests beginne – ignorieren wir das fuer jetzt also.

Das letzte fehlende Puzzleteil eines Features in TCA ist der AppInfoReducer:

import AppFoundation
import AppUI

public let appInfoReducer = AnyReducer.combine(
   errorHandlingReducer
      .optional()
      .pullback(
         state: \AppInfoState.errorHandlingState,
         action: /AppInfoAction.errorHandling(action:),
         environment: { $0 }
      ),
   AnyReducer<AppInfoState, AppInfoAction, AppEnv> { state, action, env in
      let actionHandler = AppInfoActionHandler(env: env)

      switch action {
      case .onAppear, .onDisappear:
         return .none  // for analytics only

      case .selectedAppIconChanged:
         return actionHandler.selectedAppIconChanged(state: &state)

      case .copyEnvironmentInfoPressed:
         return actionHandler.copyEnvironmentInfoPressed(state: &state)

      case .binding:
         return .none  // assignment handled by `.binding()` below

      case .errorOccurred, .setErrorHandling, .errorHandling:
         return actionHandler.handleErrorAction(state: &state, action: action)
      }
   }
   .binding()
   .recordAnalyticsEvents(eventType: AppInfoEvent.self) { state, action, env in
      switch action {
      case .onAppear:
         return .init(event: .onAppear)

      case .onDisappear:
         return .init(event: .onDisappear)

      case .copyEnvironmentInfoPressed:
         return .init(event: .copyEnvironmentInfoPressed)

      case .errorOccurred(let error):
         return .init(event: .errorOccurred, attributes: ["errorCode": error.errorCode])

      case .binding, .setErrorHandling, .errorHandling, .selectedAppIconChanged:
         return nil
      }
   }
)

Beachte zuerst, dass der appInfoReducer auf globaler Ebene definiert ist, was sich schon falsch anfuehlt. Dann werden 7 Zeilen benoetigt, um das Child-Feature ErrorHandling mit diesem Feature zu verbinden. Und dir wird auffallen, dass ich einen weiteren Typ namens AppInfoActionHandler eingefuehrt habe, der die eigentliche Logik des Reducers enthaelt. Der Grund dafuer ist, dass ein Teil meiner Reducer-Logik recht lang ist und wenn ich die gesamte Logik im switch-case behalten wuerde, haette ich viele Cases mit viel Code darin. Xcode bietet aber keine Features, um innerhalb von switch-Cases zu navigieren. Also habe ich die Logik in Funktionen eines anderen Typs ausgelagert. Schliesslich wirst du bemerken, dass ich eine Extension auf dem AnyReducer-Typ selbst fuer Analytics-Zwecke definiert habe:

import ComposableArchitecture

extension AnyReducer {
   /// Returns a `Result` where each action coming to the store first attempts to record an analytics event.
   /// In the implementation, switch over `action` and return an ``Analytics.AttributedEvent`` if the action should be recorded, or else return `nil`.
   public func recordAnalyticsEvents<Event: AnalyticsEvent>(
      eventType: Event.Type,
      event toAttributedEvent: @escaping (State, Action, Environment) -> Analytics.AttributedEvent<Event>?
   ) -> Self {
      .init { state, action, env in
         guard let attributedEvent = toAttributedEvent(state, action, env) else { return self.run(&state, action, env) }

         return .concatenate(
            .fireAndForget { Analytics.shared.record(attributedEvent: attributedEvent) },
            self.run(&state, action, env)
         )
      }
   }
}

AnyReducerExt.swift

Das Einzige, was das tut, ist ein Event in meiner Analytics-Engine zu erfassen, die von TelemetryDeck angetrieben wird, fuer die Actions, die ich aufzeichnen moechte. Ich finde das sehr nuetzlich als Erinnerung, bei jeder neuen Action, die ich zum AppInfoAction-Enum hinzufuege, immer zu ueberlegen, ob ich das neue Event auf voellig anonymisierte Weise analysieren moechte. Damit das richtig funktioniert, muss ich auch fuer jedes Feature einen weiteren Typ definieren, hier AppInfoEvent:

import AppFoundation

enum AppInfoEvent: String {
   case onAppear
   case onDisappear
   case copyEnvironmentInfoPressed
   case errorOccurred
}

extension AppInfoEvent: AnalyticsEvent {
   var idComponents: [String] {
      ["AppInfo", self.rawValue]
   }
}

AppInfoEvent.swift

Dieses Enum definiert alle Events, die ich erfassen moechte, und die idComponents-Property hilft beim automatischen Erstellen eines Strings, wenn ein Event-Name an meinen Analytics-Anbieter uebergeben wird. Das AnalyticsEvent-Protokoll ist etwas am Thema vorbei, aber falls es dich interessiert – es ist einfach das hier:

import Foundation

public protocol AnalyticsEvent: Identifiable where ID == String {
   var idComponents: [String] { get }
}

extension AnalyticsEvent {
   public var id: String {
      self.idComponents.joined(separator: ".")
   }
}

AnalyticsEvent.swift (Teil eines Hilfsmoduls namens Analytics)

Dir ist vielleicht auch ein AppEnv-Typ aufgefallen, den ich fuer die Environment verwende. Das ist eigentlich ein gemeinsamer Typ, den ich ueberall wiederverwendet habe, wo ich nur einen einfachen Environment-Typ mit einer mainQueue brauchte und der ueberall in meiner Anwendung herumgereicht wird:

import CombineSchedulers
import Defaults
import Foundation

public struct AppEnv {
   public let mainQueue: AnySchedulerOf<DispatchQueue>

   public init(mainQueue: AnySchedulerOf<DispatchQueue>) {
      self.mainQueue = mainQueue
   }
}

#if DEBUG
   extension AppEnv {
      public static var mocked: AppEnv {
         .init(mainQueue: DispatchQueue.main.eraseToAnyScheduler())
      }
   }
#endif

Nun, die letzte der 7 Dateien ist AppInfoError und dieser Typ ist fuer dieses sehr einfache Feature tatsaechlich leer. Aber ich werde seinen Zweck in einem spaeteren Artikel erklaeren, in dem ich meinen Ansatz zur Fehlerbehandlung im Detail beschreibe. Alles, was du fuer diesen Artikel wissen musst: Wenn etwas Unerwartetes passiert, moechte ich ein Sheet mit hilfreichen Informationen direkt im Kontext eines Features anzeigen.

Point-Free neigt dazu, alle ihre Typen in einer einzigen Datei zu behalten, was fuer ein kleines Feature wie AppInfo funktionieren mag. Aber ein typisches Feature von mir umfasst etwa 500 bis 1.500 Zeilen Code mit allen Typen zusammen. Ich neige dazu, meine Dateien klein zu halten, mit einem Soft Cap von 400 Zeilen und einem Hard Cap von 1.000 Zeilen (siehe SwiftLint-Regelstandards). Mit 314 Zeilen wuerde selbst dieses sehr einfache Feature schon nahe an das Soft Cap kommen, und einige meiner Features wuerden sogar ueber das Hard Cap hinausgehen. Alles in einer Datei zu halten ist also fuer mich ein No-Go. Deshalb habe ich stattdessen jeden Typ in eine eigene Datei gelegt. Aber ich war auch nie 100% zufrieden damit, weil alles etwas verstreut wirkte. Im Idealfall waere zusammengehoeriger Code immer noch beieinander, aber das Feature waere trotzdem gleichmaessig auf weniger als 7 Dateien verteilt. Schauen wir also, wie die Dinge nach der Migration aussehen.

Moechtest du hier deine Werbung sehen? Kontaktiere mich unter ads@fline.dev.

Nach der Migration (Praxisbeispiel)

In der TCA-1.0-Beta hat Point-Free das Konzept eingefuehrt, ein spezielles struct zu erstellen, das als Scope oder Namespace fuer ein Feature dient, und Hilfstypen wie State und Action als Subtypen in diesen Namespace-Typ zu legen. Sie haben diesem Namespace den Namen Feature gegeben und ihn Reducer-konform gemacht, was in etwa so aussieht:

struct Feature: Reducer {
  struct State: Equatable { … }
  enum Action: Equatable { … }

  func reduce(into state: inout State, action: Action) -> Effect<Action> { … }
}

Fuer mich ist diese Struktur aber aus zwei Gruenden verwirrend:

1. Den Namespace mit dem Suffix Feature zu benennen, waehrend er Reducer-konform ist, erscheint mir unstimmig. Ueberall, wo ein reducer-Parameter uebergeben werden muss, wuerden wir ein Feature uebergeben – was verwirrend waere. Der Namespace muesste dann eher Reducer heissen, aber dann haetten wir Subtypen ueber Reducer.State und Reducer.Action, was auch nicht korrekt ist.

2. Wenn man die Idee eines Feature-Namespaces voll annimmt, wuerde ich einen Typ Reducer innerhalb des Feature-Typs der Konsistenz halber erwarten.

Stattdessen habe ich mich dafuer entschieden, das Feature tatsaechlich als Namespace zu verwenden und auch einen Reducer-Subtyp hineinzusetzen, der Reducer-konform ist. Nun, das wuerde zu struct Reducer: Reducer fuehren – ein Namenskonflikt. Loesen wir das mit einem Typealias:

import ComposableArchitecture

public typealias FeatureReducer: Reducer

Jetzt koennten wir einen Reducer: FeatureReducer-Subtyp in unserem Feature-Namespace definieren. Und wo wir schon dabei sind – ich vergesse tatsaechlich oft, einen public Initializer fuer meine Reducer zu schreiben (was noetig ist, da die App modularisiert ist), also definieren wir stattdessen ein neues oeffentliches Protokoll, das einen public Initializer verlangt:

import ComposableArchitecture

public protocol FeatureReducer: Reducer {
   init()
}

Tatsaechlich gibt es noch mehr Dinge, die ich bei anderen TCA-Feature-Typen gerne vergesse. Machen wir das alles zu einer klaren Anforderung, indem wir Protokolle wie FeatureReducer fuer alle Arten von Subtypen innerhalb eines Feature implementieren:

import Analytics
import ComposableArchitecture
import ErrorHandling
import SwiftUI

public protocol FeatureState: Equatable {
   var childErrorHandling: ErrorHandlingFeature.State? { get set }
}

public protocol FeatureAction: Equatable {
   associatedtype ErrorType: FeatureError

   static func errorOccurred(_ error: ErrorType) -> Self
   static func childErrorHandling(_ action: PresentationAction<ErrorHandlingFeature.Action>) -> Self
}

public protocol FeatureEvent: AnalyticsEvent {}

public protocol FeatureError: HelpfulError {}

public protocol FeatureReducer: Reducer {
   init()
}

public protocol FeatureView: View {
   associatedtype Action: FeatureAction
}

Auszug aus Feature.swift (Teil eines Hilfsmoduls)

Beachte, dass ich verlange, dass FeatureState und FeatureAction Equatable sind, was in TCA immer eine gute Idee ist, um sie testbar zu machen – und alle meine State- und Action-Typen konformieren bereits dazu. Zusaetzlich habe ich FeatureView entsprechend definiert, plus die zwei zusaetzlichen Typen, die ich fuer meine Analytics- und Error-Handling-Beduerfnisse brauche. Beachte auch, dass ich mich entschieden habe, statt dem Suffix State bei allen Child-Features (wie bei errorHandlingState im Feature zuvor), das Praefix child zu verwenden – wie in childErrorHandling. Das erleichtert das Finden von Child-Features beim Scannen der Attribute von oben nach unten.

Mit diesen Protokollen koennen wir dem Compiler jetzt sogar beibringen, was ein “Feature” eigentlich ist, indem wir ein weiteres Protokoll definieren, das alle Subtypen verlangt:

/// A namespace for a TCA feature with extra requirements for Analytics and Error Handling.
public protocol Feature {
   associatedtype State: FeatureState
   associatedtype Action: FeatureAction
   associatedtype Event: FeatureEvent
   associatedtype Error: FeatureError
   associatedtype Reducer: FeatureReducer
   associatedtype View: FeatureView
}

/// A helper to declare a `Store` of a `Feature` type.
public typealias FeatureStore<F: Feature> = Store<F.State, F.Action>

Auszug aus Feature.swift (Teil eines Hilfsmoduls)

Ich habe auch einen Typealias zum Definieren des store in unseren Views erstellt, aehnlich dem neuen StoreOf-Typealias von Point-Free, aber spezifisch fuer ein Feature.

Gut, mit dieser Vorarbeit schauen wir uns an, wie das migrierte Feature aussieht:

import AppFoundation
import AppUI

public enum AppInfoFeature: Feature {
   public struct State: FeatureState {
      // see below
   }

   public enum Action: FeatureAction, BindableAction {
      // see below
   }

   public enum Event: String, FeatureEvent {
      // see below
   }

   public enum Error: FeatureError {
      // ...
   }

   public struct Reducer: FeatureReducer {
      // see below
   }

   public struct View: FeatureView {
      // see below
   }
}

extension AppInfoFeature.Event: AnalyticsEvent {
   public var idComponents: [String] {
      ["AppInfo", self.rawValue]
   }
}

Ueberblick ueber AppInfoFeature.swift

Beachte, dass ich ein enum statt eines struct fuer das Feature definiert habe, um zu verdeutlichen, dass es sich lediglich um einen Namespace handelt. Ausserdem konformieren alle Subtypen genau zu dem, was ihr Name ist, mit Feature als Praefix – z. B. State: FeatureState. Das macht es wirklich einfach, sich zu merken, wozu man konformieren muss, und den Code konsistenter.

Hier ist der State-Body, den ich im obigen Code-Beispiel fuer einen besseren Ueberblick ausgelassen habe:

   public struct State: FeatureState {
      @BindingState
      var showEnvInfoCopiedToClipboard: Bool = false
      var selectedAppIcon: AppIcon

      @PresentationState
      public var childErrorHandling: ErrorHandlingFeature.State?

      public init() {
         self.selectedAppIcon = Defaults[.selectedAppIcon]
      }
   }

Das sieht dem urspruenglichen AppInfoState recht aehnlich, aber diesmal ist das Child von errorHandlingFeature in childErrorHandling umbenannt. Und weil ich auch das Child-Feature selbst migriert habe, hat sich der Typ von ErrorHandlingState? zu ErrorHandlingFeature.State? geaendert. Ausserdem habe ich das @PresentationState-Attribut fuer den neuen Navigationsstil in TCA 1.0 hinzugefuegt, der Dismissal von innerhalb des Childs unterstuetzt, ueber @Dependency(\.dismiss) und den Aufruf von self.dismiss() im Reducer.

Als Naechstes schauen wir uns unseren Action-Subtyp an:

   public enum Action: FeatureAction, BindableAction {
      case onAppear
      case onDisappear
      case selectedAppIconChanged
      case copyEnvironmentInfoPressed

      case binding(BindingAction<State>)

      case errorOccurred(Error)
      case childErrorHandling(PresentationAction<ErrorHandlingFeature.Action>)
   }

Das ist auch weitgehend eine Kopie der urspruenglichen AppInfoAction, aber beachte, dass die Child-Action jetzt einen anderen Typ hat. Sie hat sich von HelpfulErrorAction zu PresentationAction<HelpfulErrorFeature.Action> geaendert – ein Wrapper, der alle Child-Actions in einen Case namens .presented legt. Der andere Case .dismiss meldet zurueck, dass das Child geschlossen wurde, falls das Parent darauf reagieren muss. Dank PresentationAction konnte ich die Action setErrorHandling(isPresented:) komplett entfernen, da dies jetzt in TCA-eigenen Typen gekapselt ist.

Schauen wir uns jetzt an, wie unsere View aussieht:

   public struct View: FeatureView {
      let store: FeatureStore<AppInfoFeature>

      public init(store: FeatureStore<AppInfoFeature>) {
         self.store = store
      }
   }

Wie du siehst, verwende ich den FeatureStore-Typealias anstelle des alten Stils Store<State, Action> oder des TCA-1.0-Stils StoreOf<Feature>. Aber wo ist alles andere, das eine SwiftUI-View definiert, wie die body-Property? Nun, die Implementierung einer View ist typischerweise einer der laengsten Teile eines Features, also habe ich mich dafuer entschieden, die strukturellen Teile aller Subtypen an einem Ort zu behalten, waehrend Konformitaeten zu Protokollen, die viel Code erfordern, in Extension-Dateien ausgelagert werden.

Die Implementierung der View ist als Extension in einer separaten Datei:

import AppFoundation
import AppUI

extension AppInfoFeature.View: View {
   public typealias Action = AppInfoFeature.Action

   public var body: some View {
      WithViewStore(self.store, observe: { $0 }) { viewStore in
         VStack(alignment: .leading, spacing: 20) {
            // same code as before
         }
         .frame(width: 320)
         .padding()
         .onAppear { viewStore.send(.onAppear) }
         .onDisappear { viewStore.send(.onDisappear) }
         .sheet(store: self.store.scope(state: \.$childErrorHandling, action: Action.childErrorHandling)) { childStore in
            HelpfulErrorFeature.View(store: childStore)
         }
      }
   }
}

#if DEBUG
   struct AppInfoView_Previews: PreviewProvider {
      static let store = Store(initialState: AppInfoFeature.State(), reducer: AppInfoFeature.Reducer())

      static var previews: some View {
         AppInfoFeature.View(store: self.store).previewVariants()
      }
   }
#endif

AppInfoFeatureView.swift*

Die Implementierung der body-Property ist so ziemlich die gleiche wie vorher. Aber beachte, dass der 11-zeilige .sheet-Modifier auf nur 3 Zeilen geschrumpft ist. Das verdanken wir den neuen Navigationstools mit @PresentationState und PresentationAction. Eine weitere Aenderung ist beim static let store im PreviewProvider passiert: Es gibt keinen Environment-Parameter mehr, der an den Store uebergeben werden muss!

Schauen wir uns den Reducer-Subtyp an, um zu erfahren warum:

   public struct Reducer: FeatureReducer {
      @Dependency(\.mainQueue)
      var mainQueue

      @Dependency(\.continuousClock)
      var clock

      public init() {}
   }

Beachte die Verwendung des @Dependency-Attributs. Es erinnert dich vielleicht an das @Environment-Attribut in SwiftUI, und es funktioniert tatsaechlich genauso. Dieses neue Attribut ist der Grund, warum in TCA 1.0 kein Environment-Typ mehr benoetigt wird. Stattdessen werden alle Dependencies mit dem @Dependency-Attribut deklariert. Das erlaubt mir, den AppEnv-Typ, den ich vorher herumgereicht habe, komplett zu entfernen.

Auch hier vermisst du vielleicht die eigentliche Implementierung des Reducer-Protokolls. Nun, die Implementierung des Protokolls ist der zweite Teil eines Features, der recht lang werden kann, also habe ich auch das in eine eigene Datei ausgelagert:

import AppFoundation
import AppUI

extension AppInfoFeature.Reducer: Reducer {
   public typealias State = AppInfoFeature.State
   public typealias Action = AppInfoFeature.Action

   enum ShowEnvInfoCopiedId {}

   public var body: some ReducerOf<Self> {
      AnalyticsEventRecorderOf<AppInfoFeature> { state, action in
         switch action {
         case .onAppear:
            return .init(event: .onAppear)

         case .onDisappear:
            return .init(event: .onDisappear)

         case .copyEnvironmentInfoPressed:
            return .init(event: .copyEnvironmentInfoPressed)

         case .errorOccurred(let error):
            return .init(event: .errorOccurred, attributes: ["errorCode": error.errorCode])

         case .binding, .childErrorHandling, .selectedAppIconChanged:
            return nil
         }
      }

      BindingReducer()

      Reduce<State, Action> { state, action in
         switch action {
         case .onAppear, .onDisappear:
         return .none  // for analytics only

      case .selectedAppIconChanged:
         return self.selectedAppIconChanged(state: &state)

      case .copyEnvironmentInfoPressed:
         return self.copyEnvironmentInfoPressed(state: &state)

      case .binding:
         return .none  // assignment handled by `BindingReducer()` above

      case .errorOccurred, .childErrorHandling:
         return self.handleHelpfulErrorAction(state: &state, action: action)
         }
      }
      .ifLet(\.$childErrorHandling, action: /Action.childErrorHandling) {
         HelpfulErrorFeature.Reducer()
      }
   }

   private func selectedAppIconChanged(...)

   private func copyEnvironmentInfoPressed(state: inout State) -> Effect<Action> {
      Pasteboard.string = Constants.GitHub.environmentInfo
      state.showEnvInfoCopiedToClipboard = true

      return .run { send in
         try await self.clock.sleep(for: Constants.toastMessageDuration)
         try Task.checkCancellation()
         await send(.set(\.$showEnvInfoCopiedToClipboard, false))
      }
      .cancellable(id: ShowEnvInfoCopiedId.self, cancelInFlight: true)
   }

   private func handleHelpfulErrorAction(...)
}

AppInfoFeatureReducer.swift*

Beachte zuerst die voellig andere Struktur. Es werden keine globalen reducer-Variablen mehr benoetigt. Stattdessen wird eine body-Property implementiert, ganz aehnlich wie beim View-Protokoll in SwiftUI. Und die Analogie endet nicht dort – die Struktur ist auch sehr SwiftUI-aehnlich, mit einer einfachen Liste verschiedener Reducer, die zusammen den AppInfoFeature.Reducer bilden, einschliesslich eines namens BindingReducer(), der .binding() ersetzt. Beachte auch, dass die 7 Zeilen Code fuer die Verbindung des Child-Features auf nur 3 Zeilen mit der neuen .ifLet-API geschrumpft sind. Zusaetzlich konnte ich, anstatt einen eigenen ActionHandler-Typ definieren zu muessen, in dem ich die Logik fuer die Reaktion auf Actions untergebracht habe, diese Funktionen einfach in den Reducer-Typ selbst verschieben – weil wir uns jetzt in einem Typ befinden und nicht auf globaler Ebene. Ausserdem nutzt die Implementierung von copyEnvironmentInfoPressed die neuen async-APIs. Vorher war sie im weniger lesbaren Combine-Stil implementiert:

      Pasteboard.string = Constants.GitHub.environmentInfo
      state.showEnvInfoCopiedToClipboard = true

      return .init(value: .set(\.$showEnvInfoCopiedToClipboard, false))
         .delay(for: Constants.toastMessageDuration, scheduler: env.mainQueue)
         .eraseToEffect()
         .cancellable(id: ShowEnvInfoCopiedId.self, cancelInFlight: true)

Auszug aus dem alten AppInfoActionHandler.swift

Schliesslich musste ich durch den neuen SwiftUI-artigen Function-Builder-Stil meine AnyReducer-Extension-Funktion recordAnalyticsEvents in einen einfachen Reducer umwandeln, der die Ausfuehrungslogik als Property speichert:

import ComposableArchitecture
import Foundation

/// Returns a `Reducer` where each action coming to the store attempts to record an analytics event.
public struct AnalyticsEventRecorder<State, Action, Event: AnalyticsEvent>: Reducer {
   let toAttributedEvent: (State, Action) -> Analytics.AttributedEvent<Event>?

   /// In the event closure, switch over `action` and return an ``Analytics.AttributedEvent`` if the action should be recorded, or else return `nil`.
   public init(event toAttributedEvent: @escaping (State, Action) -> Analytics.AttributedEvent<Event>?) {
      self.toAttributedEvent = toAttributedEvent
   }

   public func reduce(into state: inout State, action: Action) -> Effect<Action> {
      if let attributedEvent = self.toAttributedEvent(state, action) {
         Analytics.shared.record(attributedEvent: attributedEvent)
      }

      return .none
   }
}

/// Convenient way to declare an `AnalyticsEventRecorder`, but requires `Reducer` to conform to `Feature`.
public typealias AnalyticsEventRecorderOf<F: Feature> = AnalyticsEventRecorder<F.State, F.Action, F.Event>

AnalyticsEventRecorder.swift (aus einem Hilfsmodul)

Der Body des Analytics-Helpers im Reducer oben hat sich ueberhaupt nicht geaendert – ich habe ihn einfach von der vorherigen Hilfsfunktion in den Initializer dieses neuen Reducers kopiert.

Und das war’s – das gesamte AppInfo-Feature ist auf TCA 1.0 migriert. Die gesamte Dateistruktur sieht jetzt so aus, mit nur 3 Dateien statt 7:

Beachte, dass ich * als Trennzeichen verwende, um zu signalisieren, dass die Datei den Hauptteil eines Subtyps enthaelt. Natuerlich koennten wir . als Trennzeichen verwenden, sodass der Name sich wie AppInfoFeature.Reducer.swift liest. Aber weil .R von .Reducer vor .s von .swift sortiert wird, wuerden die Subtyp-Dateien ueber der Haupt-Feature-Datei AppInfoFeature.swift erscheinen – also habe ich mich fuer ein Trennzeichen entschieden, das aehnlich wie ein Punkt aussieht, aber niedrigere Prioritaet als . hat, was zu * fuehrte.

Die SwiftLint-Regel file_name, die ich aktiviert habe, zeigte mir mit diesem Benennungsstil eine Warnung. Aber ich konnte das einfach anpassen, indem ich dies zur Konfigurationsdatei hinzufuegte:

file_name:
   nested_type_separator: '*'

Fazit

Die Migration meiner mittelgrossen App auf den neuen API-Stil von TCA 1.0 war viel Arbeit, aber der Grossteil bestand aus dem Einrichten von Dateistrukturen, Suchen und Ersetzen und dem Verschieben von bestehendem Code an andere Stellen. Und ich habe einige Zeit investiert, um eine gute Struktur herauszufinden, die mir gefaellt. Ich denke, wenn ich es nochmal fuer eine andere App mit meinen Erkenntnissen machen muesste, waere ich wahrscheinlich in 2–3 Tagen statt 5 fertig.

Nur an wenigen Stellen musste ich tatsaechlich Code anpassen, hauptsaechlich bei der Migration von Combine-artigem Effect-Code in meinen Reducern zu async/await-artigem Code. Aber dank grossartiger Dokumentation und Warnungen war immer ziemlich klar, was zu tun ist. Fuer alle, die eine aehnliche Migration durchfuehren, hier sind die 3 Links, die ich am nuetzlichsten fand:

1. Concurrency Beta

2. Migrating to the Reducer protocol

3. Composable Navigation Beta

Und wenn es eine Episode gibt, die einen guten Ueberblick ueber die Fortschritte in TCA 1.0 bietet, dann sind es die ersten ~35 Minuten von Episode #222, die Composable Navigation einfuehrt. Schau sie dir an, um schnell eine Idee davon zu bekommen, wie sich die Dinge im letzten Jahr veraendert haben.

Du fandest diesen Artikel hilfreich? Hol dir meinen Expertenrat!

Ich habe mich kürzlich entschieden, am größten Feature für RemafoX bisher zu arbeiten, und während ich überlegte, wo ich anfangen soll, fand ich mich in über 70 Targets wieder – bei einem weniger als ein Jahr alten Projekt. Ich modularisiere meine App für klare Code-Trennung und schnellere Build-Zeiten (= schnellere SwiftUI Previews, Tests und mehr) mit dem klassischen SwiftPM-basierten Ansatz, den Point-Free in dieser kostenlosen Episode vorgestellt hat. Da ich vorhabe, über Jahre an dieser App zu arbeiten (die 27 Features online sind nur die Spitze des Eisbergs, ich habe noch viel mehr Ideen), habe ich mich entschlossen, erst mal aufzuräumen. Denn eine Runde Refactoring zwischen Features hält die Codebasis sauber und macht den Entwickler glücklich! 😇

Ich erinnerte mich daran, dass ich das @_exported-Attribut entdeckt hatte, als ich Swift-Evolution-Threads durchlas, um eine der Ausgaben meines zugehörigen Newsletters vorzubereiten. Obwohl es nicht empfohlen wird, APIs mit Unterstrich zu verwenden, da sich ihr Verhalten ändern oder sie sogar komplett entfernt werden könnten, fehlten mir Alternativen für mein Ziel, die vielen unorganisierten Targets aufzuräumen. Genau deshalb habe ich mich davon überzeugt, dass die Chancen, dass dieses Attribut komplett entfernt wird, relativ gering sind. Wenn überhaupt, glaube ich, dass der zugehörige Pitch irgendwann aufgegriffen wird und seinen Weg ins offizielle Swift findet, sodass wir @_exported mit dem dann gewählten Namen ersetzen können. Außerdem habe ich herausgefunden, dass Point-Free in The Composable Architecture ebenfalls auf dieses Attribut setzt, einem Framework, von dem meine App bereits stark abhängt. Warum also nicht voll darauf setzen?

Kurz gesagt hilft das Attribut bei Folgendem: Stell dir vor, du hast 10 Feature-Module und 5 Helfer-Module. In jeder Datei der 10 Features importiere ich tendenziell alle (oder die meisten) dieser 5 Helfer-Module, was zu so etwas führt:

import Assets
import Analytics
import ComposableArchitecture
import Constants
import Defaults
import HandySwift
import HelpfulErrorUI
import ReusableUI
import SFSafeSymbols
import SwiftUI
import Utility

Und das wiederholt sich immer wieder. Ok, es stimmt, dass nicht alle in jeder einzelnen Datei eines Targets gebraucht werden, aber die Wahrheit ist auch, dass Xcode das gesamte Modul ohnehin linkt, sobald eine einzige Datei im Modul es importiert – sie also in allen Dateien zu importieren, würde die Build-Zeiten nicht beeinflussen (soweit ich weiß). Mit @_exported import können wir all diese Imports kombinieren, indem wir ein neues Target erstellen, es z.B. CoreDependencies nennen und eine Swift-Datei darin mit folgendem Inhalt anlegen:

@_exported import Assets
@_exported import Analytics
@_exported import ComposableArchitecture
@_exported import Constants
@_exported import Defaults
@_exported import HandySwift
@_exported import HelpfulErrorUI
@_exported import ReusableUI
@_exported import SFSafeSymbols
@_exported import SwiftUI
@_exported import Utility

Jetzt importiert import CoreDependencies automatisch auch alle anderen Module!

Aber ist es wirklich die richtige Lösung, alles in eine Gruppe namens CoreDependencies zu packen? Ein weiteres Problem neben den zu oft wiederholten Imports ist, dass ich aktuell all diese 70 Module alphabetisch sortiere, weil mir eine andere Art von Gruppierung oder Struktur fehlt. Dieses Fehlen einer Gruppierung macht es nicht nur schwieriger, das richtige Modul zu finden, wenn ich ungefähr weiß, was ich suche, aber den genauen Namen nicht mehr kenne. Es kann auch zu zirkulären Abhängigkeiten führen, wenn man an Features arbeitet und dabei möglichst viel Code wiederverwenden will. Es erfordert strategische Planung, was wohin gehört, um Code wiederzuverwenden und gleichzeitig zyklische Abhängigkeiten zu vermeiden, die zu Kompilierfehlern führen.

Die Lösung

✨ UPDATE: Für neue/kleinere Apps verwende ich eine vereinfachte Version dessen, was ich unten im Detail beschreibe. Siehe mein FlineDevKit-Repository für mehr.

Der beste Weg, eine praktische Lösung für ein Problem zu finden, ist, sich ein reales Beispiel anzuschauen. Hier also eine Auswahl von Modulen, die ich tatsächlich in RemafoX verwende:

Analytics
Assets
BetterCodable
CommandLineSetup
ComposableArchitecture
Constants
FilesSearch
Foundation
HandySwift
HelpfulErrorUI
MachineTranslation
Paywall
ProjectsBrowser
ReusableUI
SFSafeSymbols
Settings
SwiftUI
Utility

Ja, ich habe auch Foundation und SwiftUI in der Liste oben aufgeführt. Warum? Weil sie am Ende des Tages eben auch Dependencies sind, die importiert werden müssen, genau wie jede andere Dependency, die wir importieren, ob extern oder intern. Ich betrachte sie als eingebaute externe Dependencies. Du bist es vielleicht gewohnt, mindestens import Foundation in jeder Swift-Datei zu haben, aber tatsächlich kannst du Swift-Code auch ohne Foundation schreiben – du hast dann eben nur die grundlegenden Swift-Features inklusive allem, was in der Swift Standard Library enthalten ist. Das funktioniert!

Und diese beiden Imports, die wir alle so oft machen, repräsentieren tatsächlich eine Apple-interne Gruppierung von Features/Helfern: Apple bündelt eine ganze Menge Funktionalität hinter Foundation, und das Gleiche macht Apple mit SwiftUI oder UIKit/AppKit. Der entscheidende Faktor scheint zu sein, dass alles, was eine Art UI darstellt oder direkt mit UI zusammenhängt, in eine Gruppe gehört, und alles, was keine UI darstellt oder nicht direkt mit UI zusammenhängt, in eine andere. Das Naheliegendste wäre also, ihrem Beispiel zu folgen – wir könnten sogar ihre Benennung übernehmen, indem wir Foundation für die Nicht-UI-Gruppe und UI (das sowohl in SwiftUI als auch in UIKit vorkommt) für die UI-Gruppe verwenden. Da unsere Gruppen spezifisch für eine App-Domäne sind, wären die resultierenden Namen für unsere Gruppen: AppFoundation und AppUI.

Wenden wir das mal auf die obige Modulliste an:

// AppFoundation
Analytics
BetterCodable
CommandLineSetup
Constants
FilesSearch
Foundation
HandySwift
MachineTranslation
Utility

// AppUI
Assets
ComposableArchitecture
HelpfulErrorUI
Paywall
ProjectsBrowser
SFSafeSymbols
ReusableUI
Settings
SwiftUI

Das sieht schon besser aus. Aber es gibt noch etwas, das wir von Apples Framework-Struktur lernen können: Apple linkt nicht jedes Nicht-UI-Feature als Teil von Foundation, und sie liefern auch nicht allen SwiftUI-bezogenen Code als Teil von SwiftUI aus. Combine und Charts sind zwei Frameworks, die wir separat importieren müssen. Warum werden sie nicht als Teil von Foundation und SwiftUI ausgeliefert? Weil sie nur in bestimmten Domänen nützlich sind und möglicherweise nicht in einem globaleren Kontext gebraucht werden.

Wenn du dich an das ursprüngliche Problem erinnerst: Ich hatte einen Satz von Modulen, die ich immer und immer wieder an vielen Stellen importiert habe, weil sie global nützliche Helfer waren, und nicht nur in bestimmten Domänen. Es ergibt also Sinn, sie unter einem einheitlichen Gruppennamen zu importieren. Aber was genau ist ein Helfer? Was unterscheidet ihn von einem domänenspezifischeren Feature?

Ich persönlich nenne ein Feature dann einen “Helfer” oder ein “Utility”-Feature, wenn seine globale Verfügbarkeit viel nützlicher ist, als sie dem Entwicklungsprozess schadet. Das ist natürlich etwas subjektiv, aber als Faustregel mache ich es so: Wenn ich das Feature bereits in mehreren verschiedenen Teilen meiner App verwende und mir zusätzlich 2 oder 3 potenzielle neue Features vorstelle, die ich irgendwann in Zukunft hinzufügen könnte, und mindestens eines davon es ebenfalls nutzen könnte – dann ist es wahrscheinlich global sehr nützlich.

Konkreter gesagt würde ich die obige Modulliste so aufteilen:

// (global nützliche) Helfer
Analytics
Assets
BetterCodable
ComposableArchitecture
Constants
Foundation
HandySwift
HelpfulErrorUI
ReusableUI
SFSafeSymbols
SwiftUI
Utility

// (domänenspezifische) Features
CommandLineSetup
FilesSearch
MachineTranslation
Paywall
ProjectsBrowser
Settings

Wenn wir nun die beiden Trennungsdimensionen kombinieren, erhalten wir etwas wie den folgenden Graphen mit 4 Quadranten und Abhängigkeiten dazwischen:

Hier ein paar wichtige Dinge zu beachten:

1. Die ⬆️ obere “Feature”-Hälfte baut auf der unteren “Helfer”-Hälfte auf, deshalb:

2. Die ↖️ grünen “Nicht-UI-Feature”-Module können import AppFoundation verwenden.

3. Die ↗️ roten “UI-Feature”-Module können beides importieren, AppFoundation und AppUI.

4. Innerhalb einer Gruppe (eines Quadranten) können Module voneinander abhängen (Zyklen vermeiden!).

5. ➡️ “UI”-Module können von ⬅️ “Nicht-UI”-Modulen oder von AppFoundation abhängen.

6. Die ⬇️ unteren “Helfer” dürfen niemals von den “Features” oben importieren!

7. Externe Module können auch “Features” sein (siehe ↖️, aktuell habe ich keine in ↗️)

Um diese Struktur umzusetzen, habe ich einfach ein neues Modul namens AppFoundation erstellt sowie eine neue Swift-Datei darin namens AppFoundation.swift mit folgendem Inhalt:

// System
@_exported import Foundation

// Internal
@_exported import Analytics
@_exported import Constants
@_exported import Utility

// External
@_exported import BetterCodable
@_exported import HandySwift

Ich habe auch ein Modul AppUI mit folgendem Inhalt für AppUI.swift darin erstellt:

// System
@_exported import SwiftUI

// Internal
@_exported import Assets
@_exported import HelpfulErrorUI
@_exported import ReusableUI

// External
@_exported import ComposableArchitecture
@_exported import SFSafeSymbols

Jetzt kann ich die 11 Imports aus dem Anfangsbeispiel dieses Artikels, die ich aus einer Datei innerhalb eines UI-Feature-Moduls entnommen habe, durch nur diese 2 Zeilen ersetzen:

import AppFoundation
import AppUI

11 Imports wurden dank des @_exported-Attributs auf nur 2 reduziert.

Beachte, dass ich nicht mal Foundation oder SwiftUI importieren musste. Und für jedes Nicht-UI-Feature brauche ich sogar nur eine einzige Zeile mit import AppFoundation!

Natürlich bedeutet das nicht, dass ich nie wieder etwas anderes importieren werde. Ich werde weiterhin Imports auf der vertikalen Achse haben, wo ein bestimmtes Modul ein anderes bestimmtes Modul innerhalb einer Gruppe importiert, z.B. ein ConfigFile-UI-Feature, das Kindkomponenten wie ConfigFileLinter und ConfigFileNormalizer importiert. Aber das sind domänenspezifische Imports, die nicht zu vielen sich wiederholenden Imports führen.

Als Letztes habe ich meine Products, Dependencies und Targets in meiner Package.swift-Datei nach diesen 4 Quadranten gruppiert. Dafür habe ich Pragma-Marks wie // MARK: - Non-UI Features in allen Abschnitten hinzugefügt und die zugehörigen Anweisungen alphabetisch sortiert hineingesetzt. Mein resultierendes Manifest sieht jetzt ungefähr so aus:

import PackageDescription

let package = Package(
   name: "RemafoX",
   platforms: [.macOS(.v12)],

   // MARK: - Products
   products: [
      // MARK: - Grouping Products
      .library(name: "AppFoundation", targets: ["AppFoundation"]),
      .library(name: "AppUI", targets: ["AppUI"]),
      .library(name: "AppTest", targets: ["AppTest"]),

      // MARK: - Non-UI Helper Products (AppFoundation)
      .library(name: "Analytics", targets: ["Analytics"]),
      .library(name: "Constants", targets: ["Constants"]),
      .library(name: "Utility", targets: ["Utility"]),

      // MARK: - UI Helper Products (AppUI)
      .library(name: "Assets", targets: ["Assets"]),
      .library(name: "HelpfulErrorUI", targets: ["HelpfulErrorUI"]),
      .library(name: "ReusableUI", targets: ["ReusableUI"]),

      // MARK: - Test Helper Products (AppTest)
      .library(name: "TestResources", targets: ["TestResources"]),

      // MARK: - Non-UI Feature Products
      .library(name: "CommandLineSetup", targets: ["CommandLineSetup"]),
      .library(name: "FilesSearch", targets: ["FilesSearch"]),
      .library(name: "MachineTranslation", targets: ["MachineTranslation"]),

      // MARK: - UI Feature Products
      .library(name: "Paywall", targets: ["Paywall"]),
      .library(name: "ProjectsBrowser", targets: ["ProjectsBrowser"]),
      .library(name: "Settings", targets: ["Settings"]),
   ],

   // MARK: - Dependencies
   dependencies: [
      // MARK: - Non-UI Helper Dependencies (AppFoundation)
      .package(url: "https://github.com/marksands/BetterCodable.git", from: "0.4.0"),
      .package(url: "https://github.com/sindresorhus/Defaults", from: "6.3.0"),
      .package(url: "https://github.com/FlineDev/HandySwift", branch: "main"),

      // MARK: - UI Helper Dependencies (AppUI)
      .package(url: "https://github.com/SFSafeSymbols/SFSafeSymbols", from: "3.3.0"),
      .package(url: "https://github.com/pointfreeco/swift-composable-architecture", from: "0.40.2"),

      // MARK: - Test Helper Dependencies (AppTest)
      .package(url: "https://github.com/pointfreeco/swift-custom-dump", from: "0.3.0"),

      // MARK: - Non-UI Feature Dependencies
      .package(url: "https://github.com/FlineDev/Microya", branch: "main"),
      .package(url: "https://github.com/JohnSundell/Splash.git", from: "0.16.0"),
      .package(url: "https://github.com/jakeheis/SwiftCLI.git", from: "6.0.3"),
      .package(url: "https://github.com/TelemetryDeck/SwiftClient", branch: "main"),

      // MARK: - UI Feature Dependencies
   ],

   // MARK: - Targets
   targets: [
      // MARK: - Grouping Targets
      .target(
         name: "AppFoundation",
         dependencies: [
            // Internal
            "Analytics",
            "Constants",
            "Utility",

            // External
            .product(name: "BetterCodable", package: "BetterCodable"),
            .product(name: "HandySwift", package: "HandySwift"),
         ]
      ),
      .target(
         name: "AppUI",
         dependencies: [
            // Internal
            "Assets",
            "HelpfulErrorUI",
            "ReusableUI",

            // External
            .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
            .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
         ]
      ),
      .target(
         name: "AppTest",
         dependencies: [
            // Internal
            "TestResources",

            // External
            .product(name: "CustomDump", package: "swift-custom-dump"),
         ]
      ),

      // MARK: - Non-UI Helper Targets (AppFoundation)
      .target(
         name: "Analytics",
         dependencies: [
            // Internal
            "Constants",

            // External
            .product(name: "HandySwift", package: "HandySwift"),
            .product(name: "TelemetryClient", package: "SwiftClient"),
         ]
      ),
      .testTarget(name: "AnalyticsTests", dependencies: ["AppTest", "Analytics"]),
      .target(
         name: "Constants",
         dependencies: [
            .product(name: "Defaults", package: "Defaults"),
            .product(name: "HandySwift", package: "HandySwift"),
         ]
      ),
      .target(
         name: "Utility",
         dependencies: [
            // Internal
            "Analytics",
            "Constants",

            // External
            .product(name: "HandySwift", package: "HandySwift"),
            .product(name: "Defaults", package: "Defaults"),
         ]
      ),
      .testTarget(name: "UtilityTests", dependencies: ["AppTest", "Utility"]),

      // MARK: - UI Helper Targets (AppUI)
      .target(
         name: "Assets",
         dependencies: [.product(name: "Defaults", package: "Defaults")],
         resources: [
            .process("Colors.xcassets"),
            .process("Images.xcassets"),
            .copy("Sounds"),
         ]
      ),
      .target(
         name: "HelpfulErrorUI",
         dependencies: [
            // Internal
            "AppFoundation",
            "Assets",
            "ReusableUI",
         ]
      ),
      .target(
         name: "ReusableUI",
         dependencies: [
            // Internal
            "AppFoundation",
            "Assets",

            // External
            .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
            .product(name: "Splash", package: "Splash"),
            .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
         ]
      ),

      // MARK: - Test Helper Targets (AppTest)
      .target(
         name: "TestResources",
         dependencies: [],
         path: "TestResources",
         exclude: ["Package.swift"],
         sources: ["TestResources.swift"],
         resources: [
            .copy("CustomSample"),
            .copy("EmptyFileStructureSamples"),
            .copy("GitHubSampleProjects"),
         ]
      ),

      // MARK: - Non-UI Feature Targets
      .target(name: "CommandLineSetup", dependencies: ["AppFoundation"]),
      .target(
         name: "MachineTranslation",
         dependencies: [
            // Internal
            "AppFoundation",

            // External
            .product(name: "Microya", package: "Microya"),
         ]
      ),
      .testTarget(
         name: "MachineTranslationTests",
         dependencies: ["AppFoundation", "AppTest", "MachineTranslation"],
         exclude: ["Resources/secrets.json.sample"],
         resources: [.copy("Resources/secrets.json")]
      ),

      // MARK: - UI Feature Targets
      .target(name: "Paywall", dependencies: ["AppFoundation", "AppUI"]),
      .target(
         name: "ProjectSetup",
         dependencies: [
            "AppFoundation",
            "AppUI",
            "ProjectDragAndDrop",
            "ProjectAnalyzer",
         ]
      ),
      .target(
         name: "Settings",
         dependencies: [
            "AppFoundation",
            "AppUI",
            "SettingsTabCurrentPlan",
            "SettingsTabGeneral",
            "SettingsTabMachineTranslation",
         ]
      ),
      // ... many more features related to Project, Settings etc.
   ]
)

☑️ Ähnlich wie AppFoundation und AppUI habe ich auch ein AppTest-Gruppierungs-Target in meiner App eingeführt, das ich verwende, um Imports von XCTest und Dependencies/Helfern wie CustomDump (sehr empfehlenswert!) zu vereinheitlichen.

Um alle relevanten Imports durch AppFoundation/AppUI zu ersetzen, habe ich diesen Trick angewandt:

1. Zuerst habe ich Xcodes Suchen & Ersetzen für jede @_exported-Library verwendet und alle Imports durch AppFoundation ersetzt, sodass ich am Ende viele Dateien mit mehrfachen Imports von AppFoundation hatte.

2. Dann habe ich die SwiftLint-Regel duplicate_imports verwendet, die Autokorrektur unterstützt. Installiere es über brew install swiftlint und führe dann diese 3 Zeilen aus:

echo "only_rules: [duplicate_imports]" > temp_swiftlint.yml
swiftlint lint --config temp_swiftlint.yml --path Sources --autocorrect
rm temp_swiftlint.yml

Passe den Parameter bei –path an, falls deiner anders als Sources ist.

1. Zum Schluss habe ich die Änderungen für Dateien, die in Modulen liegen, die selbst Teil von AppFoundation sind, mit Git zurückgesetzt, ebenso die AppFoundation.swift selbst.

2. Dann habe ich die obigen Schritte für AppUI wiederholt. Das Ganze hat weniger als 10 Minuten gedauert!

Das war’s! Wie du siehst, hatte ich vor dem Aufräumen ca. 2.000 Imports in meinem Projekt:

Nach dem Aufräumen habe ich jetzt nur noch 1.200 Imports, also rund 40 % weniger als vorher!

Außerdem ist meine Package.swift-Manifestdatei viel kürzer geworden, von 827 Zeilen auf 575 Zeilen – das ist ungefähr ein Drittel weniger. Und alles ist so viel strukturierter, ich bin begeistert! 😍

Fazit

Dank @_exported import und der Aufteilung von Modulen in vier Gruppen – durch die Fragen, ob sie (A) “UI-bezogen” oder “Nicht-UI-bezogen” und (B) eher “global nützlich” oder eher “domänenspezifisch” sind – kann ich jetzt eine beliebige Anzahl von “Helfer”-Modulen mit nur ein oder zwei import-Zeilen in meine “Feature”-Module importieren! Nicht nur das – diese Gruppen mit ihren Import-Regeln dienen auch als Leitfaden, um meinen Code im richtigen Modul zu platzieren und zirkuläre Abhängigkeiten zu vermeiden.

Das Ergebnis: Weniger Code schreiben, weniger Chancen für Build-Fehler – eine Win-win-Situation!

Am Ende beantworte ich auch einige häufig gestellte Fragen:

• Apple Silicon oder Intel?

• Wie viel Speicherplatz brauche ich?

• Wie viel RAM brauche ich?

• Was ist mit dem Mac Studio?

Dieser Artikel wurde zuletzt im Dezember 2024 aktualisiert. Wenn seitdem 6 Monate vergangen sind, schreib mir auf Bluesky und erinnere mich an ein Update.*

Der günstigste Mac für Entwickler (ab 750 $)

Hardware:

M4 Mac Mini (16 GB RAM & 256 GB SSD) für 600 $

• Monitor (mindestens 120 $)

• Kabellose Maus & Tastatur (mindestens 30 $)

Vorteile:

• Schnelle Build-Zeiten mit zukunftssicherem M4-Apple-Silicon-Prozessor

• Schnelle SSD, um Xcode-Projekte schnell zu öffnen (viele kleine Dateien)

• Insgesamt günstigste Option mit einem Gesamtpreis (inkl. Peripherie) von ca. 750 $

• Eingebaute Anschlüsse, kein Adapter nötig (5x USB-C, HDMI, LAN, 3,5 mm)

Nachteile:

• Nicht mobil (kein Laptop)

• Erfordert zusätzliche Peripherie (Maus, Tastatur, Monitor)

• 256 GB SSD reicht gerade so für die Entwicklung, kein Platz für andere Medien

Upgrade-Optionen

• 512 GB SSD, wenn du den Mac auch für andere Zwecke nutzen willst (+200 $)

• ODER eine externe 2-TB-SSD für einen etwas niedrigeren Preis kaufen (nur für Medien)

• Den 24” iMac für einen 4,5K-Monitor, Apple-Maus & -Tastatur holen (+550 $)

Empfohlene Zielgruppe

Wenn Geld das Hauptkriterium ist, z. B. weil es nur ein Hobby für dich ist, und du weißt, dass du von einem festen Platz aus coden wirst. Oder wenn du den Mac auch als Medienserver für dein Zuhause nutzen möchtest (mit einer externen Festplatte).

Der günstigste mobile Mac für Entwickler (ab 1.000 $)

Hardware:

13” M4 MacBook Air (16 GB RAM & 256 GB SSD) für 1.000 $

Vorteile:

• Schnelle Build-Zeiten mit ausreichendem M4-Apple-Silicon-Prozessor

• Schnelle SSD, um Xcode-Projekte schnell zu öffnen (viele kleine Dateien)

• Mobil (Laptop mit 13” eingebautem Bildschirm, Tastatur & Trackpad)

Nachteile:

• Teurer als der Mac mini (selbst mit inkludierter Peripherie)

• Eine externe Festplatte statt SSD-Upgrade zu nutzen ist nicht praktikabel

• Du musst einen USB-C-Adapter kaufen und mitnehmen für die Kompatibilität

• 256 GB SSD reicht gerade so für die Entwicklung, kein Platz für andere Medien

Upgrade-Optionen

• 512 GB SSD, wenn du den Mac auch für andere Zwecke nutzen willst (+200 $)

Empfohlene Zielgruppe

Wenn Geld ein Thema ist, du aber sowieso einen Laptop brauchst, z. B. weil du Student bist, und du flexibel sein und ihn immer mitnehmen willst.

Der beste Preis-Leistungs-Mac für Entwickler (ab 2.500 $)

Hardware:

16” M4 Pro MacBook Pro (24 GB & 512 GB) für 2.500 $

Vorteile:

• 14-Kern-M4-Pro mit nochmal ca. 50 % schnelleren Build-Zeiten (im Vergleich zum M4)

• Größerer & hochwertigerer 4K-, 120-Hz-, HDR-Bildschirm (im Vergleich zum Air)

• Längste Akkulaufzeit aller bisherigen Macs (länger als M4 Max oder 14”-Varianten)

• Eingebauter Kartenleser und HDMI-Anschluss & 1 zusätzlicher USB-C (im Vergleich zum Air)

• Schnelle 512-GB-SSD, um Xcode-Projekte schnell zu öffnen (viele kleine Dateien)

• 8 GB zusätzlicher RAM-Puffer für fortgeschrittenere Entwickler-Workflows

• Mobil (Laptop mit 16” eingebautem Bildschirm, Tastatur & Trackpad)

Nachteile:

• Ziemlich teuer (gesparte Build-Zeit lohnt sich, wenn man professionell programmiert)

Upgrade-Optionen

• 1 TB SSD, wenn du etwas extra Puffer haben willst (+200 $)

• M4 Max für 20 % schnellere CPU, 48 GB RAM, 1 TB SSD, schnellere GPU (+1.500 $)

Empfohlene Zielgruppe

Wenn Build-Performance dein Hauptkriterium ist (= professionelle Entwickler) und du kein Geld für kleine Verbesserungen verschwenden willst, nimm diesen.

Wenn du den 14”-Formfaktor für 2.200 $ bevorzugst (vergiss nicht, auf die 14-Kern-CPU aufzurüsten!), ist das ähnlich empfehlenswert, kommt aber mit einigen kleineren Nachteilen wie einer kürzeren (aber trotzdem großartigen) Akkulaufzeit und lauteren (aber trotzdem sehr leisen) Lüftern bei nur 100 $ Ersparnis. Dann nimm lieber das Basismodell des 14”, das 500 $ weniger kostet (2.000 $), aber bedenke, dass es mit einer 10 % langsameren 12-Kern-CPU kommt.

Häufig gestellte Fragen

Einige häufig gestellte Hardware-Fragen und meine persönliche Einschätzung dazu.

Apple Silicon oder Intel?

Eine realistischere Mindestberechnung ist daher:

• 40 GB für macOS

• 80 GB für 2 gleichzeitig installierte Xcode-Versionen

• 20 GB für 4 gleichzeitig installierte SDK-Versionen

• 30 GB für Build-Artefakte von 3 verschiedenen Projekten gleichzeitig

• 20 GB für andere entwicklungsbezogene Apps und Tools

• 50 GB für andere Apps (Pages, Numbers, Notion, Slack, Zoom usw.)

Das ergibt zusammen 240 GB, also reicht eine 256-GB-SSD gerade so für ernsthafte iOS-Entwicklung. Aber das funktioniert nur, wenn du ausschließlich iOS-Entwicklung auf diesem Mac machst und ihn nicht z. B. zum Synchronisieren deiner iPhone-Fotos oder -Videos nutzt. Wenn du den Mac auch für andere Zwecke verwenden willst, nimm mindestens 512 GB SSD. Das gibt dir auch den Spielraum, andere Technologien auszuprobieren, wie etwa Android Studio zu installieren, um auch mal Android-Entwicklung zu testen.

Wie viel RAM brauche ich?

Kurze Antwort: Mindestens 16 GB, besser 24 GB+.

Lange Antwort: 8 GB sind ein guter Start, wenn du schon einen Mac besitzt, und du solltest damit problemlos einen einzelnen Simulator plus Safari mit vielen Tabs nutzen können, ohne große Ruckler. Aber sobald dein Projekt größer wird und du anfängst, zwei Dinge gleichzeitig zu machen, und vielleicht sogar einen Server oder eine VM im Hintergrund laufen hast, wirst du durch den RAM limitiert.

Und falls du auf dem Gerät auch mal Android-Entwicklung betreiben willst, brauchst du definitiv die 16-GB-Option, weil (anders als iOS-Simulatoren) der Android-Emulator den RAM nicht effizient mit dem Host-System teilen kann.

Während der Unterschied von 8 GB zu 16 GB sehr spürbar ist, werden die Unterschiede von 16 GB zu 24 GB oder höher deutlich kleiner. Matt Gallagher hat dazu kürzlich einen guten Vergleich auf Twitter geschrieben, mit dem abschließenden Hinweis: „Wähle nicht RAM statt schnellerer CPU.” Dem stimme ich voll zu.

Erfreulicherweise haben seit 2024 alle neuen Macs mindestens 16 GB, du solltest also auf der sicheren Seite sein.

Was ist mit dem Mac Studio?

Kurze Antwort: Warte auf den M4-Ultra-Mac-Studio, wenn du ihn dir leisten kannst. Der ist ein Biest.

Lange Antwort: Die aktuellen Mac-Studio-Geräte sind in einer seltsamen Position – sie laufen noch mit M2-Max- und M2-Ultra-Chips. Der aktuelle M4 Pro ist ca. 33 % schneller als der M2 Max, und der M4 Max ist ca. 7 % schneller als der M4 Ultra bei Entwicklungsaufgaben. Es ist also derzeit keine gute Idee, einen Mac Studio zu kaufen. Wenn dir der Formfaktor gefällt, nimm stattdessen einfach einen M4-Pro-Mac-Mini (stelle sicher, dass du auf die 14-Kern-CPU aufrüstest!) für 1.600 $ (400 $ weniger als der M2-Max-Mac-Studio).

Der Basis-Mac-Studio für 2.000 $ hat eine 33 % langsamere 12-Kern-CPU als das oben empfohlene Best-Value-MacBook-Pro. Du kannst ihn natürlich trotzdem kaufen, um 500 $ zu sparen, wenn du den tollen Bildschirm, das Lautsprechersystem und die Mobilität des MacBooks nicht brauchst. Aber dann musst du für einen Monitor, Maus & Tastatur bezahlen, was (auf diesem professionellen Niveau) ungefähr genauso viel kosten kann – es sei denn, du hast sie schon.

Die M2-Ultra-Variante für 4.000 $ war hier früher das interessantere Gerät, weil sie doppelt so viele CPU-Kerne hatte und nochmal schnellere Build-Zeiten im Vergleich zu den Max-Chips bot. Wenn dir Geld egal ist, aber Performance nicht, kannst du gerne auf den M4 Ultra warten und ihn dir für die schnellstmöglichen Builds zulegen.

Features

Dieses erste Release ist bereits vollgepackt mit vielen Features, die dir helfen:

• Fokus: Verlasse nie den Kontext deiner Swift-Datei – programmier einfach weiter

• Schneller sein: Keine manuelle Bearbeitung von Strings-Dateien mehr beim Hinzufügen neuer Keys

• Automatisieren: Richte DeepL oder Microsoft Translator ein, um deine App zu übersetzen

• Linten: Erhalte Warnungen in Xcode bei leeren Übersetzungen oder doppelten Keys

• Normalisieren: Strings-Dateien alphabetisch sortiert, damit du Übersetzungen leichter findest

• Synchronisieren: Automatische Aktualisierung der Strings-Dateien bei Änderungen an Storyboard/XIB-Dateien

• Lernen: Viele Erklärungen, Schritt-für-Schritt-Anleitungen und sogar Videos

• Pluralisieren: Automatische Erkennung und sprachbewusste Formen für einfache Pluralisierung

Roadmap

Aber das ist erst der Anfang. Jeden Monat kommt ein neues Feature hinzu, zum Beispiel:

• Fastlane-Support: App-Store-Beschreibung und “What’s New” übersetzen

• Verifizierung: Einfache Möglichkeit, andere einzuladen, Übersetzungen zu prüfen oder beizusteuern

• Strings-Editor: Eine spezielle Oberfläche für angenehmeres Bearbeiten von Strings(dict)-Dateien

• Google Translate & Yandex: Unterstützung weiterer Übersetzungsdienste

• Open Source: Die Community unterstützen, indem Pro-Features kostenlos werden

• … und vieles mehr – [erkunde und stimme für Features ab oder schlage eigene vor](https://github.com/FlineDev/ReMafoX/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+Request%22+sort%3Areactions-%2B1-desc&ref=fline.dev)!

Vorschau

Noch nicht überzeugt? Dann schau dir die folgenden 3 GIFs an, die RemafoX in Aktion zeigen:

Füge eine neue Übersetzung zu einem Projekt in vielen Sprachen mit nur einem Schritt hinzu:

Finde leere Übersetzungen in Strings-Dateien und nutze maschinelle Übersetzung:

Richte ein Projekt in RemafoX ein und passe es an mit dokumentierten Konfigurationsoptionen:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Sonderangebot

Kaufe noch heute ein Lifetime-Abo und spare ca. 30 % mit dem Early-Bird-Rabatt, der bis Ende Oktober läuft. Monats- oder Jahresabonnements unterstützen die Weiterentwicklung dieses Projekts und kommen alle mit einer kostenlosen Testphase. So kannst du selbst sehen, wie RemafoX deinen Entwickler-Workflow verbessert.

Aber es gibt auch ein kostenloses Tier für kleinere Projekte, das alle oben genannten Features außer Pluralisierung umfasst. Ich verspreche, dass ich nie Features aus dem kostenlosen Tier entfernen werde – wenn es heute für dich funktioniert, wird es das auch immer tun! Und die meisten der geplanten Features werden auch dem kostenlosen Tier zugutekommen.

Jetzt loslegen!

Es gibt also wirklich keinen Grund, RemafoX nicht zu verwenden! Hol es dir jetzt:

‎ReMafoX: Easy App Localization

Wenn du auf Probleme stößt oder Fragen hast, schau bitte im Menü ‘Help’ nach.

Während die erste „Dub Dub” – so nennen die meisten, die mal persönlich dabei waren, das Event gerne – eigentlich eine geschlossene Veranstaltung war, bei der ein NDA unterschrieben werden musste, weil vorab ein neues Produkt gezeigt wurde, öffnete sie sich im Folgejahr und ist seitdem für alle Entwickler zugänglich. Zumindest für diejenigen, die eine Gebühr von ca. 1.600 $ zahlen, sich eine einwöchige Reise nach Kalifornien leisten konnten und das Glück hatten, bei der Lotterie zu gewinnen, da die Tickets begrenzt waren.

Aber weil solche großen Konferenzen 2020 wegen der COVID-19-Pandemie undenkbar waren, musste Apple etwas anderes machen, und seitdem wird die WWDC ihrem Namen tatsächlich gerecht und ist wirklich für alle Entwickler weltweit zugänglich – kostenlos! Das ist natürlich die positive Seite, aber eine Online-Konferenz ist eben ein anderes Erlebnis als eine Vor-Ort-Veranstaltung. Deshalb versuchen sie dieses Jahr einen gemischten Ansatz mit einem Special Event im Apple Park für einige Glückliche, aber die Konferenz selbst bleibt weiterhin weltweit offen für alle.

Angesichts dieser Veränderungen und der Möglichkeit, dass die jährliche Konferenz in diesem Online-Format bleibt, schauen wir uns die drei zentralen Aspekte der Konferenz an und wie wir das Beste daraus machen können, wenn wir die Zeit aufbringen:

• Lernen über die neuesten Apple-Technologien

• Vernetzen mit anderen Entwicklern und eine gute Zeit haben

• Diskutieren über die Auswirkungen neuer Technologien, Features und Produkte

Lernen

Apple

Welche Lernmöglichkeiten Apple offiziell während der Woche anbietet.

Keynote & Platforms State of the Union Die WWDC Keynote ist der Moment, in dem Apple der Öffentlichkeit die neuesten Software- und Produkt-Updates präsentiert. Sie richtet sich nicht speziell an Entwickler, enthält aber gegen Ende einen kurzen Entwickler-Abschnitt, und große Ankündigungen wie Swift 2014 oder SwiftUI 2019 wurden alle hier enthüllt (schau dir die verlinkten Abschnitte an und hör auf die Menge, um dich auf die diesjährige Keynote einzustimmen!).

Die Platforms State of the Union wird auch „Developer Keynote” genannt – und das aus gutem Grund. Sie enthüllt und demonstriert im Grunde alle neuen, tollen APIs, so wie die Keynote die neuen Produkte und Services vorstellt. Sie richtet sich gezielt an Entwickler, sodass mehr ins Detail gegangen werden kann, und wenn du während der gesamten WWDC nur Zeit für ein einziges Video hast, dann würde ich dieses empfehlen, weil es quasi eine Zusammenfassung der restlichen Woche ist. Es ist auch eine tolle Möglichkeit, Themen zu finden, die dich interessieren. Alle hier erwähnten Technologien haben eigene Sessions im Laufe der Woche.

Sessions Die über 200 Session-Videos bilden den Kern der WWDC und sind der beste Ort, um die neuesten Technologien im Detail kennenzulernen. Ein guter Ort zum Anschauen ist die spezielle Developer App, die kürzlich auch Unterstützung für SharePlay bekommen hat – so kannst du sogar eine Session gemeinsam mit jemandem remote schauen und direkt darüber diskutieren. Apple gruppiert die Sessions nach Themen, sodass du die Videos in der App einfach filtern kannst. Du kannst Sessions auch als Lesezeichen speichern, um sie später anzuschauen. Das mache ich direkt nach der Developer Keynote.

Falls dich die schiere Menge an Sessions überwältigt: Ein guter Einstieg ist, nach Sessions mit dem Titel „What’s new in …” oder „Meet …” Ausschau zu halten, da diese Zusammenfassungen für ein bestimmtes Thema oder Framework sind. In diesen Sessions werden dann andere Sessions erwähnt, um bei Bedarf tiefer in bestimmte Details einzutauchen.

Um das Meiste aus den Sessions herauszuholen, mache ich mir gerne Notizen, damit ich etwas Interessantes später leicht wiederfinden kann, und es hilft auch, die Aufmerksamkeit aufrechtzuerhalten. Hier sind die Notizen, die ich während der WWDC 2021 und WWDC 2020 gemacht habe. Ich empfehle dir, das auch zu tun, und wenn du es machst, überlege doch, deine Notizen zum Community-Projekt WWDC Notes beizutragen, um anderen Entwicklern in der Zukunft zu helfen.

Labs Wenn du Probleme mit einer Apple-Technologie hast, etwa bei der Integration ins System oder mit Xcode, oder wenn du einfach nicht verstehst, wie du ein Framework für einen bestimmten Anwendungsfall nutzen könntest, weil die Dokumentation fehlt, dann sind die Labs eine großartige Gelegenheit, mit einem Apple-Ingenieur zu sprechen und direktes Feedback von den Leuten zu bekommen, die diese Dinge implementiert haben und alle Details kennen. Es gibt auch ein Lab für Hilfe beim App Review und eines für Design-Feedback zu deiner App.

Du kannst in der Developer App einen Termin anfragen, wenn du mit einer Apple ID eingeloggt bist, die Teil des kostenpflichtigen Apple Developer Program ist, oder wenn du diesjähriger Student Challenge-Gewinner bist. Frage frühzeitig an und beachte:

Da die Verfügbarkeit begrenzt ist, werden Anfragen geprüft und du erhältst am Vorabend deines Labs um 22:00 Uhr PT eine E-Mail mit deinem Status.

Challenges Apple hat bei der WWDC 2021 etwas Neues ausprobiert und 25 „Challenges” angeboten; auf der offiziellen WWDC22-Seite werden „tägliche Coding- und Design-Challenges” erwähnt, es wird sie also wieder geben. Die meisten Entwickler scheinen sie letztes Jahr verpasst zu haben (und nein, ich meine nicht die Swift Student Challenge!).

Apple macht es unnötig schwer, sie zu erkunden – ich konnte online keinen guten Überblick finden, den ich verlinken könnte. Ich fand nur Links zu denen, die ein begleitendes Beispielprojekt haben, weil die Downloadseite dann zu einem News-Artikel verlinkt. Der einfachste Weg, sie alle zu finden, war für mich die Suche nach „Challenge” in der Developer App:

Ich bin mir nicht sicher, ob viele Leute an diesen Challenges teilgenommen haben – das Developer Forum hat nur 8 Threads mit dem offiziellen Tag vom letzten Jahr. Aber wenn du genug Zeit hast und eher der „Learning by Doing”-Typ bist, schau dir die diesjährigen Challenges an!

Community

Welche Lernmöglichkeiten andere aus der Community während der Woche anbieten.

WWDC Notes Dieses tolle Community-Projekt, organisiert von Federico Zanetello, ist eine großartige Ressource, um zu erfahren, was die verschiedenen Sessions beinhalten, ohne sie alle ansehen zu müssen. Zwar sind noch nicht alle Sessions abgedeckt, aber wie oben erwähnt – wenn wir alle unsere Notizen dort zusammentragen, können wir das dieses Jahr leicht ändern. Es dient auch als Archiv für WWDC-Inhalte, die bis zur WWDC 2010 zurückreichen. Apple bietet derzeit nur Videos bis zur WWDC 2014 an, aber sie entfernen jedes Jahr stillschweigend einige ältere Videos, und bei weitem nicht alle Inhalte von 2014 sind noch verfügbar.

Artikel, Podcasts und mehr Natürlich werden alle iOS-Dev-Content-Creator die Inhalte von Apple nicht nur konsumieren, sondern auch darüber schreiben, sprechen oder streamen. Ich plane sogar, die ganze Woche live zu streamen, während ich die Sessions schaue, die mich interessieren, und Notizen mache – ihr könnt gerne auf Twitch dazukommen, um neue APIs im Chat zu diskutieren!

John Sundell deckt normalerweise WWDC-Inhalte ab, sowohl in seinem Podcast als auch Blog. Paul Hudson schreibt die ganze Woche über tolle Zusammenfassungen in seinem Blog. In den letzten zwei Jahren hat er auch eine schöne Übersicht aller WWDC-bezogenen Inhalte in diesem Repository zusammengestellt – vielleicht macht er das dieses Jahr wieder? Falls nicht, schau dir diesen iOS-Dev-Feed-Aggregator von Andrew Yates an, der auf dem iOS Dev Directory von Dave Verwer basiert – ich bin sicher, viele davon werden WWDC-Inhalte während der Woche abdecken.

Dub Dub Series Ähnlich wie die oben erwähnten „Challenges” von Apple hat Jordi Bruin kürzlich eine Reihe von Coding-Challenges namens SwiftUI Series organisiert. Im Gegensatz zu Apples Challenges hatten diese Community-getriebenen Challenges 3 Juroren pro Thema, die sich das Projekt anschauten und in einem Livestream-Video Feedback gaben. Und Jordi plant, dasselbe für den 10. Juni zu organisieren, direkt nach dem Ende der WWDC, mit der Dub Dub Series. Details gibt es noch nicht, aber wenn es auch nur annähernd so wird wie die SwiftUI Series, wird es ziemlich cool – und diesmal auf die neuen APIs fokussiert.

Vernetzen

Apple

Special Event im Apple Park Wie oben erwähnt, veranstaltet Apple am ersten Tag der WWDC-Woche ein Special Event im Apple Park. Anmeldungen sind bereits geschlossen – wer es nicht geschafft hat, hat leider Pech gehabt. Aber für die wenigen Glücklichen gibt es die Möglichkeit, andere Entwickler persönlich zu treffen und die Keynotes gemeinsam zu erleben. Apple bietet viele Gelegenheiten dafür im Laufe des Tages, inklusive Frühstück, Mittagessen und sogar Führungen durch den Apple Park.

Community

WWDC22 Discord Aktive Community-Mitglieder wie Mikaela Caron haben einen „WWDC22”-Space in Discord erstellt, dem du über diesen Einladungslink beitreten kannst, um Treffen rund um die Bay Area während der WWDC-Woche zu organisieren – zum Beispiel ein Sonntagsabendessen, organisiert von Jordi Bruin. Falls du Discord nicht kennst: Es ist im Grunde wie Slack, aber mit einer stärkeren Gaming- und Audio-Call-Geschichte. Deshalb eignet sich der Discord-Space auch gut für Diskussionen! Schau doch während der WWDC mal bei Discord vorbei, um Entwickler zu treffen und neue APIs zu diskutieren! Der Discord-Space hatte zum Zeitpunkt dieses Artikels ca. 300 Mitglieder.

iOS Developers Slack Schon vor einiger Zeit hat die Community einen Slack-Space für iOS-Entwickler gestartet, um miteinander in Kontakt zu bleiben. Du kannst über diese Website beitreten. Mit über 22.000 Mitgliedern bin ich sicher, dass während der Woche viele Leute im dedizierten #wwdc-Channel sein werden, um die neuesten APIs zu diskutieren.

WWDC Community Week Diese spezielle Website versucht, die Community während der WWDC-Woche zusammenzubringen, indem sie Keynote Watch Parties und andere Events organisiert und auflistet, wie Twitter „Spaces” (live, interaktive Audio-Diskussionen) – zum Beispiel den Mega-Pre-WWDC Twitter Space vor der WWDC oder die iOS Dev Happy Hour während der Woche. Sie organisieren auch Treffen (vor Ort und online), einen Community-Hackathon und sammeln denkwürdige Momente der Community auf einem Mural. Außerdem haben sie gerade ihren eigenen Discord-Server eingeführt – du kannst hier beitreten.

✨ Möchtest du hier deine Anzeige sehen? Kontaktiere mich unter ads@fline.dev.

Diskutieren

Apple

Digital Lounges Wie letztes Jahr wird Apple auch dieses Jahr wieder Digital Lounges anbieten. Das waren im Grunde kontrollierte Slack-Channels, die nur zu bestimmten Zeiten geöffnet sind und für die man sich vorab registrieren muss – die Registrierung öffnet am 31. Mai und erfordert eine Apple Developer Membership oder den Gewinn der Student Challenge.

Forums Die Apple Developer Forums bekommen ebenfalls 4 dedizierte Tags, um neue APIs zu diskutieren und Fragen dazu zu stellen, mit der Chance, direkt von Apple-Ingenieuren eine Antwort zu bekommen. Ich bevorzuge zwar die Forum-Technologie, die Apple in den Swift Forums verwendet, gegenüber dieser eigenen Implementierung, aber manche der kniffligeren Fragen werden nur hier beantwortet, also kann es manchmal ein Lebensretter sein!

Community

Natürlich kannst du neue APIs auch in einem der oben unter „Vernetzen” erwähnten Discord-Server oder dem Slack-Server diskutieren. Hier sind noch weitere Optionen:

Dub Dub Together Diese Website, erstellt von Khoa, ist ein Ort, an dem du beide Keynotes anschauen und live mit anderen Entwicklern darüber chatten kannst – alles auf einem Bildschirm. Theoretisch könntest du die erste Keynote auch auf YouTube schauen und dort chatten, aber für die Developer Keynote geht das nicht, und im YouTube-Chat schreiben auch viele Nicht-Entwickler mit. Also durchaus eine Überlegung wert!

Livestreams Einige bekannte Entwickler-Seiten wie RayWenderlich werden das Event live streamen und die APIs besprechen, während sie vorgestellt werden. Ich habe schon erwähnt, dass ich auch streamen werde, und du findest vielleicht auch andere Twitch-Streamer, die dasselbe machen. Ich habe sogar einige kontaktiert, um gemeinsam in unseren Streams über APIs zu diskutieren. Bitte beachte, dass Apple es nicht erlaubt, die Keynote oder Sessions weiterzuverbreiten – du musst also die Inhalte von Apple auf einem zweiten Gerät öffnen, nur als Hinweis.

Ich hoffe, dass dir all diese Informationen helfen, eine tolle WWDC 2022 zu erleben. Hoffen wir, dass alle unsere Wünsche in Erfüllung gehen!

💁🏻‍♂️ Hat dir dieser Artikel gefallen? Schau dir meine App RemafoX an! Eine native Mac-App, die sich in Xcode integriert und dir hilft, deine App zu übersetzen. Jetzt herunterladen, um Zeit bei der Entwicklung zu sparen und die Lokalisierung einfach zu machen.

**Software: **Broadcasting-Software, Tastenkuerzel-Tool **Drittanbieter-Dienste: **Community-Aufbau, Audio-Routing, Hintergrundmusik

Software-Setup

Schau dir den ersten Teil dieser Serie an, um zu erfahren, welche Hardware ich verwende. Hier geht es jetzt um die Software-Seite – die wichtigsten Streaming-relevanten Apps inklusive Preis, meinen Einstellungen und einigen Alternativen.

Broadcasting-Software: SE.Live (OBS mit Plugins)

Beschreibung: Das Herzstueck jedes Streams ist die Broadcasting-Software. Sie erzeugt das Live-Video und sendet es als Kombination vieler verschiedener Quellen an Twitch (oder andere Plattformen wie YouTube). Ich nutze sie, um meinen Bildschirm und meine Webcam aufzunehmen, einen Green-Screen-Filter anzuwenden, mein Mikrofon-Audio aufzuzeichnen, Filter auf das Audio anzuwenden, Hintergrundmusik abzuspielen, Stream-bezogene Alerts wie Follows anzuzeigen, Sound-Alerts bereitzustellen und zwischen verschiedenen Szenen zu wechseln – etwa wenn ich den Stream starte, beende oder eine Pause mache.

Das ist ziemlich viel fuer eine einzelne Software, daher ist es wirklich wichtig, hier das richtige Tool zu waehlen. Die gute Nachricht: Es gibt ein Open-Source-Projekt dafuer namens „Open Broadcaster Software”, kurz „OBS”, mit 37k Sternen auf GitHub und vielen Features, auf denen andere Unternehmen aufbauen koennen. Ich nutze die StreamElements-Variante, weil sie dem originalen OBS Studio sehr aehnlich ist, aber zusaetzliche Plugins fuer den Community-Aufbau mitbringt.

Preis: Kostenlos (die OBS-Basis ist vollstaendig Open Source, die Plugins nicht)

Meine Einstellungen: Ich habe im Grunde zwei Arten von Szenen eingerichtet: Wenn ich nicht sichtbar bin und wenn ich es bin. Fuer Ersteres habe ich ein schoenes Hintergrund-Video von Pixabay heruntergeladen und eine abgedunkelte Ebene darueber gelegt, damit der Bildschirm lebendig wirkt, auch wenn ich nicht da bin. Ich habe 3 Szenen erstellt (vorher/Pause/nachher) mit im Grunde dem gleichen Aufbau, aber unterschiedlichem Text:

Fuer die Zeiten, in denen ich streame, habe ich ebenfalls 3 Szenen: Eine mit einem Pomodoro-Timer (aktuell nutze ich die Flow-App, werde aber meinen eigenen Open Focus Timer verwenden, sobald er fertig ist), eine ohne Timer (z. B. am Ende des Streams) und eine mit zensiertem Bildschirm (z. B. wenn ich mich irgendwo einloggen muss). Nach vielen Versuchen habe ich mich entschieden, mich unten rechts im Bild zu platzieren (aber nicht ganz am Rand):

Fuer meine Webcam habe ich einen „Chroma Key”-Filter fuer den Green Screen eingerichtet:

Meine Audio-Einstellungen sind etwas fortgeschrittener. Zunaechst meine Mikrofon-Einstellungen. Ich verwende 4 Filter fuer mein Mikrofon, die alle von Audio-Profis empfohlen werden:

„Noise Suppression” hilft, Hintergrundgeraeusche wie laute Luefter herauszufiltern.

Mit dem „Noise Gate” kann ich das Mikrofon komplett „ausschalten”, wenn ein bestimmter Lautstaerke-Schwellenwert nicht erreicht wird. Das hilft, Tastaturtippen zu entfernen, wenn ich nicht spreche.

Manchmal koennen Leute sehr laut werden, wenn sie von etwas ueberrascht werden. Stell dir vor, ich besuche eine Website und es gibt einen Jump Scare. Um meine Zuschauer nicht mit einem ploetzlichen lauten Geraeusch von mir zu belaestigen, habe ich einen „Compressor” eingerichtet, der jede Lautstaerke ueber einem bestimmten Schwellenwert um den Faktor 10 „komprimiert”.

Schliesslich macht der „Limiter” etwas sehr Aehnliches wie ein Compressor – anstatt das ueberschuessige Audio mit einem anpassbaren Faktor zu „komprimieren”, verwendet er einfach immer den Faktor „unendlich” und begrenzt die Lautstaerke damit auf ein vorgegebenes Maximum.

Weiter zu anderen Audio-Einstellungen. Zwei Dinge sollten hier erwaehnt werden: Erstens gibt es ein Konzept namens „Monitor”. Ein Monitor ist das Audio, das du als Streamer zurueckhoerst. Wenn du beispielsweise den „Monitor” fuer dein Mikrofon einschaltest, hoerst du dich selbst ueber deine Kopfhoerer. Ich habe ihn fuer alles ausser dem Mikrofon aktiviert, weil es sich seltsam anfuehlt, sich selbst (mit etwas Verzoegerung) zu hoeren. Zweitens kannst du fuer jede Audioquelle eine Audiospur-Nummer festlegen. Das ist nuetzlich, wenn du deine Videos spaeter bearbeiten moechtest, z. B. um fokussiertere YouTube-Videos zu produzieren (was ich vorhabe). Ich lege zum Beispiel meine Stimme auf eine eigene Spur, die Hintergrundmusik auf eine andere und alle Sound-Alerts auf wieder eine andere Spur. So kann ich die Videoquelle schneiden und Teile meiner Stimme behalten, ohne dass die Hintergrundmusik „springt”. Und ich kann Alert-Sounds komplett entfernen oder ihre Lautstaerke unabhaengig aendern, wenn noetig. Hier siehst du das:

Zusaetzlich habe ich eingestellt, dass alle meine Streams automatisch als .mkv-Datei mit allen Audiospuren von 1 bis 5 aufgezeichnet werden. Hier siehst du das:

Das war eine Auswahl meiner OBS-Einstellungen, aber nicht alle. Mit OBS kann man so viel machen, dass es einschuechtend wirken kann. Zum Beispiel habe ich Browser-Quellen uebersprungen.

Alternativen: – Streamlabs Desktop: Kostenlos (Open Source), eigene OBS-Oberflaeche (Geschmackssache) – Ecamm Live: 400 $ pro Jahr, native Mac-App, einfach, aber eingeschraenkte Flexibilitaet

Tastenkuerzel-Tool: KeyCastr

Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Drittanbieter-Dienste

Das sind die Drittanbieter-Dienste, die ich nutze und die jeder Streamer in Betracht ziehen sollte.

Community-Aufbau: StreamElements

Beschreibung: Was Streaming richtig spassig macht, ist die Interaktion mit deinen Zuschauern. Waehrend Twitch als Streaming-Plattform einen integrierten Chat bietet, gibt es noch viel mehr Moeglichkeiten, mit deiner Community zu interagieren. Du moechtest vielleicht in deinem Stream einen Alert anzeigen, wenn dir jemand folgt, damit sich die Zuschauer wirklich als Teil des Streams fuehlen. Oder du moechtest mit einer Bildschirm-Animation feiern, wenn ein anderer Streamer dich raidet. Und du hast wahrscheinlich einige Erinnerungen wie Links zu deinen Social-Media-Profilen, die du mit deinen staendig wechselnden Zuschauern teilen moechtest. Diese und weitere Features werden von Drittanbieter-Diensten bereitgestellt, und ich empfehle dir dringend, mindestens einen davon zu nutzen, um mit deinen Zuschauern verbunden zu bleiben und ueber die Zeit eine Fan-Community aufzubauen.

Preis: Kostenlos (sie nehmen einen Anteil, wenn du ihren Merch Store oder Partnerschaften nutzt)

Meine Einstellungen: StreamElements bietet viele Features, aber ich nutze hauptsaechlich 2 davon:

Erstens nutze ich ihre Alerts- und Overlays-Funktion mit einem benutzerdefinierten Overlay. Die zwei wichtigsten Ebenen, die ich eingerichtet habe, sind die Alert Box und Kappagen:

Beschreibung: Apple sichert macOS auf vielen Ebenen ab. Eine davon ist der Schutz von System-Audio: Standardmaessig gibt es keine Moeglichkeit, die Audio-Ausgabe anderer Apps in OBS zu leiten, damit deine Zuschauer dasselbe hoeren wie du. Das kann nuetzlich sein, z. B. wenn du Hintergrundmusik in einer separaten Musik-App abspielen oder ein Tutorial-Video anschauen und live kommentieren moechtest. Es gibt zwar eine Moeglichkeit, einige Sicherheitsfunktionen zu deaktivieren und Apps Zugriff auf System-Audio zu geben, aber OBS unterstuetzt das (noch) nicht. Du brauchst also zusaetzliche Software, die Audio von anderen Apps oder deinem System in ein virtuelles „Fake-Mikrofon” leitet, das du dann in OBS als Quelle wie jedes andere Mikrofon hinzufuegen kannst. Eine schoene detaillierte Slideshow zur Einrichtung des Tools auf Intel- und M-Chip-Macs findest du hier.

Preis: 99 $ (Einmalzahlung)

Meine Einstellungen: Die wichtigste Einstellung hier ist das „Video Content”-Geraet, weil es mir das Audio von Videos liefert, die ich mit QuickTime oder Safari abspielen koennte.

Alternativen: – Blackhole: Kostenlos (Open Source) – habe es nicht ausprobiert, sieht aber sehr aehnlich aus

Hintergrundmusik: Pretzel

Beschreibung: Eine Coding-Session ohne entspannende Hintergrundmusik ist fuer mich sehr ermuedend. Ich finde, es ist sogar noch wichtiger, gute Hintergrundmusik zu haben, wenn man live streamt, da man wahrscheinlich nicht die ganze Zeit redet und die Pausen als Zuschauer seltsam wirken koennen, wenn es gar kein Geraeusch gibt. Gleichzeitig ist die Lizenzierung von Musik ein kompliziertes Thema, und du darfst nicht alles auf Twitch streamen. In meinem Fall lade ich meine Streams auch auf YouTube hoch, und die Regeln unterscheiden sich zwischen den Plattformen. Generell ist auf Twitch mehr erlaubt, und noch mehr ist erlaubt, wenn du die „Video-on-Demand”-Funktion auf Twitch deaktivierst, sodass Zuschauer die Musik nur live hoeren koennen und es keine Moeglichkeit gibt, sie spaeter anzuschauen.

Wenn du aber Aufzeichnungen deiner Streams langfristig bereitstellen moechtest, musst du „lizenzfreie” Musik finden oder zumindest eine Lizenz fuer die Musik haben, die du nutzt – sonst riskierst du einen DMCA-Takedown von (Teilen) deiner Videos. Wenn du das auf YouTube oder Twitch wiederholt tust, kann dein Kanal sogar gesperrt werden. Geh kein Risiko ein und stelle sicher, dass du dich an die Regeln haeltst.

Preis: Freemium (15 $/Monat, um den Chatbot zu entfernen, der jeden Song postet)

Meine Einstellungen: Ich habe immer „YouTube Safe” aktiviert. Frueher hatte ich „Instrumental” aktiviert und habe die Sender „LoFi” und „Chill” viel gehoert. Aber in letzter Zeit habe ich angefangen, auch den „Rock”-Sender zu hoeren, und mit diesem Filter gab es keine Songs, also lasse ich den „Instrumental”-Filter jetzt deaktiviert.

Meine bevorzugten Pretzel-Einstellungen.

LoFi, Chill und Rock gehoeren zu meinen Lieblingssendern.

Alternativen: – Monstercat Gold: 7,50 $/Monat, unterstuetzt Musik-Download – Playlists auf Apple Music / Spotify / Amazon Music, z. B. von Anjunabeats – Hier ist eine Liste weiterer Alternativen

Was kommt als Naechstes

Das war’s mit der Software, die ich nutze, und wie ich sie konfiguriert habe – das sollte dich einen weiteren Schritt naeher an deine eigenen Livestreams bringen. In Teil 3 dieser Serie werde ich meine Systemeinstellungen und einige weitere Tipps behandeln, die du beim Streamen von Softwareentwicklung auf Twitch beachten solltest. Folge mir, um nichts zu verpassen!

Dir hat dieser Artikel gefallen? Schau dir meine App RemafoX an! Eine native Mac-App, die sich in Xcode integriert und dir hilft, deine App zu uebersetzen. Jetzt herunterladen, um bei der Entwicklung Zeit zu sparen und Lokalisierung einfach zu machen.

✨ 2023 Update: Ich habe 3 weitere Wünsche in diesem Nachfolgeartikel ergänzt.

Jedes Jahr gibt es diese ganz besondere Zeit, in der eine bestimmte Gruppe von Menschen Wünsche äußert und sich Hoffnungen auf alles Mögliche macht. Manche teilen ihre Wünsche mit anderen, manche behalten sie lieber für sich, um nicht zu enttäuscht zu werden, wenn sie nicht in Erfüllung gehen. Ich gehörte bisher zur letzteren Gruppe, aber diesmal möchte ich meine Wünsche teilen, um die Wahrscheinlichkeit zu erhöhen, dass sie wahr werden – wenn nicht dieses Jahr, dann vielleicht nächstes. Schließlich hört der Weihnachtsmann vielleicht zu.

Ich werde die offensichtlichen Themen überspringen, die auf so gut wie jeder iOS-Entwickler-Liste ganz oben stehen, wie ein stabileres Xcode, ein fehlerfreieres Swift, ein vollständigeres SwiftUI oder zuverlässigere SwiftUI Previews. Los geht’s!

#3: App-Icons in allen Größen aus einem einzigen Bild importieren

Problem

Jede App braucht ein App-Icon. Xcode verlangt von uns, das App-Icon in Dutzenden verschiedener Größen bereitzustellen, ohne dabei Unterstützung beim Skalieren zu bieten. Es gibt zwar viele Apps und Tools, die dabei helfen, aber nur wenige davon unterstützen die neuesten Größen, da Apple gerne neue dazufügt. Das ist ein unnötiges Hindernis für neue Entwickler, die gerade erst anfangen.

Aber sie werden im Swift-Code sowieso alle als Optional-Typen generiert. Das und das gesamte NSManagedObjectContext-API-Design fühlt sich ziemlich veraltet und nicht besonders „Swifty” an (also „nicht sicher”). Es wird Zeit für etwas Neues!

Lösung

Apple könnte ein neues, reines Swift-Framework einführen (wie SwiftUI), das vielleicht SwiftData heißt und eine High-Level-API zum Definieren und Verwalten persistierbarer Modelle bietet. Ein Modell zu definieren könnte dann so aussehen:

import SwiftData

actor Category: PersistableObject {
  @Persisted
  var colorHexCode: String

  @Persisted
  var iconSymbolName: String

  @Persisted
  var name: String

  @PersistedRelation(inverse: \CategoryGroup.categories)
  var group: CategoryGroup
}

Für Modelle, die in iCloud gespeichert werden sollen, müsste man distributed vor actor setzen. Normalerweise würde der Zugriff auf eine Property eines actor das Schlüsselwort await erfordern, aber spezielle Property Wrapper könnten das vereinfachen zu:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    Label(
      self.category.name,
      systemImage: self.category.iconSymbolName
    )
    .foregroundColor(
      Color(hex: self.category.colorHexCode)
    )
  }
}

Und das Schreiben auf eine actor-Property ist von außen nicht möglich, aber der @Persisted-Property-Wrapper könnte etwas Binding-Magie mitbringen, um das zu ermöglichen:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    TextField("Name", self.category.$name.bind())
  }
}

Ich muss zugeben, ich habe Actors in der Praxis noch nicht verwendet, also verzeiht mir, wenn einige der obigen Beispiele keinen Sinn ergeben. Aber ich habe das Gefühl, dass Actors eine wichtige Rolle in einem SwiftData-Framework für sicheren Zugriff spielen könnten.

Zusätzlich könnte Xcode eine Oberfläche mitbringen, die es einfach macht, Datenmodelle zu versionieren, und ein grafisches Migrationstool bieten, das in deklarativer Swift-Syntax geschrieben und als UML-Diagramm auf der rechten Seite angezeigt werden könnte (wie SwiftUI Previews). Aber vielleicht habe ich hier angefangen, zu groß zu träumen …

Wahrscheinlichkeit

Viele haben das schon in den letzten zwei Jahren erwartet, weil es der logische nächste Schritt nach SwiftUI ist. Aber dieses Jahr, mit Actors, die bereits in Swift 5.5 ausgeliefert wurden, und Distributed Actors (für iCloud-Unterstützung), die erst kürzlich akzeptiert wurden, könnte die Technologie gerade bereit sein, die erste Version bis September auszuliefern.

Fazit

Es gibt vieles, das Apple im Juni ankündigen könnte, und die obigen Punkte sind nur meine persönlichen Wünsche. Aber 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!

Motivation: Teilen mit der Community / Etwas zurueckgeben, Zeiteffizienz Hardware-Setup: Mac, Headset, Webcam, Green Screen, Mikrofon, Licht

Motivation

**Preis: **~2.700 $

Vorteile: – M1 Pro baut 40 % schneller als M1, nur 2 % langsamer als M1 Max (Quelle) – Doppelte Akkulaufzeit im Vergleich zu Intel-MacBooks (auch ~25 % laenger als M1 Max) – 1 TB bietet reichlich Platz fuer mehrere Xcodes, iOS-Simulatoren und 1080p-Streams

Nachteile: – Mehr als doppelt so teuer wie ein M1 Mac Mini mit 16 GB + 1 TB – die 40 % kuerzere Build-Zeit kombiniert mit dem tollen Display und der Mobilitaet ist es aber wert – Kein Spielraum mit nur 16 GB RAM (die 32-GB-Option kostet 400 $ extra!)

Empfohlen? Oh ja. Der M1 Ultra baut allerdings nochmal 37 % schneller – ueberleg dir das mal!

Alternativen: – M1 Mac mini mit 16 GB RAM + 1 TB (~1.300 $) – M1 MacBook Air mit 16 GB RAM + 1 TB (~1.650 $) – M1 Ultra Mac Studio mit 64 GB RAM + 1 TB (~4.000 $)

Headset: AirPods Max

Preis: ~300 EUR (~335 $) – Hinweis: Ich habe sie gebraucht gekauft.

Vorteile: – Einfache Verbindung mit Apple-Geraeten – Sehr lange Akkulaufzeit (ich muss kaum laden) – Bequem auch nach stundenlangem Streamen

Nachteile: – Teuer im Neukauf (~550 $) – Der Kabelmodus erfordert ein zusaetzliches Lightning-auf-3,5-mm-Kabel (~35 $)

Empfohlen? Wenn du weitere Apple-Geraete besitzt: Ja. Sonst: Nein.

Alternativen: – Logitech Pro X (~90 $), gutes abnehmbares Mikrofon – HyperX Cloud II (~70 $), ebenfalls sehr beliebt bei Gamern – Jeder Kopfhoerer, den du bereits besitzt (wenn du dir sowieso ein externes Mikrofon holst)

Webcam: Logitech C920S Pro

**Preis: **~70 $

Vorteile: – Zuverlaessig (ich sehe in Streams oefter, dass Kameras sich zufaellig abschalten – bei mir ist das nie passiert) – Gute 1080p-Qualitaet und natuerliche Farben – Sichtschutzblende (immerhin hat uns Edward Snowden erzaehlt, dass die NSA zuschaut) – Autofokus und automatische Beleuchtungsanpassung, konfigurierbar ueber die Logitech-Software

Nachteile: – Eingebautes Mikrofon, das sich nicht physisch ausschalten laesst (NSA, du erinnerst dich?)

Empfohlen? Ja!

Green Screen: Elgato Collapsible Chroma Key Panel

Preis: ~120 $

Vorteile: – Einfach und schnell aufzubauen und wieder wegzuraeumen – Stabiler Staender – Gute Hoehe

Nachteile: – Koennte noch etwas breiter sein (ich muss die Seiten meines Webcam-Bildes abschneiden)

Empfohlen? Ja, wirklich praktisch, wenn du einen Green Screen brauchst.

Alternativen: – Richte dir einen huebschen Hintergrund fuer deinen Arbeitsplatz ein, wenn du den Platz dafuer hast

Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Mikrofon: Blue Yeti

Preis: ~100 $

Vorteile: – Flexible Modi, die auch Interviews und mehr ermoeglichen – Toller Klang direkt aus der Verpackung, ganz ohne Filter – Logitech-Software liefert mehrere Filter-Presets mit

Nachteile: – Standard-Staender nicht gut genug gegen Vibrationen (Tastatur) geschuetzt – Der Mute-Button erzeugt beim Klicken ein zu lautes Geraeusch, um ihn waehrend des Streams zu nutzen

Empfohlen? Ja, dieses Mikrofon wird tatsaechlich von vielen fuer den Einstieg empfohlen.

Alternativen: – HyperX Quadcast, praktischer Tap-to-Mute-Sensor (~110 $) – Rode NT-USB, wird mit Popschutz geliefert (~170 $) – Wenn du ein Headset mit gutem Mikrofon hast, nimm das (z. B. Logitech Pro X)

Licht: LAVKOW 10 Inches RGB Selfie Ring Light (US-Alternative.)

Preis: ~30 $

Vorteile: – Guenstig – Unterstuetzt verschiedene Farben

Nachteile: – Nicht besonders hell, aber ausreichend fuers Streamen, wenn man nah dran sitzt

Empfohlen? Um Geld zu sparen: Ja, ein Selfie-Licht tut’s. Fuer Qualitaet: Nein.

Alternativen: – Elgato Key Light (~200 $)

Schau dir auch Twitchs Hardware-Empfehlungen an fuer weitere Alternativen.

Weiteres Zubehoer, das ich nutze

Nicht direkt mit Streaming verbunden, aber falls du dich dafuer interessierst, was ich sonst noch auf meinem Schreibtisch stehen habe – hier eine kurze kommentierte Liste:

• Apple Wireless Magic Keyboard 2 (65 $): Mittlerweile wuerde ich das Logitech ERGO K860 bevorzugen.

• Logitech MX Vertical (80 $): Ein Retter fuer mein Handgelenk – moechte nicht mehr zurueck.

• Inateck HB2021 5-in-1 Adapter (35 $): Nur ein Kabel anschliessen, wie eine Dockingstation.

• Boyata Laptop Stand (30 $): Schoene Verarbeitung, sehr stabil und rutschfest.

• Lamicall Phone Stand S1 (10 $): Gut genug, Oeffnung fuers Kabel. Erfuellt seinen Zweck.

• MAXLVL Gaming Mauspad XL (15 $): Die Groesse von 90 cm x 40 cm ist perfekt fuer mich.

Das war’s zu meiner Motivation und meinem Hardware-Setup. Ich hoffe, das hilft zukuenftigen Streamern beim Einstieg. Der naechste Teil behandelt die Software-Seite, die meiner Meinung nach noch interessanter ist: Alle Tools, die ich nutze, und wie ich sie zusammen mit meiner Hardware eingerichtet habe. Folge mir, um nichts zu verpassen!

Dir hat dieser Artikel gefallen? Schau dir meine App RemafoX an! Eine native Mac-App, die sich in Xcode integriert und dir hilft, deine App zu uebersetzen. Jetzt herunterladen, um bei der Entwicklung Zeit zu sparen und Lokalisierung einfach zu machen.

Also habe ich in einem meiner Streams (das ist eine Open-Source-App, die ich komplett öffentlich entwickle und dabei live auf Twitch streame) beschlossen, dieses Problem ein für alle Mal zu lösen. Und bin gescheitert:

Just failed at fixing a #SwiftUI preview error during my #livestream. Could fix one issue, but then got stuck at "MessageError: Connection interrupted". Any ideas? The project is open source:https://t.co/ppevrcRMtK

I started getting this error here:https://t.co/AQz2l7vnTv pic.twitter.com/aTYQy5gzHi

— Cihat Gündüz (@Jeehut) March 2, 2022

Dank der Hilfe der großartigen Swift-Community auf Twitter konnte ich die Ursache des Problems herausfinden: SwiftUI Previews bekommen Probleme, wenn CoreData-Modelle in ihnen referenziert werden.

Aber während ich dachte, es sei nur ein Pfadproblem, das sich mit einem einfachen Workaround beheben ließe, war es doch nicht so einfach. Ja, es gibt ein Pfadproblem, aber beim Lösen der Previews bin ich auf mehrere Fehlerebenen gestoßen. Und ich habe dabei gelernt, wie man SwiftUI Previews debuggt. Lass mich meine Erkenntnisse teilen …

#1: Explizite Dependencies im Package-Manifest

Das Wichtigste zuerst. Point-Frees Modularisierungsansatz zu verwenden bedeutet, dass du eine Package.swift-Datei manuell pflegen musst. Für jedes Modul fügst du einen target-, einen testTarget- und einen library-Eintrag hinzu und für jedes Target musst du die Dependencies angeben. Xcode hilft hier in keiner Weise, außer dass es die Änderungen erkennt, die du in dieser Datei vornimmst. Bei vielen Packages kann die Manifestdatei erheblich wachsen, und es gibt derzeit keine Hilfe, die mir bekannt wäre, um das einfacher zu machen. So sieht mein Manifest aktuell aus:

// swift-tools-version:5.5
import PackageDescription

let package = Package(
  name: "OpenFocusTimer",
  defaultLocalization: "en",
  platforms: [.macOS(.v12), .iOS(.v15)],
  products: [
    .library(name: "AppEntryPoint", targets: ["AppEntryPoint"]),
    .library(name: "Model", targets: ["Model"]),
    .library(name: "TimerFeature", targets: ["TimerFeature"]),
    .library(name: "ReflectionFeature", targets: ["ReflectionFeature"]),
    .library(name: "Resources", targets: ["Resources"]),
  ],
  dependencies: [
    // Commonly used data structures for Swift
    .package(url: "https://github.com/apple/swift-collections", from: "1.0.2"),

    // Handy Swift features that didn't make it into the Swift standard library.
    .package(url: "https://github.com/Flinesoft/HandySwift", from: "3.4.0"),

    // Handy SwiftUI features that didn't make it into the SwiftUI (yet).
    .package(url: "https://github.com/Flinesoft/HandySwiftUI", .branch("main")),

    // ⏰ A few schedulers that make working with Combine more testable and more versatile.
    .package(url: "https://github.com/pointfreeco/combine-schedulers", from: "0.5.3"),

    // A library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind.
    .package(url: "https://github.com/pointfreeco/swift-composable-architecture", from: "0.33.1"),

    // Safely access Apple's SF Symbols using static typing Topics
    .package(url: "https://github.com/SFSafeSymbols/SFSafeSymbols", from: "2.1.3"),
  ],
  targets: [
    .target(
      name: "AppEntryPoint",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "HandySwiftUI", package: "HandySwiftUI"),
        "Model",
        "ReflectionFeature",
        "TimerFeature",
        "Utility",
      ]
    ),
    .target(
      name: "Model",
      dependencies: [
        .product(name: "OrderedCollections", package: "swift-collections"),
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
      ],
      resources: [
        .process("Model.xcdatamodeld")
      ]
    ),
    .target(
      name: "TimerFeature",
      dependencies: [
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        "Model",
        "ReflectionFeature",
        "Resources",
        .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
        "Utility",
      ]
    ),
    .target(
      name: "ReflectionFeature",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        .product(name: "HandySwift", package: "HandySwift"),
        "Model",
        "Resources",
        "Utility",
      ]
    ),
    .target(
      name: "Resources",
      resources: [
        .process("Localizable")
      ]
    ),
    .target(
      name: "Utility",
      dependencies: [
        .product(name: "CombineSchedulers", package: "combine-schedulers"),
        "Model",
      ]
    ),
    .testTarget(
      name: "ModelTests",
      dependencies: ["Model"]
    ),
    .testTarget(
      name: "TimerFeatureTests",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        "TimerFeature",
      ]
    ),
  ]
)

Das Problem bei der manuellen Pflege dieser Datei ist nicht nur die manuelle Arbeit. Xcode verhält sich anscheinend inkonsistent bezüglich der Dependencies: Wenn du zum Beispiel einen normalen Build für den Simulator machst, scheint eine Dependency einer Dependency automatisch zu deinem Target gelinkt zu werden. Wenn also mein TimerFeature zum Beispiel Utility importiert, es aber nicht als Dependency unter dem TimerFeature-Target aufgelistet ist, kann Xcode trotzdem ohne Fehler kompilieren, wenn eine andere Dependency, z.B. Model, ebenfalls von Utility abhängt – so kann Xcode indirekt auf Utility innerhalb von TimerFeature zugreifen, weil TimerFeature Model als Dependency gelistet hat.

Obwohl das sehr nützlich klingt, kann es ziemlich frustrierend werden, weil SwiftUI Previews anders funktionieren. Für sie funktioniert diese transitive Art von impliziten Imports – soweit ich das beurteilen kann – nicht. Das Gleiche scheint auch für das Ausführen von Tests zu gelten (zumindest manchmal). Anders gesagt: Es ist wichtig, die dependencies für jedes Target immer doppelt zu prüfen und nicht zu vergessen, jeden import, den du in einem Target verwendest, auch zum entsprechenden Target in deiner Package.swift-Manifestdatei hinzuzufügen.

Vielleicht schreibt ja jemand in Zukunft ein Tool, das das einfacher macht. 🤞

#2: Generierter Code wird von Xcode nicht zuverlässig erkannt

Ein weiteres Problem, auf das ich gestoßen bin: Selbst wenn meine Builds erfolgreich waren, zeigte Xcode (nachdem es mir den “Build succeeded”-Dialog gezeigt hatte) einen Fehler im Editor innerhalb des PreviewProvider an, der besagte, dass FocusTimer nicht gefunden werden könne:

Beachte, dass du diese generierten Dateien jedes Mal löschen und neu erstellen musst, wenn du eine Änderung am Modell vornimmst (was du ohnehin selten machen solltest, um Datenbank-Migrationsprobleme zu vermeiden). Wähle außerdem das Modell in Xcode aus und setze Codegen auf Manual/None.

Damit zeigt der Editor keinen Fehler mehr an.

#3: SwiftUI Diagnostics != SwiftUI Crash Reports

Hier ein Tipp für alle (wie mich), die sich fragen, wie man mit Fehlern wie diesem umgeht, wenn man nach dem Fehlschlagen der SwiftUI Previews auf den Diagnostics-Button drückt:

Wenn du den Inhalt des hervorgehobenen Ordners anschaust, findest du viele Dateien mit verschiedenen Details über den SwiftUI-Preview-Build. Die nützlichste Datei zum Debuggen liegt im Ordner CrashLogs, wo du eine oder mehrere .ips-Dateien findest, die wir einfach per Doppelklick in Xcode öffnen können:

Zum Glück half hier der bereits erwähnte Hinweis eines hilfsbereiten Entwicklers aus der Swift-Community auf Twitter, der mich auf einen Thread mit dieser Antwort auf StackOverflow verwies.

Es besagt im Wesentlichen, dass es derzeit einen Bug in Xcode (oder SwiftPM?) gibt, der dazu führt, dass Bundle.module in SwiftUI Previews auf den falschen Pfad zeigt. Zur Lösung schlagen sie vor, eine Bundle-Extension mit einer benutzerdefinierten Suche hinzuzufügen. Hier der vollständige Code, leicht angepasst an meinen Coding- und Kommentarstil:

import Foundation

extension Foundation.Bundle {
  /// Workaround for making `Bundle.module` work in SwiftUI previews. See: https://stackoverflow.com/a/65789298
  ///
  /// - Returns: The bundle of the target with a path that works in SwiftUI previews, too.
  static var swiftUIPreviewsCompatibleModule: Bundle {
    #if DEBUG
      // adjust these for each module
      let packageName = "OpenFocusTimer"
      let targetName = "Model"

      final class ModuleToken {}

      let candidateUrls: [URL?] = [
        // Bundle should be present here when the package is linked into an App.
        Bundle.main.resourceURL,

        // Bundle should be present here when the package is linked into a framework.
        Bundle(for: ModuleToken.self).resourceURL,

        // For command-line tools.
        Bundle.main.bundleURL,

        // Bundle should be present here when running previews from a different package (this is the path to "…/Debug-iphonesimulator/").
        Bundle(for: ModuleToken.self).resourceURL?.deletingLastPathComponent().deletingLastPathComponent()
          .deletingLastPathComponent(),
        Bundle(for: ModuleToken.self).resourceURL?.deletingLastPathComponent().deletingLastPathComponent(),
      ]

      // The name of your local package, prepended by "LocalPackages_" for iOS and "PackageName_" for macOS.
      let bundleNameCandidates = ["\(packageName)_\(targetName)", "LocalPackages_\(targetName)"]

      for bundleNameCandidate in bundleNameCandidates {
        for candidateUrl in candidateUrls where candidateUrl != nil {
          let bundlePath: URL = candidateUrl!.appendingPathComponent(bundleNameCandidate)
            .appendingPathExtension("bundle")
          if let bundle = Bundle(url: bundlePath) { return bundle }
        }
      }

      return Bundle.module
    #else
      return Bundle.module
    #endif
  }
}

Wenn du diesen Code kopierst und einfügst, stelle sicher, dass du die Variablen packageName und targetName an dein Package und deine Target-Namen anpasst.

Beachte, dass ich den Workaround in ein #if DEBUG eingewickelt habe, um sicherzustellen, dass mein Produktionscode nicht versehentlich diese Pfadsuche verwendet, sondern sich auf das offizielle Bundle.module verlässt. Außerdem habe ich den fatalError aus dem StackOverflow-Workaround-Code entfernt, sodass er, falls er kein Bundle in den benutzerdefinierten Suchpfaden findet, nicht abstürzt, sondern stattdessen Bundle.module als Fallback zurückgibt. Das soll den Code robuster machen und auch dann weiterhin funktionieren, wenn dieser Bug in einem zukünftigen Xcode-Release behoben wird, die benutzerdefinierten Suchpfade aber möglicherweise nicht mehr funktionieren.

Nun war die letzte Änderung, die ich im PersistenceController vornehmen musste, den Aufruf von Bundle.module durch einen Aufruf des neuen Bundle.swiftUIPreviewsCompatibleModule zu ersetzen:

let modelUrl = Bundle.swiftUIPreviewsCompatibleModule.url(forResource: "Model", withExtension: "momd")!
let managedObjectModel = NSManagedObjectModel(contentsOf: modelUrl)!
container = NSPersistentContainer(name: "Model", managedObjectModel: managedObjectModel)

Und endlich funktionierten meine SwiftUI Previews wieder!

Waere das der Fall, koennte SwiftUI sogar fuer Prototyping genutzt werden, bei dem eine “funktionierende, aber nicht huebsche” Version einer App-Idee schnell gebaut und Nutzern gezeigt werden koennte, um zu pruefen, ob die App-Idee Erfolgschancen hat. Ausserdem koennte man so auch schnell Feedback sammeln, welche Teile ein deutlich verstaendlicheres UI brauchen (die noch nicht gut verstandenen Teile) und welche groesstenteils bei den Standard-Komponenten mit einigen visuellen Anpassungen bleiben koennten.

Mit anderen Worten: SwiftUI hat meiner Meinung nach das Potenzial, MVP-getriebene Produktentwicklung fuer deutlich mehr Entwickler interessant zu machen – was definitiv eine gute Sache ist, da es viel Zeit spart, die sonst in Dinge investiert wuerde, die sich letztlich als Fehlschlag herausstellen. Das passt zur Lean-Startup-Methodik, die ich fuer einen grossartigen Ansatz halte, um jede Art von neuem Produkt anzugehen.

Der aktuelle Stand von SwiftUI

Damit das moeglich waere, wuerde ich erwarten, dass SwiftUI bereits alle gaengigen Eingabetypen abdeckt, die in Formularen benoetigt werden koennten – etwa fuer die Nutzerregistrierung oder andere Arten von Daten – denn viele Arten von Apps sind letztlich nichts anderes als ein Formular, das Eingabedaten entgegennimmt, sie auf irgendeine Weise transformiert und Daten auf eine besondere Art oder zu einem bestimmten Zeitpunkt zurueckgibt. Leider ist SwiftUI da noch nicht ganz angekommen.

Apples Ansatz bei SwiftUI scheint zu sein, jedes Jahr zu ueberlegen, welche Komponenten am meisten fehlen, und einige davon hinzuzufuegen. Zum Beispiel wurden auf der WWDC 2020 ProgressView, Gauge, Image-Unterstuetzung innerhalb von Text und viele andere Details bestehender Views verbessert, sowohl in Bezug auf Performance als auch Flexibilitaet. Auf der WWDC 2021 wurden mehrere async/await-bezogene APIs hinzugefuegt, wie AsyncImage oder die View-Modifier .refreshable und .task, neben anderen Verbesserungen und Ergaenzungen.

Der Vorteil dieses Ansatzes ist: Sobald etwas zum Framework hinzugefuegt wird, kann man erwarten, dass es lange Zeit existiert und auf die gleiche Weise funktioniert – grosse Codeaenderungen sind also nicht bei jedem Release noetig (wie es bei Swift als Sprache vor Swift 4 der Fall war). Der Nachteil ist, dass noch viele Komponenten fehlen. Und genau da kann die Community einspringen, um temporaere Loesungen bereitzustellen, die spaeter leicht durch offizielle Komponenten von Apple ersetzt werden koennen.

Eine Multi-Selection-View-Komponente implementieren

In diesem Beitrag moechte ich mich auf eine solche Komponente konzentrieren und meine erste Loesung dafuer vorstellen: Einen Multi-Selector, um mehrere Optionen aus einer gegebenen Menge auszuwaehlen. Derzeit bietet Apple zwar einen Picker, aber der unterstuetzt keine Mehrfachauswahl und verlaesst sogar automatisch den Listen-Screen, sobald eine einzelne Auswahl getroffen wurde. Also packen wir es direkt an!

Welche Art von Datenstruktur koennte einen Multi-Selector erfordern? Schauen wir uns dieses Beispiel an:

struct Goal: Hashable, Identifiable {
    var name: String
    var id: String { name }
}

struct Task {
    var name: String
    var servingGoals: Set<Goal>
}

Also haben wir in unserer App im Grunde eine Sammlung von Zielen und eine Sammlung von Aufgaben. Und wir moechten die Beziehung modellieren, welche Ziele jede Aufgabe bedient. Beim Erstellen oder Bearbeiten einer Task wollen wir auswaehlen, welche Ziele die Aufgabe bedient. Hier ist der SwiftUI-Code fuer eine TaskEditView:

import SwiftUI

struct TaskEditView: View {
    @State
    var task = Task(name: "", servingGoals: [])

    var body: some View {
        Form {
            Section(header: Text("Name")) {
                TextField("e.g. Find a good Japanese textbook", text: $task.name)
            }

            Section(header: Text("Relationships")) {
                Text("TODO: add multi selector here")
            }
        }.navigationTitle("Edit Task")
    }
}

struct TaskEditView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView {
            TaskEditView()
        }
    }
}

Der obige Code rendert zu dieser Vorschau:

Um zu zeigen, wie es funktionieren wuerde, wenn wir nur ein Ziel haetten, koennten wir unseren TODO-Text-Eintrag einfach durch einen Picker ersetzen:

// mock data:
let allGoals: [Goal] = [
    Goal(name: "Learn Japanese"),
    Goal(name: "Learn SwiftUI"),
    Goal(name: "Learn Serverless with Swift")
]

Picker("Serving Goal", selection: $task.servingGoal) {
    ForEach(allGoals) {
        Text($0.name).tag($0 as Goal)
    }
}

So sieht die TaskEditView jetzt aus:

Und beim Klicken auf den Picker erscheint diese Detailansicht:

Ziemlich unkompliziert. Beachte, dass Goal Identifiable sein muss, damit das funktioniert – deshalb habe ich var id: String { name } von Anfang an hinzugefuegt. Fuer unseren Multi-Selector soll das UI eigentlich ziemlich gleich aussehen, aber statt einer moechten wir mehrere Eintraege auswaehlen koennen.

Zuerst muessen wir den Eintrag in der TaskEditView neu erstellen. Ich habe MultiSelector als Ersatz-Typnamen fuer Picker gewaehlt. Hier ist die Implementierung:

import SwiftUI

struct MultiSelector<LabelView: View, Selectable: Identifiable & Hashable>: View {
    let label: LabelView
    let options: [Selectable]
    let optionToString: (Selectable) -> String
    var selected: Binding<Set<Selectable>>

    private var formattedSelectedListString: String {
        ListFormatter.localizedString(byJoining: selected.wrappedValue.map { optionToString($0) })
    }

    var body: some View {
        NavigationLink(destination: multiSelectionView()) {
            HStack {
                label
                Spacer()
                Text(formattedSelectedListString)
                    .foregroundColor(.gray)
                    .multilineTextAlignment(.trailing)
            }
        }
    }

    private func multiSelectionView() -> some View {
        Text("TODO: add multi selection detail view here")
    }
}

Beachte, dass ich mich entschieden habe, jeden Eintrag mit einem String darzustellen – daher wird die optionToString-Closure benoetigt, die die String-Darstellung des Options-Typs liefert.

Der Aufruf von ListFormatter.localizedString stellt sicher, dass wir eine Liste ausgewaehlter Optionen im korrekten Lokalisierungsformat zusammenfuegen (z. B. wird ["A", "B", "C"] im Englischen zu “A, B and C”).

Das ist der Preview-Code, den ich fuer die View verwendet habe:

struct MultiSelector_Previews: PreviewProvider {
    struct IdentifiableString: Identifiable, Hashable {
        let string: String
        var id: String { string }
    }

    @State
    static var selected: Set<IdentifiableString> = Set(["A", "C"].map { IdentifiableString(string: $0) })

    static var previews: some View {
        NavigationView {
            Form {
                MultiSelector<Text, IdentifiableString>(
                    label: Text("Multiselect"),
                    options: ["A", "B", "C", "D"].map { IdentifiableString(string: $0) },
                    optionToString: { $0.string },
                    selected: $selected
                )
            }.navigationTitle("Title")
        }
    }
}

Beachte, dass ich statt Goal einen internen Typ verwendet habe, um die Vorschau unabhaengig von meinem konkreten Projekt zu machen. So sieht die Vorschau aus:

Setzen wir das in unsere TaskEditView ein und schauen, wie es in diesem Kontext aussieht, indem wir den TODO-Text-Aufruf ersetzen durch:

MultiSelector(
    label: Text("Serving Goals"),
    options: allGoals,
    optionToString: { $0.name },
    selected: $task.servingGoals
)

Die Vorschau aendert sich jetzt zu diesem Ergebnis, das genau so aussieht wie erwartet:

Aber wenn man darauf klickt, sieht man das hier – das ist noch nicht richtig:

Implementieren wir also die Detailansicht. Ich habe den Typnamen MultiSelectionView fuer die Detailansicht gewaehlt, und hier ist der Code:

import SwiftUI

struct MultiSelectionView<Selectable: Identifiable & Hashable>: View {
    let options: [Selectable]
    let optionToString: (Selectable) -> String

    @Binding
    var selected: Set<Selectable>

    var body: some View {
        List {
            ForEach(options) { selectable in
                Button(action: { toggleSelection(selectable: selectable) }) {
                    HStack {
                        Text(optionToString(selectable)).foregroundColor(.black)

                        Spacer()

                        if selected.contains { $0.id == selectable.id } {
                            Image(systemName: "checkmark").foregroundColor(.accentColor)
                        }
                    }
                }.tag(selectable.id)
            }
        }.listStyle(GroupedListStyle())
    }

    private func toggleSelection(selectable: Selectable) {
        if let existingIndex = selected.firstIndex(where: { $0.id == selectable.id }) {
            selected.remove(at: existingIndex)
        } else {
            selected.insert(selectable)
        }
    }
}

Abgesehen von label hat diese View im Grunde die gleichen Properties. Aber diesmal werden sie tatsaechlich genutzt – zum Beispiel, wenn geprueft wird, ob das Haekchen angezeigt werden soll, indem contains auf der selected-Sammlung aufgerufen wird.

Wenn einer der Eintraege angeklickt wird, wird toggleSelection auf den Eintrag angewendet, um ihn aus der selected-Property zu entfernen oder einzufuegen. Fuer das Haekchen verwende ich das SF Symbol “checkmark”, das genauso aussieht wie das Haekchen-Icon des Picker.

Das ist der Preview-Code, den ich fuer die Detailansicht eingerichtet habe – beachte, dass er im Wesentlichen eine Kopie der MultiSelector-Vorschau ist:

struct MultiSelectionView_Previews: PreviewProvider {
    struct IdentifiableString: Identifiable, Hashable {
        let string: String
        var id: String { string }
    }

    @State
    static var selected: Set<IdentifiableString> = Set(["A", "C"].map { IdentifiableString(string: $0) })

    static var previews: some View {
        NavigationView {
            MultiSelectionView(
                options: ["A", "B", "C", "D"].map { IdentifiableString(string: $0) },
                optionToString: { $0.string },
                selected: $selected
            )
        }
    }
}

So sieht es in der Xcode-Vorschau aus:

Jetzt integrieren wir schliesslich unsere MultiSelectionView in unseren MultiSelector, indem wir den TODO-Text-Eintrag ersetzen durch:

MultiSelectionView(
    options: options,
    optionToString: optionToString,
    selected: selected
)

Im Grunde geben wir einfach die Daten an die Detailansicht weiter. Aber schauen wir uns an, wie unsere App jetzt in diesem animierten GIF aussieht, das ich aus dem Simulator aufgenommen habe:

Super, es funktioniert!

Ich habe das Demo-Projekt auf GitHub hochgeladen. Wenn du einfach den Inhalt von MultiSelector und MultiSelectionView kopieren moechtest, findest du sie in diesem Ordner.

Du fandest diesen Artikel hilfreich? Hol dir meinen Expertenrat!

Point-Free hat zum Beispiel eine großartige kostenlose Episode zu diesem Thema, und Majid Jabrayilov hat kürzlich eine 4-teilige Serie über “Microapps Architecture” geschrieben (Teile 1, 2, 3, 4), die ich beide als Einstieg empfehlen kann.

Außerdem möchtest du vielleicht Secrets auch in öffentlichen Open-Source-Bibliotheken verstecken, z.B. in den Unit-Tests einer Drittanbieter-Service-Integration, wo Nutzer der Bibliothek ihr eigenes Token bereitstellen, du aber möchtest, dass deine Tests mit deinem eigenen laufen.

Was all diese Situationen gemeinsam haben: Sie basieren auf einer manuell gepflegten Package.swift-Datei – nicht der, die Xcode für dich verwaltet, wenn du einfach eine Abhängigkeit zu einem App-Projekt hinzufügst. Die App oder das Projekt ist in viele kleine Module aufgeteilt, ohne eine zugehörige .xcodeproj-Datei – Xcode öffnet einfach direkt die Package.swift-Datei, ganz ohne ein Projekt.

Das bedeutet auch, dass es für die einzelnen Module keine Möglichkeit gibt, Build-Einstellungen oder Build-Skripte innerhalb von Xcode festzulegen – alles muss direkt in der Package.swift-Manifestdatei gemacht werden.

Obwohl immer mehr solcher Features zu SwiftPM hinzugefügt werden (wie SE-303, SE-325, SE-332) in zukünftigen Releases, gibt es keine Anzeichen dafür, dass sie Xcode-spezifische Features wie .xcconfig-Dateien unterstützen werden.

Wie können wir also Secrets heute davon abhalten, in Git zu landen, damit sie nicht an unseren Git-Provider oder jemanden mit Zugriff auf unser Repository gelangen?

SwiftPM-Ressourcen & JSONDecoder

Ich bin sicher, es gibt nicht die eine “beste” Antwort darauf und andere haben vielleicht cleverere Ideen als ich. Aber ich halte die Dinge gerne einfach und verwende gerne grundlegende Features, weil ich sie gut kenne und erwarte, dass andere Entwickler sie bei Bedarf schnell verstehen. Außerdem kann ich mir sicher sein, dass sie zukunftssicher sind.

Der Ansatz, den ich verwenden möchte, ist der klassische .env-Datei-Ansatz, der in der Webentwicklung verbreitet ist. Aber statt einer speziell formatierten .env-Datei möchte ich einfach eine .json-Datei mit meinen Secrets verwenden, weil JSON-Dateien vielen iOS-Entwicklern vertraut sind und wir dank JSONDecoder in Swift bereits eingebaute Unterstützung fürs Parsen haben. Das Laden von Dateien oder allgemeiner “Ressourcen” wird ebenfalls seit Swift 5.3 von SwiftPM unterstützt (SE-271).

Hier ist die Grundidee, wie ich Secrets vor Git verbergen möchte:

1. Eine secrets.json.sample-Datei mit den Keys, aber ohne Werte, in Git einchecken

2. Entwickler duplizieren sie, entfernen die .sample-Endung und tragen die Werte ein

3. Die secrets.json-Datei über .gitignore ignorieren, damit sie nie eingecheckt wird

4. Ein einfaches struct bereitstellen, das Decodable implementiert, um die Secrets auszulesen

Der Rest dieses Artikels ist eine Schritt-für-Schritt-Anleitung, wie du diesen Ansatz anwendest. Ich werde als Beispiel die Unit-Tests meines Open-Source-Übersetzungstools BartyCrouch verwenden, das zwei Drittanbieter-Übersetzungsdienste integriert.

⚠️ Beachte bitte, dass du bei der Anwendung dieses Ansatzes auf ein App-Target, das du an Nutzer ausliefern willst, wahrscheinlich auf dasselbe Problem stößt, das beim .xcconfig-Ansatz in diesem NSHipster-Artikel beschrieben wird. Meine Methode hilft nur beim Verbergen der Secrets vor Git – du brauchst zusätzliche Verschleierung, wenn du sie an Nutzer ausliefern willst.

Die secrets.json-Ressourcendatei hinzufügen

Zuerst fügen wir die secrets.json-Datei zu unserem Projekt hinzu. Da es eine zugehörige secrets.json.sample und eine Secrets.swift-Datei geben wird, erstelle ich zunächst einen Ordner Secrets, dann eine leere Datei namens secrets.json, und füge eine einfache JSON-Dictionary-Struktur mit zwei Keys hinzu:

Und so ist auch meine CI eingerichtet, um sicher auf meine Secrets zuzugreifen, ohne sie preiszugeben.

Aber diese Strategien sind für eine übergeordnete Art der Priorisierung gedacht – also um zu entscheiden, ob du zuerst Feature A oder Feature B umsetzen solltest oder ob Feature C überhaupt in die nächste Version gehört. Sie skalieren aber nicht auf Aufgaben oder gar Unteraufgaben deiner Features herunter, sodass man bei einem bestimmten Feature durchaus zu viel tun kann. Außerdem helfen sie nicht bei der Frage, wann du das Feature in die Hände der Nutzer geben kannst, um frühes Feedback zu sammeln und nutzerzentrierte Ansätze wie die Lean-Startup-Methodik anzuwenden. Man könnte natürlich eine skalenunabhängige Methode wählen, wie die MoSCoW-Methode, aber deren Kategorien wären nicht einfach einzuordnen, weil sie so abstrakt sind, dass verschiedene Personen unterschiedliche Erwartungen an jede Kategorie hätten.

Das Ziel der Laser-Focus-Priorisierungsstrategie ist es, klare Bewertungskategorien bereitzustellen, beim Aufgabenumfang zu helfen und eine einfach anwendbare Interpretationsmethode zu bieten. Alle drei Aspekte zusammen helfen dir, den Fokus zu behalten.

Laser-Focus-Kategorien

Es gibt drei Ziele, die wir mit unseren Kategorien erreichen wollen:

1. Entscheiden, welche Aufgaben im Umfang des aktuell geplanten Releases liegen.

2. Aufgaben, die für eine Alpha- oder Beta-Version nötig sind, höher priorisieren als andere.

3. Die Kategorienamen sollen eine handlungsorientierte, eigenständige Bedeutung haben.

Wir schlagen folgende Kategorien vor, die alle Anforderungen erfüllen:

Vital

Absolutes Minimum, das für die erste Testrunde nötig ist. Darf hässlich sein.

Damit kann ein Produkt mit nur den „Vital”-Features oder -Aufgaben an eine kleine Gruppe von Testern ausgeliefert werden, um frühes Feedback zu bekommen. Natürlich sollte der Umfang dieses Alpha-Tests klar kommuniziert werden – also welche grundlegenden Features oder Aufgaben noch fehlen, damit sie nicht unnötig von den Testern gemeldet werden. Aber die vitalen Teile des Produkts oder Features können schon getestet werden und wir bekommen die erste Runde Feedback, die zeigt, ob wir in die richtige Richtung gehen.

Essential

Kernaspekte, die für die grundlegende Funktionalität nötig sind. Darf raue Kanten haben.

Eine zweite, größere Testrunde kann gestartet werden, sobald alle „Essential”-Features oder -Aufgaben umgesetzt sind. Auf dieser Stufe muss kein konkreter Testumfang kommuniziert werden – es reicht, die Version als „Beta” zu bezeichnen, bei der die Grundfunktionen verfügbar sind, aber noch vieles fehlt oder unvollständig ist.

Completing

Raue Kanten glätten und Funktionalitäten vervollständigen.

Die „Completing”-Stufe definiert den Umfang, bei dem das finale Produkt bereit für das Release ist. In manchen Situationen, z. B. wenn eine neue Version für ein bestimmtes Datum angekündigt wurde, kann das Produkt auch veröffentlicht werden, während noch einige „Completing”-Aufgaben offen sind – dann sollte es aber öffentlich als „Beta” gekennzeichnet werden. Typischerweise umfasst diese Stufe alle Features oder Aufgaben, die für eine größere Nutzerbasis wichtig sind, aber für die Bewertung des Kerns des Produkts nicht relevant sind.

Optional

Nice-to-haves, die auf spätere Versionen verschoben oder ganz weggelassen werden können.

Die „Optional”-Stufe drückt aus, dass die so bewerteten Features oder Aufgaben zwar gewünscht sind, aber in keiner Weise nötig, um eine fertige Version eines Produkts zu veröffentlichen – auch langfristig nicht. Daher können sie bei Bedarf je nach Ressourcen des Teams einfach verschoben oder gestrichen werden.

Retracting

Nice-to-haves (auf den ersten Blick), die (potenziell) mehr schaden als nützen können.

Anders als „Optional” sollten Features oder Aufgaben, die als „Retracting” bewertet werden, aktiv vermieden werden. Das heißt, es kann sinnvoll sein, sie inklusive der Begründung, warum sie vermieden werden sollten, für langfristige Entscheidungsfindung zu dokumentieren. Das spart Zeit, wenn dieselbe Idee irgendwann in der Zukunft wieder aufkommt. Außerdem kann es bei der Bewertung durch mehrere Personen helfen, die Aufgaben zu identifizieren, bei denen eine Diskussion nötig ist, um die Auswirkung einer Aufgabe auf das Produkt zu klären.

Laser-Focus-Matrix

Die zweite Säule der Laser-Focus-Strategie ist ihre mehrdimensionale Skalierbarkeit. Um zu erklären, was das bedeutet und warum es wichtig ist, wenden wir die bisherigen Kategorien an einem Beispiel an: Lass uns eine Stoppuhr-App entwickeln, die die Zeit für verschiedene Tätigkeiten über den Tag hinweg erfasst. Das ist die anfängliche Liste der Feature-Ideen, bewertet mit den Laser-Focus-Kategorien:

1. Projekte erstellen → Essential (essentiell für die App, aber vorgefüllte Projekte reichen für den ersten Test)

2. Projekte bearbeiten → Completing (für Testzwecke nicht nötig, aber für das finale Release)

3. Projekte löschen → Completing (Aufräumaufgabe, für Tests nicht nötig, aber für das finale Release)

4. Timer starten/stoppen → Vital (Kernidee der App, vitaler Teil)

5. Ein Projekt für den Timer auswählen → Vital (ohne Projektauswahl ist die App-Idee nicht erfüllt)

6. Vergangene erfasste Zeiten bearbeiten → Retracting (V2 mit Wettbewerbs-Feature geplant, Risiko von Manipulation)

7. Vergangene erfasste Zeiten löschen → Optional (nice to have, kein Manipulationsrisiko, da keine Zeit hinzugefügt wird)

8. Historische erfasste Zeit für ein ausgewähltes Projekt anzeigen → Essential (Kernanwendungsfall der App)

9. Projekte mit der meisten erfassten Zeit anzeigen → Essential (Kernanwendungsfall der App)

Dank der Kategorisierung können wir schon zwei Features aus dem ersten Release ausschließen und haben sogar ein Feature erkannt, das wir wahrscheinlich nie umsetzen sollten (6) und das dauerhaft dokumentiert werden sollte. Aber noch wichtiger: Wir wissen jetzt, dass 4 und 5 die „Vital”-Features sind, die zuerst umgesetzt werden müssen.

Fangen wir an, an ihren Unteraufgaben zu arbeiten:

4. Timer starten/stoppen: (Vital)

a. Start/Stop-Button-Layout designen (Low Fidelity) b. Start/Stop-Button-Farben & Icons designen (High Fidelity) c. Start/Stop-Button pulsierenden Schatteneffekt designen (Animationen) d. Start/Stop-Button-Layout implementieren (Low Fidelity) e. Start/Stop-Button-Farben & Icons implementieren (High Fidelity) f. Start/Stop-Button pulsierenden Schatteneffekt implementieren (Animationen) g. Grundlegende Datenbankmodelle für erfasste Zeiten aufsetzen h. Start/Stop-Aktionen in der Datenbank persistieren

5. Ein Projekt für den Timer auswählen: (Vital)

a. Projektauswahl-Navigation & Layout designen (Low Fidelity) b. Projektauswahl-Formen, Farben & Icons designen (High Fidelity) c. Projektauswahl-Navigation & Layout implementieren (Low Fidelity) d. Projektauswahl-Formen, Farben & Icons implementieren (High Fidelity) e. Ausgewähltes Projekt im Datenbankmodell für erfasste Zeiten persistieren

Alles klar, legen wir los, oder? Oder?

Nein. Du hast es sicher schon beim Lesen bemerkt. Es gibt ein Problem. Wir haben die Features priorisiert und darüber nachgedacht, was wirklich nötig ist, um testbar zu sein, um die App in die Hände der Nutzer zu geben. Aber jetzt haben wir dasselbe Problem wieder, nur auf einer anderen Ebene. Diese Aufgaben (und potenziell auch ihre Unteraufgaben) sind nicht alle „Vital” für unsere allererste Version, die wir in die Hände der Nutzer geben wollen. Wie können wir das lösen? Sollten wir eine weitere Bewertung für die Aufgaben durchführen?

Ja, unbedingt! Das ist sogar eine Anforderung der Laser-Focus-Strategie: Wende die Bewertung auf allen Ebenen nach unten hin an! Nicht unbedingt auf höheren Ebenen, wo du jede beliebige alternative Priorisierungstechnik verwenden darfst. Aber die tieferen Ebenen ab dem Punkt, an dem du anfangen willst, sollten alle so bewertet werden.

Weisen wir den Aufgaben also auch die Laser-Focus-Kategorien zu und schauen dann, was das für die Gesamtpriorität bedeutet:

4. Timer starten/stoppen: (Vital)

a. Start/Stop-Button-Layout designen (Low Fidelity) → Vital b. Start/Stop-Button-Farben & Icons designen (High Fidelity) → Completing c. Start/Stop-Button pulsierenden Schatteneffekt designen (Animationen) → Optional d. Start/Stop-Button-Layout implementieren (Low Fidelity) → Vital e. Start/Stop-Button-Farben & Icons implementieren (High Fidelity) → Completing f. Start/Stop-Button pulsierenden Schatteneffekt implementieren (Animationen) → Optional g. Grundlegende Datenbankmodelle für erfasste Zeiten aufsetzen → Essential h. Start/Stop-Aktionen in der Datenbank persistieren → Essential

5. Ein Projekt für den Timer auswählen: (Vital)

a. Projektauswahl-Navigation & Layout designen (Low Fidelity) → Vital b. Projektauswahl-Formen, Farben & Icons designen (High Fidelity) → Completing c. Projektauswahl-Navigation & Layout implementieren (Low Fidelity) → Vital d. Projektauswahl-Formen, Farben & Icons implementieren (High Fidelity) → Completing e. Ausgewähltes Projekt im Datenbankmodell für erfasste Zeiten persistieren → Essential

Wichtig: Der Bezugswert für die Bewertung der Aufgaben war das Feature, weil es das direkte Elternelement ist. Das heißt, ich habe mir die Frage gestellt: „Ist das Persistieren von Start/Stop-Aktionen in der Datenbank vital oder essential für das Feature Timer starten/stoppen?” – und nicht für die App oder irgendetwas anderes. Das macht die Beantwortung der Fragen deutlich einfacher.

Visualisieren wir diese zwei verschiedenen Bewertungsebenen mit einer einfachen Matrix. Auf der X-Achse sind die Bewertungen der Features. Auf der Y-Achse die Bewertungen der Aufgaben. Die Kreise stellen die Aufgaben dar:

Wie du sehen kannst, befinden sich die Aufgaben 4a, 4d, 5a und 5c im Feld unten links, dem „Vital-Vital”-Feld, kurz „VV”. Der Hintergrund des Feldes ist rot eingefärbt. Es enthält alle Aufgaben, auf die man sich zuerst konzentrieren sollte. Sobald sie alle umgesetzt sind, kann die allererste Testrunde beginnen und die Alpha-Phase startet.

Die Aufgaben 4g, 4h und 5e im gelb eingefärbten Feld „Vital-Essential” oder kurz „VE” sollten als Nächstes angegangen werden. Sobald alle Aufgaben in allen drei gelb eingefärbten Feldern (VV, VE, EV) abgeschlossen sind, beginnt die Beta-Phase.

Das „VC”-Feld mit seinen „Completing”-Aufgaben für die „Vital”-Features sollte unter den bisher definierten Aufgaben zuletzt angegangen werden. Sobald alle Aufgaben in allen grün eingefärbten Feldern (VC, CV, EC, CE, CC) erledigt sind, ist es Release-Zeit.

Im obigen Beispiel haben wir die Aufgaben für alle nicht-vitalen Features übersprungen. Hätten wir sie auch bewertet, hätte die vollständige Matrix etwa so aussehen können, einschließlich der „Retracting”-Bewertung:

Wir können sehen, wie die Alpha-, Beta- und Release-Aufgaben kreisförmig um den Ursprungspunkt (unten links) geschichtet sind und uns visuell eine Priorität für jede Aufgabe basierend auf ihrem Abstand zum Ursprung geben. Das skaliert problemlos auf eine dritte Achse, wenn zum Beispiel Unteraufgaben zu jeder Aufgabe hinzukommen. Formal gesprochen skaliert das auf beliebig viele Dimensionen. Um die Gesamtkategorie eines bestimmten Elements zu berechnen, schau dir einfach alle Vorfahren an und wähle die niedrigste Priorität als Gesamtkategorie des „atomaren” (untersten) Elements. Stell dir zum Beispiel eine Unteraufgabe mit der Kategoriebewertung „Essential” vor, einer übergeordneten Aufgabe mit „Vital” und deren übergeordnetem Feature mit „Completing”. Insgesamt ist die niedrigste Priorität „Completing”, also ist das die Gesamtkategorie der Unteraufgabe.

Die Berechnung der Gesamtkategorie allein kann dazu führen, dass viele Aufgaben auf derselben Stufe landen, besonders bei „Completing”, wo wir 5 verschiedene Felder haben. Eine Möglichkeit, Features oder Aufgaben innerhalb derselben Kategorie zu priorisieren, ist die Berechnung des Durchschnitts aus der eigenen Kategorie und der aller Vorfahren-Kategorien. Dazu weisen wir jeder Kategorie eine Zahl zu (von 1 „Vital” bis 5 „Retracting”), die unterste Ebene (z. B. eine Unteraufgabe) kann dann als Tupel dargestellt werden, z. B. (2, 1, 3) im obigen Beispiel. Der Durchschnitt dieser Zahlen wird einfach berechnet: (2 + 1 + 3) / 3 = 2.0. Eine andere Aufgabe mit mehr Vorfahren und derselben Gesamtkategorie „Completing” könnte als (3, 2, 3, 1) bewertet sein und hätte daher einen Durchschnitt von (3 + 2 + 3 + 1) / 4 = 2.25, sollte also niedriger priorisiert werden. Je höher der Gesamtdurchschnitt, desto niedriger die Priorität – das ergibt viel Sinn, da die Durchschnittszahl in etwa den Abstand zum Ursprung widerspiegelt – der höchstmöglichen Priorität.

Aber keine Sorge, du musst diese Durchschnitte nicht tatsächlich berechnen. Es gibt einen einfacheren Weg basierend auf der Matrix, die wir oben gesehen haben, mit ausreichender Genauigkeit:

Das obige Diagramm zeigt, in welcher Reihenfolge die Felder bearbeitet werden sollten, basierend auf dem Abstand zum Ursprung. Beachte, dass es jeweils zwei Felder auf Platz 2, 4 und 5 gibt. Für diese Felder muss je nach Situation eine Entscheidung getroffen werden: Sollten wir uns mehr darauf konzentrieren, weitere Features hinzuzufügen? Oder sollten wir uns mehr darauf konzentrieren, die bereits begonnenen Features zu verbessern? Für eine Feature-Erweiterung zuerst solltest du in Richtung der „Feature-Kategorie” weitermachen, z. B. „EV” vor „VE”. Für die Verbesserung bestehender Features zuerst sollte es andersherum sein.

Laser-Focus-Aufschlüsselung

Im obigen Abschnitt haben wir gelernt, dass die Kategorisierung auf mehreren Ebenen der Schlüssel zum Laser-Focus-Konzept ist. Wenn du das direkt auf dein Projekt anwenden willst, wirst du vielleicht feststellen, dass viele oder sogar alle deine Features oder Aufgaben für dich eigentlich „Vital” oder „Essential” sind. Wenn das der Fall ist, dann ist es ein Zeichen dafür, dass du deine Aufgaben wahrscheinlich noch nicht effizient aufgeteilt hast.

Deshalb ist es wichtig, deine Aufgaben richtig herunterzubrechen, bevor du sie kategorisierst. Die Leitfrage, die du dir beim Aufteilen von Features in Aufgaben oder Aufgaben in Unteraufgaben stellen solltest, sollte nicht nur sein: „Welche Schritte muss ich machen, um es fertigzustellen?” Du solltest auch den Aufwand für jeden Schritt bedenken, und wenn der Aufwand nicht vernachlässigbar klein ist, solltest du in Betracht ziehen, ihn abzutrennen. Manchmal mag das schwierig erscheinen, aber meistens ist es eine gute Idee, dem Ansatz „erst zum Laufen bringen, dann verbessern” beim Aufteilen der Aufgaben zu folgen.

Beim obigen Feature „Timer starten/stoppen” hätten wir zum Beispiel in 3 Aufgaben aufteilen können: „Start/Stop-Buttons designen”, „Start/Stop-Buttons implementieren” und „Daten persistieren”. Das Problem dabei ist, dass es keine verschiedenen Fertigstellungsstufen gibt. Es ist besser, noch weiter herunterzubrechen. Natürlich könnten wir das als Unteraufgaben unter diesen Aufgaben tun, aber um die Prioritätsberechnung einfacher zu machen, empfiehlt es sich, es auf weniger Ebenen zu tun. Also haben wir uns stattdessen für „Start/Stop-Button-Layout designen”, „Start/Stop-Button-Layout implementieren” entschieden und dieselben zwei Aufgaben auch für „… Farben & Icons” und „… pulsierender Schatteneffekt”.

Frag dich, welche Teile ihren eigenen Aufwand haben, und teile sie so auf, dass jede Aufgabe es wert ist, basierend auf dem nötigen Aufwand priorisiert zu werden. Trenne keine Mikroaufgaben ab – es lohnt sich nicht, so kleine Aufgaben zu priorisieren; behalte sie einfach als Teil einer anderen Aufgabe.

Eine ordentliche Aufschlüsselung ist sehr wichtig, damit die Laser-Focus-Strategie effektiv ist.

Zusammenfassung

Fassen wir die Laser-Focus-Priorisierungsstrategie in der richtigen Reihenfolge zusammen:

1. Brich deine Features und Aufgaben in kleinere Schritte mit verschiedenen Fertigstellungsstufen herunter

2. Bewerte sie auf jeder Ebene mit „Vital”, „Essential”, „Completing”, „Optional” oder „Retracting”

3. Visualisiere oder berechne die Gesamtpriorität für die unterste Ebene unter Berücksichtigung aller Vorfahren

Wende diese Schritte zu jedem beliebigen Zeitpunkt in deinem Projekt an und sie werden dir helfen, dich auf die wichtigen Dinge zu konzentrieren und deine In-Arbeit-Versionen so früh wie sinnvoll in die Hände der Nutzer zu geben.

Natürlich müssen diese gelöst werden, bevor der Arbeits-Branch gemergt werden kann. Aber die Frage ist: Wie sollte diese Situation gelöst werden? Sollten wir den Main-Branch in den Arbeits-Branch mergen? Oder sollten wir den Arbeits-Branch auf den neuesten Main-Branch rebasen?

Meiner Meinung nach gibt es nur eine richtige Antwort auf diese Frage. Aus meiner Erfahrung ist der Hauptgrund, warum so viele Diskussionen rund um dieses Thema entstehen, dass es viele Missverständnisse darüber gibt, wie sich Merge und Rebase in diesem Kontext unterscheiden, und ein generelles Verständnisdefizit, was ein Rebase überhaupt ist.

Deshalb habe ich eine FAQ für mein Team erstellt, die versucht, die Dinge klarzustellen. Die möchte ich hier teilen:

Was ist ein Merge?

Ein Commit, der alle Änderungen eines anderen Branches in den aktuellen kombiniert.

Was ist ein Rebase?

Alle Commits des aktuellen Branches auf einen anderen Basis-Commit neu anzuwenden.

Was sind die Hauptunterschiede zwischen Merge und Rebase?

1. merge führt nur einen neuen Commit aus. rebase führt typischerweise mehrere aus (Anzahl der Commits im aktuellen Branch).

2. merge erzeugt einen neuen generierten Commit (den sogenannten Merge-Commit). rebase verschiebt nur bestehende Commits.

In welchen Situationen sollte man merge verwenden?

Verwende merge, wenn du Änderungen eines abgezweigten Branches zurück in den Basis-Branch übernehmen willst.

Typischerweise macht man das über den “Merge”-Button bei Pull/Merge Requests, z.B. auf GitHub.

In welchen Situationen sollte man rebase verwenden?

Verwende rebase, wenn du Änderungen eines Basis-Branches in einen abgezweigten Branch übernehmen willst.

Typischerweise macht man das in work-Branches, wenn es eine Änderung im main-Branch gibt.

Warum nicht merge verwenden, um Änderungen vom Basis-Branch in einen Arbeits-Branch zu mergen?

1. Die Git-History wird viele unnötige Merge-Commits enthalten. Wenn mehrere Merges in einem Arbeits-Branch nötig waren, könnte der Arbeits-Branch sogar mehr Merge-Commits als eigentliche Commits enthalten!

2. Das erzeugt eine Schleife, die das mentale Modell zerstört, für das Git entworfen wurde, was zu Problemen bei jeder Visualisierung der Git-History führt.

Stell dir vor, es gibt einen Fluss (z.B. den “Nil”). Wasser fließt in eine Richtung (Zeitrichtung in der Git-History). Hin und wieder gibt es Abzweigungen von diesem Fluss und die meisten davon fließen irgendwann wieder in den Fluss zurück. So könnte der natürliche Flussverlauf aussehen. Das ergibt Sinn.

Aber dann stell dir mal vor, es gibt eine kleine Abzweigung dieses Flusses. Dann, aus irgendeinem Grund, fließt der Fluss in die Abzweigung und die Abzweigung geht von dort aus weiter. Der Fluss ist nun technisch gesehen verschwunden, er befindet sich jetzt in der Abzweigung. Aber dann, auf magische Weise, wird diese Abzweigung wieder zurück in den Fluss geführt. In welchen Fluss fragst du? Keine Ahnung. Der Fluss sollte eigentlich in der Abzweigung sein, aber irgendwie existiert er noch weiter und ich kann die Abzweigung zurück in den Fluss führen. Also ist der Fluss im Fluss. Irgendwie ergibt das keinen Sinn.

Genau das passiert, wenn du den Basis-Branch in einen work-Branch mergest und dann, wenn der work-Branch fertig ist, diesen wieder zurück in den Basis-Branch mergst. Das mentale Modell ist kaputt. Und deswegen hat man am Ende eine Branch-Visualisierung, die nicht besonders hilfreich ist.

Beispiel einer Git-History bei Verwendung von merge:

Beispiel einer Git-History bei Verwendung von merge

Beachte die vielen Commits, die mit Merge branch 'main' into … beginnen (mit gelben Kästchen markiert). Die existieren bei einem Rebase gar nicht (dort hat man nur Pull-Request-Merge-Commits). Beachte auch die vielen visuellen Branch-Merge-Schleifen (main in work in main).

Beispiel einer Git-History bei Verwendung von rebase:

Beispiel einer Git-History bei Verwendung von rebase

Viel sauberere Git-History mit deutlich weniger Merge-Commits und keinerlei unübersichtlichen visuellen Branch-Merge-Schleifen.

Gibt es Nachteile / Fallstricke bei rebase?

Ja:

1. Da ein rebase Commits verschiebt (technisch gesehen neu ausführt), wird das Commit-Datum aller verschobenen Commits auf den Zeitpunkt des Rebase gesetzt und die Git-History verliert den ursprünglichen Commit-Zeitpunkt. Wenn also das genaue Datum eines Commits aus irgendeinem Grund wichtig ist, dann ist merge die bessere Option. Aber typischerweise ist eine saubere Git-History viel nützlicher als exakte Commit-Daten.

2. Wenn der gerebaste Branch mehrere Commits hat, die dieselbe Zeile ändern, und diese Zeile auch im Basis-Branch geändert wurde, musst du möglicherweise Merge-Konflikte für dieselbe Zeile mehrmals lösen, was beim Mergen nie nötig ist. Im Durchschnitt gibt es also mehr Merge-Konflikte zu lösen.

Tipps zur Reduzierung von Merge-Konflikten bei Verwendung von rebase:

1. Häufig rebasen. Ich empfehle, es mindestens einmal täglich zu machen.

2. Versuche, Änderungen an derselben Zeile so weit wie möglich in einen Commit zusammenzufassen (squashen).

Ich hoffe, diese FAQ hilft dem einen oder anderen Team da draußen.

Reguläre Ausdrücke (kurz Regexes) sind Strings, die als DSL (Domain-Specific Language, also eine domänenspezifische Sprache) funktionieren, um bestimmte häufige Aufgaben in anderen Strings zu erledigen. Eine DSL kann man auch als “eine Programmiersprache innerhalb einer Programmiersprache” beschreiben.

Im Fall von Regexes kann die äußere Programmiersprache jede beliebige Sprache sein, die den Typ String unterstützt – sie muss eben nur Regexes unterstützen. Nahezu alle populären Programmiersprachen unterstützen Regexes, was sie so nützlich macht. Die innere Sprache der Regexes besteht nur aus String, wobei bestimmte Zeichen eine besondere Bedeutung haben.

Zum Beispiel bedeutet im String ".*@.*\\.com" der . “ein beliebiges Zeichen”, das * bedeutet “beliebig oft ”, zusammen bedeutet .* also “beliebig viele beliebige Zeichen”. Dann haben wir ein nicht-spezielles Zeichen @, dann wieder .* gefolgt von \\, was “das nächste Zeichen escapen und als nicht-spezielles Zeichen behandeln” bedeutet – \\. zusammen liest sich also wie ein normaler . ohne die besondere Bedeutung “beliebiges Zeichen”. Zum Schluss kommt com, was einfach eine Reihe von Zeichen ohne besondere Bedeutung ist. Insgesamt ist diese Regex ein einfacher Matcher für jede E-Mail-Adresse, die mit .com endet und irgendwo ein @ enthält.

Was kann ich mit der “Regex-DSL” machen?

ℹ️ Wenn du Ruby installiert hast (auf Macs ist es vorinstalliert), kannst du irb eingeben, um eine interaktive Ruby-Shell zu starten und mit den folgenden Beispielen herumzuspielen.

Es gibt drei Hauptfunktionen, mit denen jeder Regex-String verwendet werden kann:

1. matches: Gegeben eine Regex und einen anderen String, prüft diese Funktion, ob der gegebene String zur Regex “passt”. Das heißt, wenn es “irgendeinen” Teil im gegebenen String gibt, der zur angegebenen Regex passt, gibt sie true zurück, sonst false. Zum Beispiel in Ruby (wo matches als match? heißt – das ? ist Teil des Funktionsnamens):

/.*@.*\\.com/.match?('harry.potter@hogwarts.co.uk') # => false /.*@.*\\.com/.match?('queenie.goldstein@ilvermorny.com') # => true

1. captures: Gegeben eine Regex und einen anderen String, kann diese Funktion Teilstrings aus dem gegebenen Text auslesen, die zu markierten Teilen der gegebenen Regex passen. Die Teile in der Regex werden mit ( und ) markiert. Sie werden “Capture Groups” (Erfassungsgruppen) genannt. Zum Beispiel in Ruby (wo auf captures über das Match-Objekt zugegriffen wird):

/(.*)@(.*)\\.com/.match('queenie.goldstein@ilvermorny.com').captures # => ["queenie.goldstein", "ilvermorny"]

1. replace: Gegeben eine Regex und ein Template-String, kann diese Funktion Treffer automatisch mit einem gegebenen String ersetzen, wobei sogar die Capture Groups über $1, $2 oder in manchen Sprachen auch \\1, \\2 usw. referenziert werden können. Zum Beispiel in Ruby (wo replace als gsub heißt):

'queenie.goldstein@ilvermorny.com'.gsub(/(.*)@(.*)\\.com/, '\\1@\\2.org') # => "queenie.goldstein@ilvermorny.org"

Wie sieht die “Regex-DSL” aus?

Es gibt jede Menge nützliche “Cheat Sheets” mit tollen Beispielen dafür:

• https://www.rexegg.com/regex-quickstart.html#chars

• Regular Expression Examples

Grundsätzlich gibt es 5 verschiedene Arten von DSL-Komponenten zu verstehen:

1. Zeichen-/Gruppenmodifikatoren (z.B. *, +, {,}, ?)

Der Standard-“Baustein” von Regexes sind Zeichen. Nach jedem Zeichen kannst du einen Modifikator schreiben, der angibt, wie oft das vorangehende Zeichen gematcht wird. Folgende Modifikatoren stehen zur Verfügung:

**0 oder 1 Mal: ** ? (Beispiel: a?b?c? matcht a, ab, abc, bc, c)

**Genau 1 Mal: ** Kein Modifikator (Standard)

**0 bis ♾️ Mal: ** * (Beispiel: a*bc matcht bc, abc, aaabc)

1 bis ♾️ Mal: + (Beispiel: a+bc matcht abc, aaabc, aber nicht bc)

Genau X Mal: {X} (Beispiel: a{3}bc matcht aaabc, aber nicht aabc, aaaabc)

X bis Y Mal: {X,Y} (Beispiel: a{2,5}bc matcht aaaaabc, aber nicht abc)

X bis ♾️ Mal: {X,} (Beispiel: a{2,}bc matcht aaaaaaaabc, aber nicht abc)

Die gleichen Modifikatoren funktionieren auch auf Gruppen (z.B. (abc)+) (siehe unten bei Gruppen).

Benutzerdefinierte Zeichensätze (erstellt mit [ und ])

Du kannst eigene Zeichensätze definieren, indem du die Zeichen ohne Trennzeichen in eckigen Klammern auflistest, z.B. für einen Satz der Zeichen a, b, c und der Zahlen 1, 2, 3 schreibst du [abc123]. Dies wird dann als “ein Zeichen aus diesem Satz” betrachtet, und um mehrere davon zu matchen, braucht man Zeichenmodifikatoren wie [abc123]* oder [abc123]{2,5}.

Du kannst auch ^ am Anfang eines benutzerdefinierten Zeichensatzes verwenden, um anzugeben, dass du jedes Zeichen akzeptierst, außer denen, die du in den Klammern angegeben hast, z.B. [^\\n] um jedes Zeichen außer einem Zeilenumbruch zu akzeptieren.

Bei Zeichen, von denen du weißt, dass sie direkt aufeinanderfolgen – wie Zahlen oder das Alphabet – kannst du auch Bereiche verwenden, indem du ein - dazwischensetzt, z.B. [a-zA-Z0-9].

[abc123]{3,} würde nicht a, b, c, ab matchen, aber 111, abc schon.

Vordefinierte Zeichensätze (\\s, \\S, \\d, \\D, \\w, \\W)

Die folgenden Zeichensätze (vereinfacht) sind bereits vordefiniert und können direkt verwendet werden:

• \\s entspricht im Wesentlichen [ \\t\\n], liest sich als “ein beliebiges Leerzeichen”

• \\S entspricht im Wesentlichen [^ \\t\\n], liest sich als “ein beliebiges Nicht-Leerzeichen”

• \\d entspricht im Wesentlichen [0-9], liest sich als “eine beliebige Ziffer”

• \\D entspricht im Wesentlichen [^0-9], liest sich als “eine beliebige Nicht-Ziffer”

• \\w ähnlich wie [a-zA-Z_0-9] (einschließlich Umlaute usw.), liest sich als “ein beliebiges Wortzeichen”

• \\W ähnlich wie [^a-zA-Z_0-9], liest sich als “ein beliebiges Nicht-Wortzeichen”

Gruppen (z.B. ( und ), (?<name> und ))

Gruppen kann man sich wie “Wörter” oder “Sätze” vorstellen – sie ändern den Standard-Baustein, der “Zeichen” ist, für jeden Modifikator auf einen Satz von Zeichen, also eine “Gruppe”. Zum Beispiel liest sich abc* als “einmal a, einmal b und beliebig oft c”. Wenn du “beliebig oft abc” schreiben willst, machst du es so: (abc)*. Das abc wird dann als eine Gruppe betrachtet und die Regex würde den gesamten String abcabcabc matchen.

Gruppen erlauben es auch, verschiedene Optionen zur Auswahl anzugeben. Dafür schreibst du eine Gruppe und trennst die verschiedenen Wörter mit einem |, so: (abc|def) – das liest sich als “entweder abc oder def” und würde sowohl 123abc123 als auch 456def456 matchen, aber nicht adbecf.

Diese erfassen bestimmte Teilabschnitte einer Regex und weisen ihnen eine Nummer oder einen Namen zu, der dann im Code oder in Ersetzungs-Templates referenziert werden kann. Typischerweise werden Capture Groups wie in (.*)@(.*).com dann über \\1@\\2.com oder $1@$2.com (je nach Sprache) zurückreferenziert.

Es ist auch möglich, den Gruppen Namen zu geben, z.B. (?<user>.*)@(?<domain>.*).com, um sie dann wie in ${user}@${domain}.com zu referenzieren, aber das sind fortgeschrittene Features, die in verschiedenen Sprachen unterschiedlich implementiert sind (und in manchen fehlen).

Match-Modifikatoren (z.B. \\A, \\z, ^, $, Lookaheads und Lookbehinds)

Standardmäßig wird ein Match für eine Regex wie abc wie eine contains-Methode ausgeführt. Du kannst aber auch angeben, dass der String abc am Anfang oder Ende eines gegebenen Strings oder einer Zeile stehen muss. Zum Beispiel stellt das ^ in ^abc sicher, dass nur Strings matchen, bei denen abc am Anfang einer neuen Zeile steht. Das würde def\\nabc matchen, aber nicht defabc. Das $ in abc$ stellt sicher, dass nach abc ein Zeilenende kommt. Verwende \\A und \\z, um über den gesamten String zu matchen (über mehrere Zeilen hinweg).

Lookaheads und Lookbehinds sind eher ein fortgeschrittenes Thema und besonders dann nützlich, wenn du matchen willst, dass der Anfang oder das Ende deiner Regex NICHT auf eine bestimmte Regex passt. In den meisten Fällen können Regexes mit Lookaheads und Lookbehinds auch mit Capture Groups umgeschrieben werden, also solltest du sie als Capture Groups zu schreiben versuchen und dich nur über Lookarounds informieren, wenn die anderen Optionen nicht funktionieren – denn Lookarounds sind CPU-intensive Operationen und auch etwas eingeschränkt (z.B. unterstützen sie die meisten Modifikatoren nicht).

Hier ist ein guter Ort, um mehr darüber zu erfahren:

Häufige Eigenheiten und Validierung neuer Regexes

Eine häufige Sache, die man beachten sollte: Der . matcht in den meisten Sprachen standardmäßig nicht den Zeilenumbruch. Aber das lässt sich typischerweise mit einer Option aktivieren – in Ruby z.B. durch Angabe von /m am Ende, was für “make dot match newlines” steht.

Beachte auch, dass es in jeder Sprache verschiedene Zeichen gibt, die reserviert sind, je nachdem wie Strings in der jeweiligen Sprache funktionieren. In Ruby z.B. muss / mit \\/ escaped werden, in Swift ist dieses Escaping nicht nötig, aber dafür muss man { und } mit \\{ und \\} escapen. Diese Eigenheiten sind wichtig, wenn man Regexes aus anderen Sprachen kopiert und einfügt.

Generell empfehle ich beim Schreiben einer neuen Regex, eine Website oder ein Tool mit diesen 3 Features zu verwenden:

1. Eine Option, einen Beispiel-String zum Abgleichen hinzuzufügen.

2. Ein Regex-Cheat-Sheet direkt auf dem Bildschirm zum Nachschlagen.

3. Ein Live-Matcher für die Regex, die du schreibst, basierend auf dem gegebenen Beispiel-String.

Die Seite, die ich dafür verwende, ist diese (sie läuft mit Ruby im Hintergrund):

Rubular

Wie kann ich Regexes heute schon in meinen Projekten nutzen?

Du musst nicht warten, bis sich eine gute Gelegenheit ergibt, Regexes einzusetzen – du kannst deine Projekte einfach mit regulären Ausdrücken linten (inklusive Autokorrektur-Unterstützung) über AnyLint:

github.comFlineDev / AnyLintLint anything by combining the power of scripts & regular expressions