For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation

Vorschläge
API Dashboard
ChatGPT ausprobieren
Codex

Codex use case

SwiftUI-Screens refaktorieren

Teile mit Codex einen übergroßen SwiftUI-Screen in kleine Unteransichten auf, ohne Verhalten oder Layout zu ändern.

Difficulty Fortgeschritten
Time horizon 1 h

Nutze Codex und das Build iOS Apps-Plug-in, um eine lange SwiftUI-View in eigene Abschnittsansichten aufzuteilen, Nebeneffekte aus body auszulagern, die Zustandsverwaltung und die Nutzung von Observation zu stabilisieren und die Refaktorierung nach dem MV-Prinzip auszurichten, statt unnötige View Models einzuführen.

Am besten geeignet für

  • Sehr große SwiftUI-Dateien, in denen `body` Layout, Verzweigungen, asynchrone Vorgänge und Inline-Aktionen in einem einzigen schwer zu überprüfenden Screen vermischt
  • Bestehende iOS-Funktionen, die visuell und im Verhalten identisch bleiben sollen, während die interne Struktur leichter zu pflegen wird
  • Screens, bei denen berechnete Fragmente, die `some View` zurückgeben, optionale View Models oder aufwendige Zustandsweitergabe durch explizite Eingaben und Callbacks für Unteransichten vereinfacht werden sollen

Contents

    ← Alle Anwendungsfälle

    SwiftUI-Screens refaktorieren

    Teile mit Codex einen übergroßen SwiftUI-Screen in kleine Unteransichten auf, ohne Verhalten oder Layout zu ändern.

    Nutze Codex und das Build iOS Apps-Plug-in, um eine lange SwiftUI-View in eigene Abschnittsansichten aufzuteilen, Nebeneffekte aus body auszulagern, die Zustandsverwaltung und die Nutzung von Observation zu stabilisieren und die Refaktorierung nach dem MV-Prinzip auszurichten, statt unnötige View Models einzuführen.

    Fortgeschritten
    1 h

    Nutze Codex und das Build iOS Apps-Plug-in, um eine lange SwiftUI-View in eigene Abschnittsansichten aufzuteilen, Nebeneffekte aus body auszulagern, die Zustandsverwaltung und die Nutzung von Observation zu stabilisieren und die Refaktorierung nach dem MV-Prinzip auszurichten, statt unnötige View Models einzuführen.

    Fortgeschritten
    1 h

    Weiterführende Links

    Build iOS Apps-Plug-in Agenten-Skills

    Am besten geeignet für

    • Sehr große SwiftUI-Dateien, in denen `body` Layout, Verzweigungen, asynchrone Vorgänge und Inline-Aktionen in einem einzigen schwer zu überprüfenden Screen vermischt
    • Bestehende iOS-Funktionen, die visuell und im Verhalten identisch bleiben sollen, während die interne Struktur leichter zu pflegen wird
    • Screens, bei denen berechnete Fragmente, die `some View` zurückgeben, optionale View Models oder aufwendige Zustandsweitergabe durch explizite Eingaben und Callbacks für Unteransichten vereinfacht werden sollen

    Skills und Plug-ins

    • Build iOS Apps
      Nutze den Skill zur Refaktorierung von SwiftUI-Views, um eigene Unteransichten zu extrahieren, einen stabilen Datenfluss zu bewahren, die Nutzung von Observation zu vereinfachen und das Verhalten unverändert zu lassen, während Codex große SwiftUI-Screens bearbeitet.
    Skill Why use it
    Build iOS Apps Nutze den Skill zur Refaktorierung von SwiftUI-Views, um eigene Unteransichten zu extrahieren, einen stabilen Datenfluss zu bewahren, die Nutzung von Observation zu vereinfachen und das Verhalten unverändert zu lassen, während Codex große SwiftUI-Screens bearbeitet.

    Einstiegs-Prompt

    Setze das Plug-in Build iOS Apps und dessen Skill zur Refaktorierung von Ansichten in SwiftUI ein, um [NameOfScreen.swift] aufzuräumen, ohne die Funktionsweise oder das Aussehen des Screens zu verändern. Vorgaben: - Bewahre Verhalten, Layout, Navigation und Geschäftslogik, es sei denn, du findest einen Fehler, den du separat benennen musst. - Setze standardmäßig auf MV statt auf MVVM. Nutze zunächst `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)` und `onChange`, bevor du ein neues View Model einführst. Behalte ein View Model nur bei, wenn diese Funktion eindeutig eines benötigt. - Ordne die View so, dass gespeicherte Eigenschaften, berechneter Zustand, `init`, `body`, View-Hilfsfunktionen und Hilfsmethoden von oben nach unten leicht zu erfassen sind. - Extrahiere aussagekräftige Abschnitte als eigene Typen, die `View` implementieren und mit wenigen expliziten Eingaben, `@Binding`s und Callbacks auskommen. Ersetze nicht einen einzigen riesigen `body` durch viele große berechnete Eigenschaften, die `some View` zurückgeben. - Verschiebe nicht triviale Button-Aktionen und Nebeneffekte aus `body` in kleine Methoden und echte Geschäftslogik in Services oder Modelle. - Halte die oberste Ebene des View-Baums stabil. Vermeide Verzweigungen mit `if/else` auf oberster Ebene, die völlig unterschiedliche Screens austauschen, wenn bedingte Abschnitte oder Modifier an der jeweiligen Stelle ausreichen. - Sorge beim Refaktorieren für korrekte Besitzverhältnisse in Observation: Speichere unter iOS 17+ Modelle mit `@Observable` auf oberster Ebene mithilfe von `@State` und vermeide optionale oder verzögert initialisierte View Models, sofern die UI diese Zustandsstruktur nicht wirklich benötigt. - Führe nach jeder Extraktion die kleinste sinnvolle Build- oder Testprüfung aus, die belegt, dass sich der Screen weiterhin gleich verhält. Liefere: - den refaktorierten Screen und alle extrahierten Unteransichten - eine kurze Erläuterung der neuen Aufteilung in Unteransichten und des Datenflusses - alle Stellen, an denen du bewusst ein View Model beibehalten hast, sowie die jeweilige Begründung - die ausgeführten Validierungsprüfungen, mit denen du belegt hast, dass das Verhalten unverändert geblieben ist
    Setze das Plug-in Build iOS Apps und dessen Skill zur Refaktorierung von Ansichten in SwiftUI ein, um [NameOfScreen.swift] aufzuräumen, ohne die Funktionsweise oder das Aussehen des Screens zu verändern. Vorgaben: - Bewahre Verhalten, Layout, Navigation und Geschäftslogik, es sei denn, du findest einen Fehler, den du separat benennen musst. - Setze standardmäßig auf MV statt auf MVVM. Nutze zunächst `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)` und `onChange`, bevor du ein neues View Model einführst. Behalte ein View Model nur bei, wenn diese Funktion eindeutig eines benötigt. - Ordne die View so, dass gespeicherte Eigenschaften, berechneter Zustand, `init`, `body`, View-Hilfsfunktionen und Hilfsmethoden von oben nach unten leicht zu erfassen sind. - Extrahiere aussagekräftige Abschnitte als eigene Typen, die `View` implementieren und mit wenigen expliziten Eingaben, `@Binding`s und Callbacks auskommen. Ersetze nicht einen einzigen riesigen `body` durch viele große berechnete Eigenschaften, die `some View` zurückgeben. - Verschiebe nicht triviale Button-Aktionen und Nebeneffekte aus `body` in kleine Methoden und echte Geschäftslogik in Services oder Modelle. - Halte die oberste Ebene des View-Baums stabil. Vermeide Verzweigungen mit `if/else` auf oberster Ebene, die völlig unterschiedliche Screens austauschen, wenn bedingte Abschnitte oder Modifier an der jeweiligen Stelle ausreichen. - Sorge beim Refaktorieren für korrekte Besitzverhältnisse in Observation: Speichere unter iOS 17+ Modelle mit `@Observable` auf oberster Ebene mithilfe von `@State` und vermeide optionale oder verzögert initialisierte View Models, sofern die UI diese Zustandsstruktur nicht wirklich benötigt. - Führe nach jeder Extraktion die kleinste sinnvolle Build- oder Testprüfung aus, die belegt, dass sich der Screen weiterhin gleich verhält. Liefere: - den refaktorierten Screen und alle extrahierten Unteransichten - eine kurze Erläuterung der neuen Aufteilung in Unteransichten und des Datenflusses - alle Stellen, an denen du bewusst ein View Model beibehalten hast, sowie die jeweilige Begründung - die ausgeführten Validierungsprüfungen, mit denen du belegt hast, dass das Verhalten unverändert geblieben ist

    Einen Screen refaktorieren, ohne sein Verhalten zu ändern

    Dieser Anwendungsfall ist für Situationen gedacht, in denen eine SwiftUI-Datei zu einem einzigen riesigen Screen angewachsen ist und jede kleine Änderung riskant erscheint. Ziel ist weder, die Funktion neu zu gestalten, noch eine neue Architektur zu erfinden. Bitte Codex, Verhalten und Layout beizubehalten und den Screen anschließend in kleine Unteransichten mit explizitem Datenfluss aufzuteilen. So lässt sich die nächste Änderung leichter überprüfen.

    Nutze das Build iOS Apps-Plug-in für diese Art der Bereinigung. Sein Skill zur Refaktorierung von SwiftUI-Views verfolgt einen klaren, nützlichen Ansatz: Setze standardmäßig auf MV statt auf MVVM, belasse die Geschäftslogik in Services oder Modellen, nutze zuerst lokalen View-Zustand und Umgebungsabhängigkeiten und behalte ein View Model nur bei, wenn die Funktion eindeutig eines benötigt.

    Was Codex tun soll

    Nenne zuerst eine konkrete Screen-Datei und bitte Codex, das Verhalten beizubehalten und zugleich die Struktur zu verbessern. Diese Regeln für die Refaktorierung solltest du direkt in deinen Prompt aufnehmen:

    • Ordne die Datei so, dass Umgebungsabhängigkeiten, gespeicherte Eigenschaften, berechnete Zustandswerte, die keine Views erzeugen, init, body, View-Hilfsfunktionen und Hilfsmethoden von oben nach unten leicht zu erfassen sind.
    • Extrahiere aussagekräftige Abschnitte in eigene Typen, die View implementieren und mit wenigen expliziten Eingaben, @Bindings und Callbacks auskommen.
    • Verwende berechnete Hilfsfunktionen, die some View zurückgeben, nur selten und halte sie klein. Baue einen riesigen Screen nicht als lange Liste privater berechneter View-Fragmente neu auf.
    • Verschiebe nicht triviale Button-Aktionen und Nebeneffekte aus body in kleine Methoden und echte Geschäftslogik in Services oder Modelle.
    • Halte den View-Baum auf oberster Ebene stabil. Bevorzuge lokale Bedingungen in Abschnitten oder Modifiern gegenüber Verzweigungen mit if/else auf oberster Ebene, die ganze Screens austauschen.
    • Sorge dabei auch in Observation für korrekte Besitzverhältnisse. Bei Modellen mit @Observable auf oberster Ebene sollte die verantwortliche View sie unter iOS 17+ mithilfe von @State speichern; ältere Observable-Wrapper solltest du nur verwenden, wenn dein Deployment-Target dies erfordert.

    Bitte Codex um einen kurzen Validierungszyklus

    Verhaltenserhaltende Refaktorierungen sollten belegt werden. Bitte Codex, nach jeder sinnvollen Extraktion die kleinste sinnvolle Prüfung per Build, Vorschau, Test oder Simulator auszuführen, die den Screen abdeckt. Lass Codex anschließend zusammenfassen, was sich strukturell geändert hat und was bewusst unverändert geblieben ist.

    Praktische Tipps

    Erst aufteilen, dann die Architektur diskutieren

    Wenn ein Screen zu groß ist, bitte Codex zunächst, Abschnittsansichten zu extrahieren, bevor du eine neue Abstraktionsebene einführst. Ein kürzerer, expliziterer View-Baum macht ein View Model oft vollständig überflüssig.

    Halte die Schnittstelle jeder Unteransicht so klein wie möglich

    Bevorzuge mit let deklarierte Werte, @Bindings und Callbacks für genau einen Zweck, statt jeder untergeordneten View das gesamte übergeordnete Modell zu übergeben. So kannst du jeden extrahierten Abschnitt leichter in der Vorschau darstellen und koppelst ihn nicht so leicht versehentlich wieder an den gesamten Screen.

    Lass Codex ausdrücklich nennen, was unverändert bleibt

    Für eine risikoarme Refaktorierung ist es hilfreich, wenn Codex ausdrücklich aufführt, was nicht geändert wurde: Geschäftsregeln, Navigationsverhalten, Persistenz, Analytics-Semantik und das für Nutzende sichtbare Layout. Das beschleunigt die Review deutlich.

    Tech stack

    Need

    UI-Architektur

    Default options

    SwiftUI mit MV als Ausgangspunkt und einer Aufteilung auf @State, @Environment sowie kleine, dedizierte Typen, die View implementieren

    Why it's needed

    Große Screens lassen sich in der Regel leichter pflegen, wenn Codex zuerst den View-Baum und den Zustandsfluss vereinfacht, bevor eine weitere Ebene mit einem View Model hinzukommt.

    Need

    Ablauf der Refaktorierung

    Default options

    Build iOS Apps-Plug-in

    Why it's needed

    Der Skill des Plug-ins zur Refaktorierung von SwiftUI-Views gibt Codex klare Regeln für das Extrahieren, Observation und die Bereinigung von Nebeneffekten vor, ohne das Verhalten zu ändern.

    Need

    Validierung

    Default options

    xcodebuild, Vorschauen und gezielte UI-Prüfungen

    Why it's needed

    Kleine Build- oder Simulatorprüfungen nach jeder Extraktion schaffen mehr Vertrauen in eine verhaltenserhaltende Refaktorierung als eine komplette Neufassung in einem einzigen Schritt.

    Need Default options Why it's needed
    UI-Architektur SwiftUI mit MV als Ausgangspunkt und einer Aufteilung auf @State , @Environment sowie kleine, dedizierte Typen, die View implementieren Große Screens lassen sich in der Regel leichter pflegen, wenn Codex zuerst den View-Baum und den Zustandsfluss vereinfacht, bevor eine weitere Ebene mit einem View Model hinzukommt.
    Ablauf der Refaktorierung Build iOS Apps-Plug-in Der Skill des Plug-ins zur Refaktorierung von SwiftUI-Views gibt Codex klare Regeln für das Extrahieren, Observation und die Bereinigung von Nebeneffekten vor, ohne das Verhalten zu ändern.
    Validierung xcodebuild , Vorschauen und gezielte UI-Prüfungen Kleine Build- oder Simulatorprüfungen nach jeder Extraktion schaffen mehr Vertrauen in eine verhaltenserhaltende Refaktorierung als eine komplette Neufassung in einem einzigen Schritt.

    Verwandte Anwendungsfälle

    App Intents zu einer iOS-App hinzufügen

    Nutze Codex und das Plug-in „Build iOS Apps“, um zu ermitteln, welche Aktionen und Entitäten...

    iOS Code

    Liquid Glass einführen

    Nutze Codex und das Plug-in Build iOS Apps, um bestehende Benutzeroberflächen für iPhone und...

    iOS Code

    Für iOS entwickeln

    Nutze Codex, um iOS-SwiftUI-Projekte aufzusetzen, die Build-Schleife mit `xcodebuild` oder...

    iOS Code