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

Codex use case

Adopter Liquid Glass

Utilisez Codex pour migrer une application SwiftUI existante vers Liquid Glass à l’aide des API d’iOS 26 et de Xcode 26.

Difficulty Avancé
Time horizon 1 h

Utilisez Codex et le plugin Build iOS Apps pour auditer l’interface existante sur iPhone et iPad, remplacer les empilements personnalisés de flous ou de matériaux par des effets Liquid Glass natifs et sécuriser la migration grâce aux vérifications de disponibilité d’iOS 26 et à une validation sur simulateur.

Idéal pour

  • Applications SwiftUI existantes qui ont besoin d’un plan concret de migration vers Liquid Glass sous iOS 26, et non d’un vague cahier des charges de refonte
  • Équipes qui souhaitent que Codex audite les cartes personnalisées, les feuilles, les barres d’onglets, les barres d’outils et les boutons d’action, puis mette en œuvre la migration partie par partie
  • Applications qui prennent toujours en charge d’anciennes versions d’iOS et nécessitent des solutions de repli avec `#available(iOS 26, *)`, plutôt qu’une refonte visuelle à sens unique

Contents

    ← Tous les cas d’utilisation

    Adopter Liquid Glass

    Utilisez Codex pour migrer une application SwiftUI existante vers Liquid Glass à l’aide des API d’iOS 26 et de Xcode 26.

    Utilisez Codex et le plugin Build iOS Apps pour auditer l’interface existante sur iPhone et iPad, remplacer les empilements personnalisés de flous ou de matériaux par des effets Liquid Glass natifs et sécuriser la migration grâce aux vérifications de disponibilité d’iOS 26 et à une validation sur simulateur.

    Avancé
    1 h

    Utilisez Codex et le plugin Build iOS Apps pour auditer l’interface existante sur iPhone et iPad, remplacer les empilements personnalisés de flous ou de matériaux par des effets Liquid Glass natifs et sécuriser la migration grâce aux vérifications de disponibilité d’iOS 26 et à une validation sur simulateur.

    Avancé
    1 h

    Idéal pour

    • Applications SwiftUI existantes qui ont besoin d’un plan concret de migration vers Liquid Glass sous iOS 26, et non d’un vague cahier des charges de refonte
    • Équipes qui souhaitent que Codex audite les cartes personnalisées, les feuilles, les barres d’onglets, les barres d’outils et les boutons d’action, puis mette en œuvre la migration partie par partie
    • Applications qui prennent toujours en charge d’anciennes versions d’iOS et nécessitent des solutions de repli avec `#available(iOS 26, *)`, plutôt qu’une refonte visuelle à sens unique

    Skills et plugins

    • Utilisez les Skills dédiés à Liquid Glass dans SwiftUI, aux modèles d’interface SwiftUI et au débogage du simulateur pour moderniser les écrans iOS, adopter des effets Liquid Glass natifs et vérifier le résultat dans des simulateurs iOS 26.
    Skill Why use it
    Build iOS Apps Utilisez les Skills dédiés à Liquid Glass dans SwiftUI, aux modèles d’interface SwiftUI et au débogage du simulateur pour moderniser les écrans iOS, adopter des effets Liquid Glass natifs et vérifier le résultat dans des simulateurs iOS 26.

    Prompt de démarrage

    Utilisez le plugin Build iOS Apps et son Skill SwiftUI Liquid Glass pour migrer vers Liquid Glass un parcours très utilisé de cette application. Contraintes : - Considérez qu’il s’agit d’une migration vers iOS 26 + Xcode 26, mais conservez, avec `#available(iOS 26, *)`, une solution de repli sans Liquid Glass pour les cibles de déploiement antérieures. - Commencez par auditer le parcours. Indiquez les arrière-plans personnalisés, les empilements de flous, les pastilles, les boutons, les feuilles et les barres d’outils qui doivent adopter Liquid Glass natif, ainsi que les surfaces qui doivent rester du contenu simple, sans effet. - Préférez les contrôles système et les API natives comme `glassEffect`, `GlassEffectContainer`, `glassEffectID`, `.buttonStyle(.glass)` et `.buttonStyle(.glassProminent)` aux flous personnalisés. N’utilisez `glassEffectID` avec `@Namespace` que lorsqu’une véritable transition par morphing améliore le parcours. - Appliquez `glassEffect` après les modificateurs de mise en page et d’apparence, conservez des formes cohérentes et n’utilisez `.interactive()` que pour les contrôles qui réagissent réellement au toucher. - Utilisez XcodeBuildMCP pour compiler et exécuter l’application dans un simulateur iOS 26, prendre des captures d’écran du parcours migré et indiquer précisément le schéma, le simulateur et les vérifications utilisés. Livrables : - un plan concis de migration du parcours - la partie Liquid Glass mise en œuvre - le comportement de repli pour les appareils exécutant une version antérieure à iOS 26 - les étapes de validation dans le simulateur et les captures d’écran utilisées
    Utilisez le plugin Build iOS Apps et son Skill SwiftUI Liquid Glass pour migrer vers Liquid Glass un parcours très utilisé de cette application. Contraintes : - Considérez qu’il s’agit d’une migration vers iOS 26 + Xcode 26, mais conservez, avec `#available(iOS 26, *)`, une solution de repli sans Liquid Glass pour les cibles de déploiement antérieures. - Commencez par auditer le parcours. Indiquez les arrière-plans personnalisés, les empilements de flous, les pastilles, les boutons, les feuilles et les barres d’outils qui doivent adopter Liquid Glass natif, ainsi que les surfaces qui doivent rester du contenu simple, sans effet. - Préférez les contrôles système et les API natives comme `glassEffect`, `GlassEffectContainer`, `glassEffectID`, `.buttonStyle(.glass)` et `.buttonStyle(.glassProminent)` aux flous personnalisés. N’utilisez `glassEffectID` avec `@Namespace` que lorsqu’une véritable transition par morphing améliore le parcours. - Appliquez `glassEffect` après les modificateurs de mise en page et d’apparence, conservez des formes cohérentes et n’utilisez `.interactive()` que pour les contrôles qui réagissent réellement au toucher. - Utilisez XcodeBuildMCP pour compiler et exécuter l’application dans un simulateur iOS 26, prendre des captures d’écran du parcours migré et indiquer précisément le schéma, le simulateur et les vérifications utilisés. Livrables : - un plan concis de migration du parcours - la partie Liquid Glass mise en œuvre - le comportement de repli pour les appareils exécutant une version antérieure à iOS 26 - les étapes de validation dans le simulateur et les captures d’écran utilisées

    Prenez iOS 26 comme version de référence

    Considérez d’abord l’adoption de Liquid Glass comme un projet de migration vers iOS 26 et Xcode 26. Recompilez l’application avec le SDK d’iOS 26, examinez ce que les contrôles SwiftUI standard fournissent automatiquement, puis demandez à Codex de repenser uniquement les parties personnalisées qui paraissent encore trop plates, trop lourdes ou trop déconnectées de l’interface du système.

    Si l’application prend toujours en charge des versions antérieures d’iOS, explicitez cette contrainte dès le départ. Le Skill SwiftUI Liquid Glass du plugin Build iOS Apps doit utiliser #available(iOS 26, *) pour conditionner l’accès aux nouvelles API propres à Liquid Glass et conserver une solution de repli qui reste claire sur les appareils plus anciens.

    Tirez parti du plugin iOS

    Utilisez le plugin Build iOS Apps lorsque vous voulez que Codex associe des modifications de l’interface SwiftUI à une validation dans le simulateur. Pour une migration vers Liquid Glass, demandez à Codex d’auditer un parcours, de migrer un petit ensemble de surfaces, de lancer le résultat dans un simulateur iOS 26 et de prendre des captures d’écran avant d’élargir le périmètre.

    Ce plugin inclut un Skill SwiftUI Liquid Glass avec quelques choix par défaut utiles à reprendre dans votre prompt :

    • Privilégiez les API natives glassEffect et GlassEffectContainer, les styles de boutons Liquid Glass et les transitions glassEffectID, plutôt que les vues de flou personnalisées.
    • Appliquez .glassEffect(...) après les modificateurs de mise en page et d’apparence, afin que le matériau épouse la forme finale souhaitée.
    • Regroupez les éléments Liquid Glass associés dans GlassEffectContainer lorsque plusieurs surfaces apparaissent ensemble.
    • N’utilisez .interactive() que pour les boutons, les pastilles et les contrôles qui réagissent réellement au toucher.
    • Harmonisez la forme des coins, les teintes et les espacements dans toute la fonctionnalité au lieu de multiplier les traitements Liquid Glass ponctuels.
    • Conservez une solution de repli sans Liquid Glass pour les cibles de déploiement antérieures à iOS 26.

    Pour en savoir plus sur l’installation des Plugins et des Skills, consultez notre documentation consacrée aux Plugins et aux Skills.

    Regardez les sessions de la WWDC

    Ces sessions de la WWDC25 constituent un bon ensemble de références avant de demander à Codex de refactoriser un parcours réellement utilisé en production :

    Demandez d’abord un plan de migration, puis la migration d’une première partie

    Les migrations vers Liquid Glass se déroulent mieux lorsque Codex sépare la question « Où Liquid Glass doit-il apparaître ? » de la consigne « Écrivez tout le code maintenant. » Demandez d’abord un audit rapide, puis laissez l’agent mettre en œuvre une partie autonome avec une validation dans le simulateur.

    Conseils pratiques

    N’appliquez pas Liquid Glass partout

    Liquid Glass doit créer une couche de contrôles clairement distincte au-dessus du contenu, et non transformer chaque carte en panneau lumineux. Demandez à Codex de supprimer les arrière-plans décoratifs qui entrent en conflit avec les matériaux système, de conserver un contenu sans effet là où la lisibilité prime et de réserver les teintes à la mise en valeur sémantique ou aux actions principales.

    Commencez par un parcours très utilisé

    Pour une première migration, mieux vaut généralement choisir la racine d’un onglet, un écran de détail, une feuille, une interface de recherche ou un parcours de prise en main plutôt que toute l’application. Cela simplifie la révision et permet d’identifier clairement quels choix relatifs à Liquid Glass doivent être déclinés en modèles de composants réutilisables.

    Vérifiez soigneusement le comportement de repli

    Si votre cible de déploiement est antérieure à iOS 26, demandez à Codex d’afficher l’implémentation de repli à côté de l’implémentation Liquid Glass. Cette étape de révision permet de détecter toute régression involontaire dans la gestion de la disponibilité des API et d’éviter de livrer une migration qui ne fonctionne que dans le simulateur le plus récent.

    Tech stack

    Need

    API d’interface utilisateur Liquid Glass

    Default options

    SwiftUI avec glassEffect, GlassEffectContainer et les styles de boutons Liquid Glass

    Why it's needed

    Ce sont les API natives que le Skill doit privilégier, afin que Codex supprime les couches de flou personnalisées au lieu de réinventer le système de matériaux.

    Need

    Versions de référence de la plateforme

    Default options

    iOS 26 et Xcode 26

    Why it's needed

    Liquid Glass est disponible avec le SDK d’iOS 26. Codex doit compiler avec Xcode 26 et ajouter des solutions de repli explicites pour prendre en charge les versions antérieures du système d’exploitation.

    Need

    Validation dans le simulateur

    Default options

    XcodeBuildMCP

    Why it's needed

    La compilation, le lancement, la prise de captures d’écran et l’inspection des journaux sont essentiels lors d’une migration visuelle, en particulier pour examiner plusieurs états et formats d’appareil.

    Need Default options Why it's needed
    API d’interface utilisateur Liquid Glass SwiftUI avec glassEffect , GlassEffectContainer et les styles de boutons Liquid Glass Ce sont les API natives que le Skill doit privilégier, afin que Codex supprime les couches de flou personnalisées au lieu de réinventer le système de matériaux.
    Versions de référence de la plateforme iOS 26 et Xcode 26 Liquid Glass est disponible avec le SDK d’iOS 26. Codex doit compiler avec Xcode 26 et ajouter des solutions de repli explicites pour prendre en charge les versions antérieures du système d’exploitation.
    Validation dans le simulateur XcodeBuildMCP La compilation, le lancement, la prise de captures d’écran et l’inspection des journaux sont essentiels lors d’une migration visuelle, en particulier pour examiner plusieurs états et formats d’appareil.

    Cas d’utilisation associés