Beim Konfigurieren von Connection Pools in Vapor – ob für Redis, PostgreSQL oder andere Datenbanken – begegnet dir ein Parameter namens maximumActiveConnections. Die naheliegende Annahme ist, dass dieser die maximale Gesamtanzahl an Verbindungen für deine Anwendung festlegt. Tut er nicht. Er legt das Maximum pro NIO EventLoop fest.

Diese Unterscheidung ist in der Produktion enorm wichtig.

Die Rechnung, die mich überrascht hat

Auf einem typischen Server erstellt Swift NIO einen EventLoop pro CPU-Kern. Die tatsächliche maximale Verbindungsanzahl ist also:

actual max = maximumActiveConnections * CPU cores * number of dynos/instances

Ich hatte maximumActiveConnections auf 8 gesetzt, in der Annahme, dass ich meine Redis-Verbindungen auf vernünftige 16 über zwei Dynos begrenze. Die tatsächliche Zahl:

8 (per event loop) * 8 (cores) * 2 (dynos) = 128 potential connections

Das ist eine Größenordnung mehr als beabsichtigt, und es überschritt das Verbindungslimit meines Redis-Anbieters bei Traffic-Spitzen.

Die Symptome

Der Fehlermodus ist besonders tückisch: intermittierende 500-Fehler, die nur unter Last auftreten. Bei normalem Traffic erreichst du nie das echte Verbindungslimit, also funktioniert alles einwandfrei. Bei Spitzen häufen sich Verbindungen über alle Event Loops gleichzeitig an und überschreiten das Limit des Anbieters. Die Fehler wirken zufällig und sind lokal schwer zu reproduzieren, weil Entwicklungsmaschinen typischerweise weniger Kerne haben.

Den richtigen Wert berechnen

Teile das Verbindungslimit deines Anbieters durch die Gesamtzahl der Event Loops über alle Instanzen hinweg:

// Provider limit: 40 connections
// 2 dynos * 8 cores = 16 event loops total
// 40 / 16 = 2.5, round down to 2

app.redis.configuration = .init(
   pool: .init(maximumActiveConnections: 2)
)

Diese konservative Einstellung hat endlich die seit Langem bestehenden seltenen 500-Fehler in TranslateKit behoben, die mich monatelang verwirrt hatten. Überprüfe immer die Verbindungslimits deines Cloud-Anbieters und rechne die Multiplikation durch, bevor du deployst.

Es gibt einen weit verbreiteten Glauben in der Entwickler-Community, dass das Einreichen von Feedback Assistant-Berichten (dem Nachfolger von Radar) sinnlos ist – dass Berichte in einem Loch verschwinden und nie etwas passiert. Ich hatte einen Feature-Request, der in Xcode 26 implementiert wurde, was das Gegenteil beweist.

Zu sehen, wie ein Feature, das du angefragt hast, in einer Keynote oder Release Notes auftaucht, ist eine befriedigende Bestätigung. Aber noch wichtiger: Es zeigt, dass Apples Engineering-Teams Community-Feedback tatsächlich lesen und priorisieren, selbst wenn sie nie direkt auf den Bericht antworten.

Tipps zum Schreiben effektiven Feedbacks

Nicht alle Berichte sind gleich. Hier ist, was nach meiner Erfahrung die Chancen erhöht, dass ein Bericht bearbeitet wird:

Sei spezifisch mit dem Problem. „Xcode ist langsam” ist nicht hilfreich. „Xcodes SwiftUI Preview braucht 12 Sekunden zum Aktualisieren, wenn die Datei mehr als 3 #Preview-Blöcke enthält” gibt Ingenieuren etwas zum Untersuchen.

Lege ein Beispielprojekt bei. Ein minimales Reproduktionsprojekt ist das wertvollste, was du anhängen kannst. Wenn ein Ingenieur dein Projekt bauen und starten kann, um das Problem zu sehen, hast du die größte Hürde zur Untersuchung beseitigt.

Beschreibe den Anwendungsfall, nicht nur die Lösung. Anstatt „füge einen Button hinzu, der X macht”, erkläre, warum du es brauchst: „Beim Arbeiten mit großen SPM-Graphen muss ich schnell identifizieren, zu welchem Target eine Datei gehört, weil …” Das gibt dem Team Kontext, um die richtige Lösung zu entwickeln, die anders sein könnte als das, was du dir vorgestellt hast.

Reiche während der Beta-Saison ein. Die Wochen nach der WWDC sind die Zeit, in der Apples Teams am aktivsten Feedback zu neuen Features sammeln. Berichte, die in diesem Zeitraum eingereicht werden, bekommen deutlich mehr Aufmerksamkeit als solche, die mitten im Release-Zyklus eingereicht werden.

Mach es zur Gewohnheit

Nimm dir jede WWDC-Beta-Saison Zeit, deine Apps gegen die neuen OS- und Xcode-Betas zu testen. Reiche Berichte für jedes Problem und jedes fehlende Feature ein. Die meisten werden keine Antwort bekommen, aber einige werden stillschweigend zukünftige Releases beeinflussen.

Ein Pattern, das ich ständig in SwiftUI-Code sehe, ist das manuelle Erstellen von Icon-only Buttons, indem ein Image direkt in die Label-Closure eines Button gepackt wird. Es funktioniert visuell, wirft aber Barrierefreiheits-Informationen weg und arbeitet gegen das Design von SwiftUI.

Der falsche Weg

Button {
   toggleSidebar()
} label: {
   Image(systemName: "sidebar.left")
}

Das rendert ein tippbares Icon, aber VoiceOver hat kein aussagekräftiges Label zum Vorlesen. Der Nutzer hört etwas wie „button” oder den rohen SF Symbol-Namen, was nicht hilfreich ist.

Der richtige Weg

Button("Toggle Sidebar", systemImage: "sidebar.left") {
   toggleSidebar()
}
.labelStyle(.iconOnly)

Oder mit explizitem Label:

Button(action: toggleSidebar) {
   Label("Toggle Sidebar", systemImage: "sidebar.left")
}
.labelStyle(.iconOnly)

Warum das wichtig ist

Die Label-View trägt sowohl einen Titel als auch ein Icon. Wenn du .labelStyle(.iconOnly) anwendest, versteckt SwiftUI den Titel visuell, bewahrt ihn aber im Accessibility-Baum. VoiceOver liest „Toggle Sidebar, button” vor – genau das, was der Nutzer hören muss.

Dieses Pattern macht deinen Code auch anpassungsfähiger. Wenn du dich später entscheidest, Text neben dem Icon anzuzeigen (zum Beispiel in einer Toolbar auf dem iPad), änderst du einfach den Label-Style auf .titleAndIcon. Keine Umstrukturierung nötig.

Über Buttons hinaus

Dasselbe Prinzip gilt für jede View, die ein Label akzeptiert: NavigationLink, Toggle, Picker, Menüeinträge. Wann immer du versucht bist, ein nacktes Image zu verwenden, frag dich, ob ein Label mit einem Style-Modifier nicht passender wäre. In fast jedem Fall ist es das.

Wenn mehrere Personen an einem Swift Package mitwirken, schleichen sich Einrückungs-Inkonsistenzen ein. Ein Mitwirkender nutzt 4 Leerzeichen, ein anderer Tabs, ein dritter 2 Leerzeichen. Pull Requests werden durch reine Whitespace-Änderungen unübersichtlich, und die Codebasis driftet in ein inkonsistentes Durcheinander. Die Lösung ist eine einzelne Datei, die in 30 Sekunden hinzugefügt ist.

Der .editorconfig-Standard

EditorConfig ist ein weit verbreiteter Standard zur Definition von Coding-Style-Einstellungen pro Projekt. Xcode respektiert .editorconfig-Dateien, sodass Mitwirkende automatisch die korrekten Einrückungseinstellungen bekommen, wenn sie das Projekt öffnen – keine manuelle Konfiguration, keine Dokumentation zum Lesen.

Hier ist die .editorconfig, die ich für jedes SwiftPM Package empfehle:

root = true

[*.swift]
indent_style = space
indent_size = 3

[*.{yml,yaml,json}]
indent_style = space
indent_size = 2

Die 3-Leerzeichen-Einrückung für Swift ist eine bewusste Wahl. Sie ist weniger verbreitet als 2 oder 4 Leerzeichen, trifft aber einen Sweet Spot: besser lesbar als 2 Leerzeichen bei verschachtelten Closures, weniger Verschwendung von horizontalem Platz als 4 Leerzeichen. Wenn du es einmal ausprobierst, fühlen sich die Standard-Optionen entweder zu eng oder zu weit auseinander an.

Warum das globale Einstellungen übertrifft

Jeder Entwickler hat seine eigenen Xcode-Einrückungspräferenzen global konfiguriert. Ohne .editorconfig werden diese globalen Einstellungen auf jedes Projekt angewandt, das geöffnet wird. Das bedeutet, ein Mitwirkender mit 4-Leerzeichen-Tabs wird Code stillschweigend umformatieren, wenn er eine Datei bearbeitet, selbst wenn die Projektkonvention anders ist.

Mit .editorconfig im Repository-Root überschreibt Xcode die globalen Einstellungen mit den projektspezifischen. Mitwirkende müssen nichts ändern – es funktioniert einfach.

Einführung

Lege diese Datei in dein Package-Root und committe sie. Das ist alles. Es gibt keinen Build-Schritt, keine Abhängigkeit, keine Konfiguration über die Datei selbst hinaus. Die meisten modernen Editoren (VS Code, Vim, Sublime Text) unterstützen ebenfalls EditorConfig, sodass auch Nicht-Xcode-Mitwirkende profitieren.

Die App Store Connect iOS-App hat ein Feature, das die meisten Entwickler nie entdecken: Push-Benachrichtigungen für neue Nutzerbewertungen. Es ist standardmäßig deaktiviert, und du musst es für jede App separat aktivieren, was wahrscheinlich der Grund ist, warum so wenige Leute davon wissen.

So aktiviert man es

Öffne die App Store Connect App auf deinem iPhone und navigiere zu:

1. Tippe auf dein Profilbild oder gehe zu Settings

2. Wähle Notifications

3. Du siehst eine Liste aller deiner Apps

4. Aktiviere für jede App Customer Reviews

Das war’s. Ab jetzt bekommst du eine Push-Benachrichtigung, wann immer jemand eine neue Bewertung für diese App hinterlässt.

Warum das für Indie-Entwickler wichtig ist

Schnell auf App Store Reviews zu reagieren hat einen spürbaren Einfluss. Wenn ein Nutzer eine negative Bewertung über einen Bug hinterlässt, kann eine schnelle Antwort, die das Problem anerkennt (oder auf einen Fix hinweist), dazu führen, dass er seine Bewertung aktualisiert. Positive Bewertungen verdienen ebenfalls Anerkennung – das ermutigt Nutzer, weiterhin Feedback zu geben.

Ohne Benachrichtigungen schauen die meisten Entwickler nur dann nach Bewertungen, wenn sie daran denken, was Tage oder Wochen später sein kann. Bis dahin hat der Nutzer weitergemacht, und deine Antwort wirkt wie ein nachträglicher Einfall.

Ein Wort der Vorsicht

Wenn du mehrere Apps mit hohem Bewertungsvolumen hast, könnte das Aktivieren für alle davon laut werden. Fang mit deinen wichtigsten Apps an und passe es an, basierend darauf, wie viele Benachrichtigungen du tatsächlich bekommst. Für die meisten Indie-Entwickler mit einer Handvoll Apps ist das Volumen gut handhabbar und die Vorteile sind sofort spürbar.

Die meisten Entwickler wissen, dass DocC Standard-Markdown unterstützt, aber es gibt zwei mächtige Direktiven, die überraschend wenig genutzt werden: Video-Einbettung und Tab-Inhalte. Beide funktionieren in Xcodes Dokumentations-Viewer und auf gehosteten DocC-Websites.

Videos einbetten

Ein Video zur Dokumentation hinzuzufügen ist eine einzige Direktive:

@Video(source: "setup-walkthrough.mp4")

Platziere die Videodatei im Resources-Ordner deines Dokumentationskatalogs. Das rendert einen Inline-Videoplayer direkt in der Dokumentation, was weitaus effektiver ist als auf eine externe URL zu verlinken oder einen visuellen Prozess in Text zu beschreiben. Es funktioniert gut für Setup-Guides, UI-Walkthroughs oder das Demonstrieren von Animationen.

Tab-Inhalte mit TabNavigator

Wenn du alternative Ansätze oder plattformspezifische Anleitungen zeigen musst, halten Tabs die Dinge übersichtlich, ohne den Leser zu überfordern:

@TabNavigator {
   @Tab("SwiftUI") {
      Use the `.environment` modifier to inject dependencies.
   }
   @Tab("UIKit") {
      Override `viewDidLoad` and configure your dependencies there.
   }
}

Das rendert als echtes Tab-Interface, bei dem Leser zwischen Abschnitten wechseln können. Es ist besonders nützlich für Dokumentation, die mehrere Plattformen, API-Versionen oder Konfigurationsansätze abdeckt.

Praktische Hinweise

Ich habe meinen Contributing-Guide aktualisiert, um beide Features zu nutzen, und das Ergebnis ist deutlich zugänglicher als eine Textwand. Das Video zeigt den Setup-Prozess, der Absätze zum Beschreiben brauchen würde, und die Tabs trennen plattformspezifische Schritte sauber.

Diese Direktiven sind in Apples DocC-Dokumentation dokumentiert, werden aber selten in Tutorials erwähnt. Wenn du ein Open-Source Swift Package pflegst, überlege, sie deinem Dokumentationskatalog hinzuzufügen – sie machen einen echten Unterschied dabei, wie Leute deine Docs erleben.

Eine bezahlte App auf Freemium umzustellen ist eine gängige Geschäftsentscheidung, bringt aber eine Fairness-Herausforderung mit sich: Nutzer, die bereits für die App bezahlt haben, sollten nicht plötzlich Features verlieren oder erneut zur Kasse gebeten werden. StoreKits AppTransaction API löst das sauber.

AppTransaction zur Überprüfung der Kaufhistorie verwenden

Der Schlüssel ist AppTransaction.shared, das Informationen über die ursprüngliche Transaktion deiner App liefert. Genauer gesagt sagt dir originalAppVersion, welche Version der App der Nutzer ursprünglich heruntergeladen hat. Wenn diese Version eine bezahlte Version war, weißt du, dass der Nutzer bereits bezahlt hat.

import StoreKit

func shouldGrantFullAccess() async -> Bool {
   do {
      let result = try await AppTransaction.shared
      if case .verified(let transaction) = result {
         let originalVersion = transaction.originalAppVersion
         // Version "2.0" was when the app went freemium
         if originalVersion.compare("2.0", options: .numeric) == .orderedAscending {
            return true // User purchased before freemium transition
         }
      }
   } catch {
      // Handle verification failure
   }
   return false
}

Die Logik ist unkompliziert: Vergleiche die originalAppVersion des Nutzers mit der Version, bei der du den Freemium-Wechsel vorgenommen hast. Wenn die ursprüngliche Version vor der Änderung liegt, gewähre automatisch vollen Zugriff.

Wichtige Details

Die originalAppVersion entspricht dem CFBundleShortVersionString-Wert zum Zeitpunkt des ursprünglichen Kaufs (oder Downloads bei kostenlosen Apps). Stelle sicher, dass du genau weißt, welche Versionsnummer deinen Übergangspunkt markiert.

Dieser Ansatz erfordert keine Server-Infrastruktur und keinen Migrationscode. StoreKit übernimmt die Verifizierung über die App Store Receipt Chain, sodass die Prüfung manipulationssicher ist. Apple dokumentiert dieses Muster in der Original-API für Geschäftsmodell-Migration.

Für TestFlight- und Simulator-Tests gibt originalAppVersion stattdessen die CFBundleVersion (Build-Nummer) zurück, plane deine Testfälle also entsprechend.

Jahrelang war mein Workflow zum Nachschlagen von Dokumentation in Xcode derselbe: Cmd-Klick auf ein Symbol, „Show Quick Help” aus dem Kontextmenü wählen, das Popup lesen, dann schließen und weitercodieren. Es funktioniert, aber es unterbricht – jede Suche erfordert drei Aktionen und bricht deinen Arbeitsfluss.

Dann habe ich zufällig das Quick Help Inspector-Panel in der rechten Sidebar entdeckt.

So funktioniert es

Öffne den Quick Help Inspector mit Option+Cmd+3 oder gehe zu View > Inspectors > Quick Help. Das öffnet ein Panel in der rechten Sidebar, das Dokumentation für das Symbol anzeigt, auf dem sich dein Cursor gerade befindet. Wenn du deinen Cursor durch den Code bewegst – auf eine Methode klickst, durch Parameter navigierst, einen Typ auswählst – aktualisiert sich die Sidebar automatisch.

Kein Klicken, kein Popup zum Schließen, keine Unterbrechung. Du codierst einfach weiter und die relevante Dokumentation folgt dir.

Warum es Cmd-Klick übertrifft

Der Cmd-Klick-Ansatz hat einen bestimmten Nachteil: Er erfordert, dass du entscheidest „Ich brauche Docs dafür”, bevor du nachschaust. Die Sidebar kehrt das um. Weil sie immer sichtbar ist, nimmst du Dokumentation passiv auf. Du bemerkst Parameterbeschreibungen, Rückgabetypen, Deprecation-Warnungen und Verfügbarkeitsannotationen, ohne bewusst danach suchen zu müssen.

Das ist besonders wertvoll beim Arbeiten mit unbekannten APIs. Anstatt bei jedem zweiten Symbol Cmd zu klicken, bewegst du einfach deinen Cursor durch den Code und liest die Sidebar nebenbei. Es verwandelt das Nachschlagen von Dokumentation von einer einzelnen Aktion in einen kontinuierlichen Strom.

Das Panel zeigt denselben Inhalt wie das Quick Help-Popup: Deklaration, Beschreibung, Parameter, Rückgabewert, Verfügbarkeit und verwandte Symbole. Der einzige Unterschied ist, dass es bestehen bleibt und sich an Ort und Stelle aktualisiert, anstatt zu erscheinen und zu verschwinden.

Wenn du den Platz für die rechte Sidebar hast, ist das Offenhalten von Quick Help beim Codieren eine dieser kleinen Workflow-Änderungen, die sich über die Zeit summieren.

Standard-SwiftUI-Button-Aktionen sind synchron. Wenn du eine asynchrone Operation durchführen musst – eine Netzwerkanfrage, einen Datenbankschreibvorgang, einen StoreKit-Kauf – musst du manuell einen Task verwalten, den Ladezustand tracken, den Button deaktivieren und Fehler behandeln. Dieses Boilerplate wiederholt sich bei jedem asynchronen Button in deiner App.

Ich habe eine AsyncButton-Komponente gebaut, die all das in eine einzige wiederverwendbare View verpackt.

Eine vereinfachte Implementierung

Hier ist die Kernidee:

struct AsyncButton<Label: View>: View {
   let action: () async throws -> Void
   let label: () -> Label

   @State private var isRunning = false
   @State private var result: Result<Void, Error>?

   var body: some View {
      Button {
         isRunning = true
         Task {
            do {
               try await action()
               result = .success(())
            } catch {
               result = .failure(error)
            }
            isRunning = false
         }
      } label: {
         HStack(spacing: 8) {
            label()
            if isRunning {
               ProgressView()
            }
         }
      }
      .disabled(isRunning)
   }
}

Der Button erstellt intern einen Task, sodass Aufrufer await direkt in der Action-Closure verwenden können. Während der Task läuft, erscheint ein ProgressView neben dem Label und der Button wird deaktiviert, um doppelte Absendungen zu verhindern. Der result-State kann Erfolgs- oder Fehlerindikatoren steuern – ein Häkchen, einen Farbblitz oder eine Schüttelanimation.

Verwendung

Die Verwendung fühlt sich natürlich an:

AsyncButton {
   try await viewModel.submitOrder()
} label: {
   Text("Place Order")
}

Kein manuelles State-Management, keine Task-Erstellung an der Aufrufstelle. Die vollständige Implementierung in HandySwiftUI fügt konfigurierbare Erfolgs-/Fehleranimationen, anpassbare Fortschrittsanzeigen und Unterstützung für Button-Styles hinzu. Aber das Kernmuster oben deckt den häufigsten Fall ab und lässt sich unkompliziert an deine eigenen Projekte anpassen.

SwiftUI’s ImageRenderer ermöglicht es dir, jede SwiftUI View in ein UIImage oder CGImage zu rendern. Es funktioniert gut für reine SwiftUI Views, versagt aber stillschweigend – erzeugt ein leeres oder unvollständiges Bild – wenn der View-Baum Komponenten enthält, die von UIKit oder AppKit unterstützt werden. Das betrifft mehrere häufig verwendete Views:

• List (umhüllt UITableView / NSTableView)

• ScrollView (umhüllt UIScrollView / NSScrollView)

• TextEditor (umhüllt UITextView / NSTextView)

• Map (umhüllt MKMapView)

Es gibt weder eine Compiler-Warnung noch einen Runtime-Fehler. Der Renderer erfasst diese Teile der View-Hierarchie einfach nicht.

Der Workaround

Als ich ein listenähnliches Layout als Bild exportieren musste, bestand die Lösung darin, List durch ein reines SwiftUI-Äquivalent aus VStack und manueller Stilisierung zu ersetzen:

let exportView = VStack(spacing: 0) {
   ForEach(items) { item in
      HStack {
         Text(item.name)
         Spacer()
         Text(item.value)
            .foregroundStyle(.secondary)
      }
      .padding(.horizontal, 16)
      .padding(.vertical, 12)

      if item.id != items.last?.id {
         Divider()
      }
   }
}
.background(.white)
.frame(width: 390)

let renderer = ImageRenderer(content: exportView)
renderer.scale = UIScreen.main.scale

if let image = renderer.uiImage {
   // Use the rendered image
}

Der VStack mit ForEach repliziert die visuelle Struktur einer List, ohne auf UIKit-gestützte Views angewiesen zu sein. Das Hinzufügen von Dividers, Padding und einem Hintergrund erzeugt ein Ergebnis, das für Exportzwecke einer Standard-Liste nahe genug kommt.

Praktischer Ratschlag

Wenn du vorhast, ImageRenderer in deiner App zu verwenden, designe deine exportierbaren Views mit dieser Einschränkung von Anfang an im Hinterkopf. Baue sie aus grundlegenden SwiftUI-Primitiven: Stacks, Text, Shapes und Images. Vermeide jede View, von der du weißt, dass sie ein plattformspezifisches Control umhüllt. Das Render-Ergebnis frühzeitig zu testen erspart die Frustration, später leere Bereiche zu entdecken.

In jedem Swift-Projekt mittlerer Größe hast du am Anfang fast jeder Datei denselben Satz an Imports. Foundation, SwiftUI, OSLog, vielleicht Observation – die Liste wächst, wenn du neue Frameworks übernimmst. Mit dem Wechsel zu strukturiertem Logging via OSLog habe ich festgestellt, dass ich import OSLog in fast jeder Datei neben den üblichen Verdächtigen hinzufüge.

Die Lösung ist ein Wrapper-Modul, das alles, was du häufig brauchst, über einen einzigen Import re-exportiert.

Das Wrapper-Modul einrichten

Erstelle ein neues Target in deinem Swift Package oder Xcode-Projekt. In meinem Fall habe ich es AppFoundation genannt. Das gesamte Modul besteht aus einer einzigen Datei:

// Sources/AppFoundation/Exports.swift
@_exported import Foundation
@_exported import SwiftUI
@_exported import OSLog
@_exported import Observation

Das @_exported-Attribut macht alle öffentlichen Symbole jedes Frameworks für jede Datei verfügbar, die AppFoundation importiert. Jetzt braucht jede Datei in deiner App nur noch:

import AppFoundation

In deiner Package.swift hat das Target keinen eigenen Quellcode über die Exports-Datei hinaus. Dein App-Target deklariert eine Abhängigkeit von AppFoundation, und alle re-exportierten Frameworks werden überall verfügbar.

Zu berücksichtigende Kompromisse

Dieser Ansatz hat klare Vorteile: weniger Boilerplate, weniger Merge-Konflikte in Import-Abschnitten und eine zentrale Stelle, um neue Framework-Imports hinzuzufügen. Aber es gibt Kompromisse.

Erstens ist @_exported ein unterstrichenes Attribut, was bedeutet, dass es nicht offiziell Teil der stabilen Swift-API ist. In der Praxis ist es seit Jahren stabil und wird im Ökosystem weit verbreitet verwendet, aber es gibt keine formale Garantie.

Zweitens können implizite Abhängigkeiten es schwerer machen zu verstehen, was eine Datei tatsächlich nutzt. Wenn jede Datei Zugriff auf alles hat, verlierst du den Dokumentationswert expliziter Imports. Wenn du später ein Modul in ein eigenständiges Package extrahierst, musst du die expliziten Imports wieder hinzufügen.

Für App-Targets, bei denen Bequemlichkeit wichtiger ist als strikte Modularität, spart das Wrapper-Modul-Pattern echte Zeit. Für wiederverwendbare Bibliotheken bleiben explizite Imports die bessere Wahl.

In UIKit ist Navigation imperativ. Du sagst dem System genau, was es tun soll:

let detailVC = DetailViewController()
detailVC.item = selectedItem
navigationController?.pushViewController(detailVC, animated: true)

Du erstellst einen View Controller, konfigurierst ihn und pushst ihn auf den Stack. Du hast die Kontrolle über die Aktion.

SwiftUI funktioniert anders. Du navigierst nicht – du präsentierst Daten in neuen Views. Alles ist datengetrieben. Du kontrollierst keine Views. Du kontrollierst Daten.

Datengetriebene Navigation in der Praxis

Mit NavigationStack wird Navigation durch State gesteuert. Du deklarierst, welche Daten welcher View zugeordnet werden, und SwiftUI kümmert sich um die Übergänge:

struct ContentView: View {
   @State private var path: [Item] = []

   var body: some View {
      NavigationStack(path: $path) {
         List(items) { item in
            Button(item.name) {
               path.append(item)  // Modify data, not views
            }
         }
         .navigationDestination(for: Item.self) { item in
            DetailView(item: item)
         }
      }
   }
}

Die Schlüsselzeile ist path.append(item). Du pushst keine View. Du fügst Daten zu einem Array hinzu. SwiftUI beobachtet die Änderung und präsentiert die entsprechende View automatisch.

Warum das wichtig ist

Diese Unterscheidung ist nicht nur philosophisch – sie hat praktische Konsequenzen. Weil Navigation State ist, bekommst du Deep Linking geschenkt, indem du das richtige Path-Array konstruierst. Du kannst den Navigationszustand persistieren und wiederherstellen, indem du den Pfad speicherst. Du kannst programmatisch zu jeder Tiefe navigieren, indem du mehrere Elemente auf einmal hinzufügst.

Es bedeutet auch, dass das Schließen einfach das Entfernen von Daten ist. path.removeLast() aufzurufen poppt die oberste View. Das Array zu leeren kehrt zum Root zurück. Kein Bedarf, View-Controller-Referenzen zu tracken oder die Navigationshierarchie zu durchlaufen.

Der Umstieg braucht Zeit zur Verinnerlichung, besonders wenn du jahrelange UIKit-Erfahrung hast. Aber sobald es Klick macht, wird SwiftUI-Navigation deutlich vorhersagbarer. Deine Views werden zu reinen Funktionen deiner Daten, und Navigation ist einfach ein weiteres Stück dieser Daten.

SwiftUI’s AsyncImage ist praktisch zum Laden von Remote-Bildern, hat aber eine überraschende Einschränkung: Du kannst den .resizable()-Modifier nicht darauf anwenden. Dieser Code kompiliert, verhält sich aber nicht wie erwartet:

// This does NOT work as intended
AsyncImage(url: imageURL)
   .resizable()  // Has no effect -- AsyncImage is not an Image
   .aspectRatio(contentMode: .fill)
   .frame(width: 200, height: 200)

Der Grund ist, dass AsyncImage kein Image ist – es ist eine Container-View, die den Ladezustand verwaltet. Der .resizable()-Modifier ist nur auf Image definiert, sodass die Anwendung auf AsyncImage nur die generische View-Version aufruft, die nichts Nützliches tut.

Die Lösung

Die Lösung ist die Verwendung des phasenbasierten Initializers, der dir direkten Zugriff auf den zugrunde liegenden Image-Wert gibt, sobald das Laden abgeschlossen ist:

AsyncImage(url: imageURL) { phase in
   switch phase {
   case .success(let image):
      image
         .resizable()
         .aspectRatio(contentMode: .fill)
   case .failure:
      Image(systemName: "photo")
         .foregroundStyle(.secondary)
   case .empty:
      ProgressView()
   @unknown default:
      EmptyView()
   }
}
.frame(width: 200, height: 200)
.clipped()

Innerhalb des .success-Falls ist image ein echter Image-Wert, sodass .resizable() korrekt funktioniert. Das gibt dir auch Kontrolle über die Lade- und Fehlerzustände, was ohnehin die bessere Praxis ist.

Wann man manuell lädt

Wenn du die rohen Bilddaten brauchst – zum Beispiel um sie zu cachen, ihre Größe zu prüfen oder ein UIImage zu erstellen – möchtest du AsyncImage vielleicht ganz überspringen und mit URLSession laden. Aber für die meisten reinen Anzeigefälle deckt der phasenbasierte Initializer den Bedarf ohne zusätzliche Komplexität.

Das ist eine dieser SwiftUI-APIs, bei denen der einfache Initializer verlockend aussieht, aber in der Praxis zu kurz greift. Verwende standardmäßig die phasenbasierte Version, wann immer du bildspezifische Modifier brauchst.

Xcode 15 hat ein kleines, aber wirkungsvolles Tastenkürzel eingeführt: Ctrl+M. Setze deinen Cursor auf einen Funktionsaufruf, Initializer oder eine beliebige kommagetrennte Parameterliste, drücke Ctrl+M, und Xcode verteilt es automatisch auf mehrere Zeilen – ein Parameter pro Zeile, korrekt eingerückt.

Vor diesem Tastenkürzel bedeutete das Umformatieren eines langen Funktionsaufrufs manuelles Hinzufügen von Zeilenumbrüchen und Korrigieren der Einrückung. Betrachte einen Aufruf wie diesen:

let label = UILabel(frame: .zero, font: .systemFont(ofSize: 14), textColor: .label, numberOfLines: 0)

Nach dem Drücken von Ctrl+M mit dem Cursor auf dieser Zeile formatiert Xcode es um zu:

let label = UILabel(
   frame: .zero,
   font: .systemFont(ofSize: 14),
   textColor: .label,
   numberOfLines: 0
)

Wann man es verwendet

Dieses Tastenkürzel ist am wertvollsten, wenn du SwiftUI View Modifier oder Initializer schreibst, die im Laufe der Zeit Parameter ansammeln. Eine View, die mit zwei Parametern beginnt, wächst oft auf fünf oder sechs, wenn du Konfiguration hinzufügst. Anstatt jedes Mal manuell umzuformatieren, erledigt Ctrl+M das mit einem einzigen Tastendruck.

Es funktioniert auch umgekehrt – wenn deine Parameter bereits auf separaten Zeilen stehen, faltet Ctrl+M sie zurück in eine einzelne Zeile. Dieses Umschaltverhalten macht es einfach, je nach Lesbarkeitsbedarf zwischen kompaktem und erweitertem Format zu wechseln.

Ein Hinweis: Das Tastenkürzel arbeitet mit der innersten Parameterliste an der Cursorposition. Wenn du verschachtelte Funktionsaufrufe hast, positioniere deinen Cursor sorgfältig, um den richtigen zu erweitern.

Die meisten Xcode-Nutzer kennen Shift+Cmd+O – das „Open Quickly”-Tastenkürzel, mit dem du zu jeder Datei, jedem Symbol oder Typ in deinem Projekt springen kannst. Es ist eines dieser Tastenkürzel, das innerhalb von Tagen zur zweiten Natur wird. Was ich bis vor Kurzem nicht wusste: dasselbe Tastenkürzel funktioniert jetzt auch auf der Apple Developer Documentation Website, angetrieben von DocC.

Wenn du auf developer.apple.com/documentation surfst, öffnet Shift+Cmd+O ein Such-Overlay, das sich genau wie Xcodes Open Quickly-Dialog verhält. Du kannst einen Framework-Namen, eine Klasse, eine Methode oder sogar eine Teilübereinstimmung eingeben, und Ergebnisse erscheinen sofort. Durch Auswahl eines Ergebnisses navigierst du direkt zu dieser Dokumentationsseite.

Warum das wichtig ist

Vor diesem Feature bedeutete das Durchsuchen von Apples Dokumentation, durch die Sidebar-Hierarchie zu scrollen oder die allgemeine Suchleiste zu verwenden, die oft eine Mischung aus Artikeln, Tutorials und API-Referenzen lieferte. Das Open Quickly-Overlay filtert Ergebnisse auf API-Symbole und Seiten, was es deutlich präziser macht.

Das ist besonders nützlich, wenn du im Browser einen WWDC-Artikel oder Forum-Thread liest und schnell die Signatur einer verwandten API nachschlagen musst. Anstatt zurück zu Xcode zu wechseln, bleibst du im Kontext und schlägst es direkt nach.

Das Feature ist Teil von Apples breiterer Investition in DocC als Dokumentationsplattform. Da DocC sowohl Xcodes Dokumentations-Viewer als auch die webbasierte Dokumentation antreibt, ist es sinnvoll, dass dieselben Interaktionsmuster übernommen werden. Wenn du viel Zeit mit dem Lesen von Apple-Dokumentation im Browser verbringst, lohnt es sich, dieses Tastenkürzel in dein Muskelgedächtnis aufzunehmen.

Eine der stilleren, aber wirkungsvollen Änderungen in Xcode 15 ist der eingebaute typsichere Zugriff auf Asset Catalogs. Zuvor erforderte das Referenzieren eines Bildes oder einer Farbe aus dem Asset Catalog ein String-Literal:

// Before Xcode 15
Image("custom-header-icon")
Color("primaryBrand")

Das war fragil. Benenne ein Asset um und dein Code kompiliert einwandfrei, stürzt aber zur Laufzeit ab oder zeigt nichts an. Tools wie SwiftGen existierten speziell dafür, dieses Problem zu lösen, indem sie typsichere Konstanten aus deinen Asset Catalogs generierten.

Was sich geändert hat

Xcode 15 generiert jetzt automatisch Swift-Accessoren für jedes Bild und jede Farbe in deinem Asset Catalog. Du greifst über die Resource-Initializer darauf zu:

// Xcode 15+
Image(.customHeaderIcon)
Color(.primaryBrand)

Der Compiler kennt deine Assets. Du bekommst volle Autovervollständigung, und wenn du ein Asset löschst oder umbenennst, erhältst du einen Compile-Time-Fehler statt eines stillen Runtime-Fehlers.

Apple hat SwiftGen sherlocked

Das ist im Grunde Apple, das integriert, was SwiftGen seit Jahren bietet. Für Teams, die bereits SwiftGen verwenden, ist jetzt ein guter Zeitpunkt, zu evaluieren, ob es noch benötigt wird. Die eingebaute Lösung deckt die zwei häufigsten Anwendungsfälle ab – Bilder und Farben – ohne Build-Phase-Scripts oder Code-Generierungsschritte.

Es gibt weiterhin Gründe, SwiftGen zu behalten, wenn du es für Fonts, lokalisierte Strings oder andere Ressourcentypen nutzt. Aber für Asset Catalogs im Speziellen ist die native Lösung jetzt für die meisten Projekte gut genug und funktioniert sofort ohne Konfiguration.

Die Arbeit mit .strings- und .stringsdict-Dateien war schon immer eine der raueren Kanten der Apple-Entwicklung. Einfache Textdateien mit Schlüssel-Wert-Paaren sind fehleranfällig – fehlende Semikolons, nicht übereinstimmende Schlüssel zwischen Sprachen, keine Möglichkeit, den Übersetzungsfortschritt auf einen Blick zu sehen. Und .stringsdict-Dateien, die für Pluralisierungsregeln verwendet werden, sind XML-basierte Plist-Dateien, die bekanntermaßen schwierig von Hand zu erstellen sind.

Was String Catalogs mitbringen

Xcode 15 führt ein neues .xcstrings-Dateiformat namens String Catalogs ein. Es ersetzt sowohl .strings als auch .stringsdict durch eine einzige Datei, die mit einem eigenen visuellen Editor kommt.

Die wichtigsten Verbesserungen sind erheblich:

Visueller Editor – Alle lokalisierbaren Strings werden in einer Tabelle mit Spalten für jede Sprache angezeigt. Du kannst Übersetzungen inline sehen und bearbeiten, ohne zwischen Dateien zu wechseln oder externe Tools zu verwenden.

Übersetzungsfortschrittsverfolgung – Jede Sprache zeigt einen Fertigstellungsprozentsatz. Auf einen Blick kannst du erkennen, welche Sprachen Aufmerksamkeit brauchen und welche Strings noch unübersetzt sind.

Automatische String-Extraktion – Xcode durchsucht deinen Swift-Code und entdeckt automatisch Strings, die lokalisiert werden müssen. Neue Strings erscheinen im Katalog ohne manuellen Registrierungsschritt.

Eingebaute Migration – Es gibt einen Migrationspfad von bestehenden .strings- und .stringsdict-Dateien. Rechtsklicke auf deine vorhandenen Lokalisierungsdateien und Xcode bietet an, sie ins neue Format zu konvertieren.

Praktische Auswirkungen

Für Projekte mit auch nur einer Handvoll unterstützter Sprachen ist das eine erhebliche Verbesserung der Lebensqualität. Der visuelle Editor allein eliminiert eine ganze Klasse von Formatierungsfehlern. Kombiniert mit der automatischen Extraktion bedeutet es weniger vergessene Strings und ein klareres Bild deines Lokalisierungsstatus im gesamten Projekt.

Wenn du ein neues Projekt mit Xcode 15 startest, sind String Catalogs der Standard. Für bestehende Projekte ist die Migration unkompliziert und lohnt sich auf jeden Fall.

Lange Funktionsaufrufe und -deklarationen mit vielen Parametern sind eines der häufigsten Lesbarkeitsprobleme in Swift-Code. Man endet mit Zeilen, die weit über jede vernünftige Spaltengrenze hinausgehen:

func configureView(title: String, subtitle: String, icon: Image, backgroundColor: Color, isEnabled: Bool, action: @escaping () -> Void) {

Das manuell in mehrere Zeilen umzubrechen ist mühsam. Du musst den Cursor positionieren, Zeilenumbrüche einfügen, jeden Parameter einrücken und sicherstellen, dass die schließende Klammer korrekt ausgerichtet ist.

Die neue Aktion in Xcode 15

Xcode 15 führt eine „Format to Multiple Lines”-Aktion ein, die das automatisch erledigt. Setze deinen Cursor auf einen Funktionsaufruf oder eine Deklaration mit mehreren Parametern, und Xcode bietet an, es umzuformatieren:

Das Ergebnis ist sauber formatiert mit einem Parameter pro Zeile:

func configureView(
   title: String,
   subtitle: String,
   icon: Image,
   backgroundColor: Color,
   isEnabled: Bool,
   action: @escaping () -> Void
) {

Du findest diese Aktion per Rechtsklick auf die Funktionssignatur unter Refactor oder über das Editor-Menü. Es funktioniert sowohl bei Funktionsdeklarationen als auch bei Aufrufstellen.

Wann man es einsetzt

Das ist am nützlichsten direkt nach dem Schreiben einer neuen Funktion oder dem Hinzufügen von Parametern zu einer bestehenden. Anstatt beim Schreiben manuell zu formatieren, kannst du alles in eine Zeile schreiben und dann den Formatierer in einer einzigen Aktion anwenden. Es hilft auch beim Code-Review, wenn jemand anderes lange einzeilige Signaturen hinterlassen hat – markieren und umformatieren ohne manuelles Editieren.

Die umgekehrte Operation (mehrere Zeilen zurück in eine zusammenfalten) ist derzeit nicht verfügbar, aber diese Richtung wird seltener benötigt.

Beim Erstellen von Views, die von asynchronen Daten abhängen, hast du typischerweise einen Ladezustand, der einen Spinner oder Platzhalter anzeigt. In der Produktion erscheint dieser Zustand kurz, während Daten aus dem Netzwerk oder der Datenbank geladen werden. Aber in SwiftUI Previews sind deine Mock-Daten sofort verfügbar, sodass der Ladezustand zu schnell vorbeihuscht, um ihn zu begutachten – oder gar nicht erst erscheint.

Ein rein auf Previews beschränkter Delay-Helper

Die Lösung ist ein kleiner Helper, der eine künstliche Verzögerung einführt, aber nur im Preview- oder Debug-Kontext. Hier ist das Muster:

struct DelayedStatePreview<Content: View>: View {
   @State private var isLoaded = false
   let delay: Duration
   let content: (Bool) -> Content

   init(
      delay: Duration = .seconds(2),
      @ViewBuilder content: @escaping (Bool) -> Content
   ) {
      self.delay = delay
      self.content = content
   }

   var body: some View {
      content(isLoaded)
         .task {
            try? await Task.sleep(for: delay)
            isLoaded = true
         }
   }
}

Du verwendest es in einem Preview so:

#Preview {
   DelayedStatePreview { isLoaded in
      if isLoaded {
         ArticleListView(articles: mockArticles)
      } else {
         LoadingView()
      }
   }
}

Warum das wichtig ist

Der entscheidende Vorteil ist, dass dein Produktionscode sauber bleibt. Du fügst keine künstlichen Verzögerungen oder Debug-Flags zu deinen eigentlichen Views hinzu. Der Helper existiert rein auf der Preview-Ebene und gibt dir die Möglichkeit, visuell zu überprüfen, ob deine Ladezustände korrekt aussehen, ob Übergänge flüssig animieren und ob das Layout nicht springt, wenn Daten ankommen.

Das ist besonders nützlich für Views mit Skeleton-Loadern oder Shimmer-Effekten, bei denen die visuelle Qualität des Ladezustands Teil der User Experience ist.

Wenn du jemals eine Verzögerung bemerkt hast – manchmal mehrere Sekunden – zwischen dem Drücken von Run in Xcode und dem tatsächlichen Erscheinen deiner App, ist der Übeltäter oft der LLDB-Debugger, der sich an deinen Prozess anhängt. Während dieser Zeit zeigt der Simulator einen leeren Bildschirm, während der Debugger initialisiert wird.

Wo die Einstellung zu finden ist

Die Einstellung befindet sich in deiner Scheme-Konfiguration:

1. Gehe zu Product > Scheme > Edit Scheme (oder drücke Cmd+Shift+<)

2. Wähle links die Run-Aktion aus

3. Wechsle zum Info-Tab

4. Deaktiviere Debug executable

Was das bewirkt

Wenn „Debug executable” aktiviert ist (der Standard), hängt Xcode den LLDB-Debugger beim Start an deinen App-Prozess an. Das ist es, was Breakpoints, den Debug Memory Graph, den View Hierarchy Debugger und po-Befehle in der Konsole ermöglicht.

Das Deaktivieren überspringt das Anhängen des Debuggers komplett. Deine App startet merklich schneller – meiner Erfahrung nach kann der Unterschied bei größeren Projekten 2 bis 5 Sekunden betragen. Konsolenausgaben über print() und os_log funktionieren weiterhin normal, sodass du Logging fürs Debugging weiter nutzen kannst.

Der Kompromiss

Ohne angehängten Debugger verlierst du:

• Breakpoints (sie werden nicht ausgelöst)

• po- und expression-Befehle in der Konsole

• Memory Graph und View Hierarchy Debugging-Tools

Das macht die Einstellung ideal für UI-Iterationsarbeit, wenn du visuelle Anpassungen machst und häufig neu startest. Wenn du einen bestimmten Bug mit Breakpoints untersuchen musst, aktiviere das Kontrollkästchen einfach vorübergehend wieder. Ich lasse es die meiste Zeit deaktiviert und schalte es nur ein, wenn ich Code Schritt für Schritt durchgehen muss.

Swifts #warning-Direktive erzeugt eine Compiler-Warnung mit einer benutzerdefinierten Nachricht. Anders als Kommentare tauchen diese im Issue Navigator und in der Build-Ausgabe auf, sodass man sie unmöglich übersehen kann. Ich verwende sie als harte Erinnerungen für Dinge, die vor dem Release unbedingt erledigt werden müssen.

Zwei Snippets, die ich täglich nutze

Ich habe zwei Xcode Code Snippets für diesen Zweck eingerichtet.

“nyi” – Not Yet Implemented:

#warning("Not yet implemented!")

Ich tippe nyi und drücke Enter, wann immer ich eine Funktion auslagere oder beim Prototyping einen Codepfad überspringe. Es kompiliert problemlos, aber die Warnung stellt sicher, dass ich zurückkomme, um die Arbeit zu beenden.

“dw” – Developer Warning:

#warning("<#message#>")

Dieses Snippet verwendet ein Platzhalter-Token, sodass nach dem Tippen von dw und Drücken von Enter der Cursor in der Nachricht landet und ich eine individuelle Notiz eingeben kann. Ich verwende das für Dinge wie #warning("Handle error case for offline mode") oder #warning("Remove before release").

So erstellt man Xcode Snippets

Das Einrichten dauert jeweils etwa 30 Sekunden:

1. Tippe den gewünschten Code als Snippet in eine beliebige Swift-Datei

2. Markiere den Code

3. Rechtsklick und Create Code Snippet wählen

4. Gib ihm einen Titel (z.B. „Developer Warning”)

5. Setze die Completion-Abkürzung (z.B. dw)

6. Setze Availability auf „All” oder „Swift”

7. Klicke auf Done

Von da an bietet das Tippen der Abkürzung in jeder Swift-Datei das Snippet über die Autovervollständigung an.

Der entscheidende Vorteil gegenüber reinen Kommentaren ist die Sichtbarkeit. Ein // TODO:-Kommentar lässt sich leicht ignorieren und ist schwer konsistent zu finden. Ein #warning zwingt den Compiler, es bei jedem einzelnen Build anzuzeigen, und hält deine unfertige Arbeit im Vordergrund, bis du sie erledigst.

Swift Evolution Proposals sind von Natur aus ausführlich. Sie behandeln Motivation, detailliertes Design, betrachtete Alternativen, ABI-Auswirkungen und mehr. Diese Gründlichkeit ist für den Review-Prozess unverzichtbar, aber wenn du nur verstehen willst, was ein Proposal macht und warum, kann das Durchlesen von tausenden Wörtern ganz schön viel sein.

Der URL-Trick

Es gibt eine einfache Möglichkeit, eine zusammengefasste Version jedes Swift Evolution Proposals auf GitHub zu bekommen. Wenn du ein Proposal unter einer URL wie dieser betrachtest:

https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

Ersetze apple durch FlineDev:

https://github.com/FlineDev/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

Das führt dich zu einem Fork des swift-evolution Repository, in dem Proposals um KI-generierte Zusammenfassungen am Anfang ergänzt wurden. Jede Zusammenfassung destilliert die wichtigsten Punkte – was das Proposal einführt, warum es wichtig ist und die grundlegende Syntax – in wenige Absätze.

Wann das hilfreich ist

Das ist besonders nützlich, wenn du ein Proposal in Release Notes oder in sozialen Medien erwähnt siehst und schnell den Kern verstehen willst. Anstatt 15 Minuten mit dem vollständigen Proposal zu verbringen, bekommst du die wesentlichen Informationen in ein paar Minuten.

Die Zusammenfassungen decken die meisten kürzlich akzeptierten Proposals ab. Für ältere Proposals, die vor dem Fork erstellt wurden, siehst du weiterhin den Originaltext. Aber für alles aus den letzten Jahren der Swift Evolution ist die zusammengefasste Version ein echter Zeitsparer.

Ich habe diesen Fork erstellt, weil ich mich immer wieder dabei ertappt habe, Proposals nur nach der Kernidee zu durchsuchen, und dachte, dass andere Entwickler von der gleichen Abkürzung profitieren könnten.

Beim Erstellen eines Onboarding-Flows besteht eine Herausforderung darin, die Aufmerksamkeit des Nutzers auf die nächste Aktion zu lenken. Eine dezente pulsierende Animation auf Buttons zieht den Blick an, ohne aufdringlich zu sein. Ich habe das in SwiftUI mit einer Kombination aus scaleEffect- und opacity-Modifiern umgesetzt, die an eine sich wiederholende Animation gekoppelt sind.

Hier ist der grundlegende Ansatz:

struct PulsatingButtonStyle: ButtonStyle {
   @State private var isPulsating = false

   func makeBody(configuration: Configuration) -> some View {
      configuration.label
         .scaleEffect(isPulsating ? 1.06 : 1.0)
         .opacity(isPulsating ? 0.8 : 1.0)
         .animation(
            .easeInOut(duration: 0.8)
               .repeatForever(autoreverses: true),
            value: isPulsating
         )
         .onAppear {
            isPulsating = true
         }
   }
}

Der Trick besteht darin, zwei Animationen – Skalierung und Transparenz – zu kombinieren, die synchron laufen. Der repeatForever(autoreverses: true)-Modifier lässt die Animation kontinuierlich hin und her schwingen. Durch das Umschalten von isPulsating beim Erscheinen startet die Animation sofort, wenn die View angezeigt wird.

Der Skalierungsfaktor von 1.06 ist bewusst dezent gewählt. Ein deutlich höherer Wert (wie 1.2) lässt die Animation aggressiv und ablenkend wirken. Die leichte Transparenzänderung verleiht dem Puls Tiefe, ohne den Button schwer lesbar zu machen.

Dieses Muster eignet sich gut für Onboarding-Screens, auf denen du einen „Weiter”- oder „Los geht’s”-Button hervorheben möchtest. Sobald der Nutzer das Onboarding hinter sich hat, wird die Animation nicht mehr angezeigt, sodass sie mit der Zeit nicht nervt.

Du kannst sie auf jeden Button mit .buttonStyle(PulsatingButtonStyle()) anwenden und hältst die Animationslogik sauber von deinem Button-Inhalt getrennt.