Structurez l’application et sa boucle de compilation

Pour créer une application Mac, demandez d’abord à Codex de choisir le modèle de scène adapté parmi WindowGroup, Window, Settings, MenuBarExtra ou DocumentGroup. L’application suit ainsi les conventions du Mac dès la première version, sans avoir à partir d’une ContentView conçue sur le modèle d’iOS.

Pilotez la compilation et le lancement depuis le shell. Pour les projets Xcode, utilisez xcodebuild. Pour les applications structurées autour d’un package Swift, utilisez swift build et un script script/build_and_run.sh propre au projet. Ce script arrête le processus précédent, compile l’application et lance la nouvelle version. Il peut aussi donner accès aux journaux ou aux données de télémétrie.

Si une application gérée entièrement avec SwiftPM possède une interface graphique, créez un bundle .app et lancez-le au lieu d’exécuter directement le binaire. Vous éviterez ainsi les problèmes d’affichage dans le Dock, d’activation de l’application et d’identité du bundle lors des vérifications locales.

Utilisez les skills

Ajoutez le plugin Build macOS Apps dès que vous abordez des fonctionnalités propres au Mac. Il couvre la compilation et le débogage depuis le shell, la création de bundles d’application avec SwiftPM, les modèles de scènes et de fenêtres natifs de SwiftUI, l’interopérabilité avec AppKit, la journalisation unifiée, le diagnostic des échecs de tests ainsi que les workflows de signature et de notarisation.

Pour savoir comment installer et utiliser les plugins et les skills, consultez la documentation sur les plugins et la documentation sur les skills.

Créez une interface native pour Mac

Privilégiez les conventions du Mac par rapport aux modes de navigation d’iOS. Utilisez NavigationSplitView pour associer une barre latérale à une vue de détail, des scènes Settings explicites pour les préférences, des barres d’outils et des commandes pour rendre les actions faciles à trouver, et des éléments dans la barre des menus pour les petits utilitaires qui doivent rester accessibles à tout moment.

Utilisez en priorité les matériaux système, les couleurs sémantiques et les contrôles standard. N’ajoutez des styles de fenêtre personnalisés, des zones permettant de déplacer la fenêtre ou des surfaces Liquid Glass que si le produit nécessite une interface de bureau qui lui est propre.

Si SwiftUI couvre l’essentiel de vos besoins, limitez le recours à AppKit au comportement manquant. AppKit peut par exemple gérer les panneaux d’ouverture et d’enregistrement, le choix du premier répondant, la validation des commandes de menu ou certains cas particuliers du glisser-déposer. Vous pouvez aussi encapsuler une NSView pour intégrer un contrôle spécialisé.

Déboguez, testez et préparez la distribution

Pour observer le comportement de l’application à l’exécution, demandez à Codex d’ajouter quelques événements Logger lors de l’ouverture d’une fenêtre, d’un changement de sélection dans la barre latérale, de l’exécution d’une commande de menu ou d’une synchronisation en arrière-plan. Vérifiez ensuite ces événements avec log stream après le lancement de l’application.

Si des tests échouent, demandez à Codex d’exécuter d’abord le plus petit ensemble de tests pertinent avec xcodebuild test ou swift test, puis de déterminer la cause de l’échec : erreur de compilation, échec d’une assertion, plantage, test instable ou problème d’environnement ou de configuration.

Lorsque vous passez du développement local à la distribution, demandez à Codex de préparer deux procédures : l’une pour créer manuellement une archive dans Xcode, l’autre pour automatiser par script l’archivage et la notarisation à chaque livraison. Demandez-lui d’inspecter le bundle de l’application, les droits qui lui sont accordés et la configuration de la protection renforcée à l’exécution avec codesign et plutil. Si vous souhaitez également téléverser les versions depuis le terminal, utilisez App Store Connect CLI.

Exemple de prompt

Conseils pratiques

Définissez chaque scène explicitement

Définissez des racines de scène distinctes pour la fenêtre principale, la fenêtre des réglages, les fenêtres utilitaires et les éléments de la barre des menus. Évitez de regrouper toute l’application dans une seule grande vue.

Appuyez-vous sur les éléments d’interface du système

Avant de créer des barres latérales, des barres d’outils ou des matériaux personnalisés, vérifiez si les API standard de SwiftUI pour les scènes et les fenêtres offrent déjà le comportement recherché sur Mac.

Réservez AppKit aux besoins ciblés

Pour ajouter une fonctionnalité de bureau qui manque à SwiftUI, utilisez NSViewRepresentable, NSViewControllerRepresentable ou un utilitaire NSWindow dédié à cette fonctionnalité. Gardez SwiftUI comme source de vérité pour la sélection et l’état de l’application.

Vérifiez la signature et la notarisation indépendamment de la compilation locale

Un lancement local réussi ne garantit ni que l’application est signée ni qu’elle est prête pour la notarisation. Conservez une procédure d’archivage manuel dans Xcode pour les vérifications ponctuelles avant publication. Automatisez par script l’archivage et la notarisation pour pouvoir répéter la procédure de distribution, et lancez les vérifications avec codesign et plutil dès que vous préparez une livraison au-delà des essais locaux.