Les notes de version d’Apple pour Xcode 27.2 bêta signalent un cas précis où le dossier JIT des prévisualisations appartient à un autre compte utilisateur. Cette mention concerne cette erreur particulière : elle ne permet pas d’attribuer toute panne de SwiftUI Preview aux permissions.
Symptôme : Canvas vide, mise à jour en erreur ou prévisualisation qui plante.
Premier geste : relevez la première erreur utile dans Preview Diagnostics, puis comparez avec une vue minimale, une compilation ordinaire et la cible de prévisualisation. Ne supprimez pas tous les caches et ne réinstallez pas Xcode d’emblée.
Cet article s’adresse à vous si vous développez une app SwiftUI sur un Mac distant et que Xcode Canvas reste vide ou échoue à se mettre à jour.
Il vous aide aussi si le projet compile normalement, mais que Preview ne démarre pas, ou si plusieurs personnes partagent le même environnement macOS.
SECTION 01Les symptômes de SwiftUI Preview sur Mac distant
Avant de modifier le projet, classez le symptôme. « Preview ne fonctionne pas » peut désigner plusieurs étapes différentes : le Canvas n’est pas ouvert, l’aperçu est en pause, sa mise à jour échoue, le lancement reste bloqué ou le processus se ferme après le démarrage.
Dans Xcode, vérifiez d’abord si le Canvas est visible et si l’aperçu est actif. Consultez ensuite les erreurs affichées dans l’éditeur, l’Issue navigator et Preview Diagnostics. Les informations de diagnostic permettent de relier le message affiché au code, à la cible ou à l’environnement concernés. Apple décrit les contrôles et interactions disponibles dans la documentation sur les prévisualisations dans le Canvas.
Une compilation ordinaire qui réussit ne prouve pas que toute la chaîne Preview fonctionne. La prévisualisation doit, elle aussi, retrouver le bon fichier, résoudre ses dépendances, construire la cible attendue et démarrer dans le contexte d’exécution sélectionné. Traitez donc séparément la compilation du projet et l’exécution de l’aperçu.
Pour éviter une fausse piste, notez le premier message pertinent et ce que vous faisiez juste avant son apparition. Une série d’erreurs secondaires peut suivre un seul échec initial ; c’est la première erreur exploitable, et non la dernière ligne du journal, qui oriente le mieux la recherche.
SECTION 02Pourquoi le Canvas reste-t-il vide alors que le projet compile ?
Si le projet compile mais que le Canvas n’affiche rien, commencez par vérifier le fichier ouvert et le code Preview associé. Une vue peut dépendre d’initialiseurs, d’objets de modèle ou de données d’exemple que la prévisualisation ne fournit pas. Une vue d’ensemble correcte dans l’application n’est pas nécessairement instanciable sans préparation dans le contexte de Preview.
Créez un témoin minimal dans le projet : une vue SwiftUI qui ne dépend ni de services externes ni de données propres à l’application, avec une déclaration #Preview. Si cette vue s’affiche, le mécanisme de prévisualisation fonctionne au moins pour ce cas ; recherchez alors une différence dans la vue d’origine, ses paramètres, ses ressources ou ses dépendances. Si le témoin échoue lui aussi, examinez plutôt la cible, le runtime, l’état de Xcode ou la session distante.
Apple présente la syntaxe et les conditions d’ajout des prévisualisations dans la documentation consacrée à #Preview. Vérifiez que le fichier concerné est bien ouvert dans l’éditeur, que la déclaration est reconnue et que ses paramètres d’initialisation sont disponibles. Si l’aperçu repose sur des données de démonstration, construisez une instance locale simple plutôt que d’exiger dès le lancement une connexion à un service de développement.
Un scénario fréquent concerne une vue de tableau de bord qui charge des images, des sons ou des séquences vidéo depuis un service de l’application. La compilation peut réussir tandis que l’aperçu attend un compte, un fichier inaccessible ou un chargement réseau. Pour isoler ce cas, remplacez temporairement la dépendance par des données locales déterministes. Si l’aperçu démarre alors, vous avez localisé un problème de configuration ou de données, pas un défaut général de Canvas.
Quand faut-il suspecter la vue plutôt que l’environnement ?
Comparez le comportement de la vue réelle avec celui du témoin minimal, sans changer simultanément de cible ni de runtime. Si le témoin s’affiche et que la vue réelle échoue, réduisez progressivement les éléments propres à cette vue : initialiseur, modèle, chargement de ressources, service injecté, puis sous-vues. Cette réduction conserve une relation claire entre le changement et le résultat.
Si aucune prévisualisation ne s’affiche dans le projet, testez le témoin avec la même cible et le même compte macOS. Passer immédiatement à un autre environnement pourrait masquer un problème de permissions, de dépendances ou de session sans en identifier la cause.
SECTION 03Comment isoler un échec de cible, de runtime ou de dépendance ?
Vérifiez que le schéma sélectionné correspond au produit que vous prévisualisez, que la plateforme est celle attendue et que le runtime associé est installé. Une cible correcte avec un environnement de simulation indisponible ne fournit pas à Preview ce dont il a besoin pour démarrer. De même, une prévisualisation configurée pour une plateforme différente de celle du fichier peut échouer alors que la compilation d’une autre cible réussit.
Croisez les résultats sans confondre les opérations : lancez une compilation ordinaire pour le schéma concerné, puis réessayez Preview avec une cible et un runtime cohérents. Si vous envisagez de modifier la destination de déploiement, vérifiez auparavant l’effet sur les autres configurations du projet. Les réglages correspondants et leur portée sont détaillés dans la référence des réglages de compilation Xcode. Une modification destinée à débloquer un aperçu ne doit pas être appliquée globalement sans vérifier ses conséquences pour les builds de développement et de publication.
Si Preview Diagnostics désigne un module absent, un produit de dépendance introuvable ou un objet qui ne peut pas être chargé, remontez à la première cible qui échoue. Contrôlez que le produit est bien associé à la cible concernée et que son chemin de construction est accessible au compte qui exécute Xcode. Ne concluez pas que DerivedData est corrompu simplement parce que plusieurs messages d’erreur mentionnent des fichiers produits.
Un nettoyage ciblé peut être justifié si le diagnostic identifie un artefact incohérent et que vous avez d’abord noté le message d’origine. Un effacement général, en revanche, peut supprimer des indices et déclencher de nouvelles compilations sans corriger une cible incorrecte, une dépendance absente ou un runtime indisponible.
Quels indices permettent de distinguer Preview, Simulator et appareil ?
Le Canvas Preview sert à afficher et interagir avec une représentation de l’interface dans Xcode. Le Simulator exécute l’application dans un environnement simulé, tandis qu’un appareil physique reste nécessaire pour examiner certains comportements liés au matériel ou à l’usage réel. Apple décrit séparément le lancement sur un appareil simulé ou physique.
Un échec de Preview n’établit donc pas que Simulator est en panne, et un Simulator fonctionnel ne démontre pas que la prévisualisation d’une vue isolée est correctement configurée. Si Simulator ne démarre pas non plus, vérifiez son runtime et sa destination séparément. Si seul Preview échoue, conservez ce résultat comme indice en faveur d’un problème propre à la création ou à l’exécution de l’aperçu.
Les discussions d’Apple Developer Forums peuvent aider à reconnaître un message déjà rencontré, mais un cas rapporté par un développeur ne suffit pas à établir une cause générale. Servez-vous de cette discussion sur les outils de développement comme piste à confronter aux diagnostics de votre projet, et non comme preuve qu’une panne identique a nécessairement la même origine.
SECTION 04Comment traiter un échec JIT ou un problème de compte ?
Sur un Mac distant partagé, vérifiez quel compte macOS exécute Xcode, quel compte possède le projet et si les répertoires de construction sont accessibles à l’utilisateur actif. Une session graphique et une commande lancée sous un autre utilisateur peuvent produire des résultats différents. Notez également si le problème apparaît uniquement après un changement de compte ou de session.
Lorsque Preview Diagnostics mentionne JIT, un chargement impossible ou une erreur de signature, suivez le premier composant en échec. Vérifiez la cible, le produit de dépendance et le contexte d’accès aux fichiers avant de modifier les permissions. Évitez notamment d’appliquer une modification globale à des répertoires système ou de construction sans avoir confirmé leur propriétaire et la portée requise.
La note de version d’Apple pour Xcode 27.2 bêta indique une amélioration du message d’erreur dans le cas où le dossier JIT de Previews appartient à un autre compte. Cette information vaut pour le cas décrit dans les notes officielles de cette version bêta ; elle ne confirme pas que toute panne liée à JIT, ni tout échec observé sur une autre version, vient d’une propriété de dossier incorrecte. Vérifiez les notes correspondant à la version installée avant de transposer ce diagnostic.
Pour départager un souci de session et un souci de projet, comparez le même témoin minimal dans une session propre, sans déplacer les fichiers ni modifier les permissions en même temps. Si le témoin échoue uniquement pour un compte, examinez l’accès au projet, aux produits construits et aux répertoires utilisés par la session. Si plusieurs comptes obtiennent le même échec sur la même cible, poursuivez plutôt l’inspection des dépendances, de la configuration et du runtime.
Quelle branche de dépannage suivre ?
Choisissez une branche selon ce que vous pouvez confirmer, et évitez de cumuler des réparations avant d’avoir identifié le niveau de panne.
- Si le Canvas est masqué ou en pause, réactivez la prévisualisation et vérifiez que le fichier ouvert contient une déclaration reconnue ; sinon, passez au témoin minimal.
- Si le témoin minimal s’affiche mais pas la vue réelle, isolez les paramètres, données et dépendances de cette vue avant de toucher à Xcode.
- Si le témoin et la vue réelle échouent avec la même cible, contrôlez schéma, plateforme, runtime installé et premier échec de compilation.
- Si l’erreur cite JIT, un fichier inaccessible ou un autre utilisateur, confirmez le compte qui exécute Xcode et le propriétaire des répertoires concernés avant toute modification de permissions.
- Si Preview fonctionne mais que Simulator échoue, traitez le lancement de Simulator comme un incident distinct ; si les deux échouent, vérifiez séparément leurs destinations et leurs diagnostics.
SECTION 05Comment valider la réparation sans confondre les résultats ?
Après une correction, rouvrez le Canvas et vérifiez que la même prévisualisation se met à jour, puis répétez le test après avoir fermé et rouvert le projet si la panne semblait liée à la session. Conservez le message initial et la modification appliquée : cela permet de savoir si le correctif a traité la cause ou seulement fait disparaître momentanément le symptôme.
Effectuez ensuite une compilation ordinaire pour la cible concernée, puis lancez l’application dans Simulator si cette vérification fait partie de votre scénario. Pour une livraison, contrôlez séparément l’archive de publication et les étapes de distribution ; la documentation Apple sur la distribution des apps décrit ce parcours. Un Canvas fonctionnel ne valide ni l’archive ni la distribution, tout comme une archive réussie ne prouve pas que toutes les vues de l’interface sont prévisualisables.
Les écarts entre ces contrôles sont utiles. Preview réussi et Simulator en échec orientent l’enquête vers le runtime ou l’exécution de l’application. Simulator réussi et Preview en échec renvoient plutôt au contexte de prévisualisation, à la vue ou à ses paramètres. Enfin, l’archive et le test sur appareil répondent à d’autres questions que l’affichage du Canvas : gardez ces preuves séparées dans votre compte rendu d’incident.
| Contrôle | Ce qu’il vérifie | Ce qu’un résultat positif ne prouve pas |
|---|---|---|
| Vue minimale dans Xcode Canvas | Détection de #Preview et démarrage de l’aperçu témoin |
Que la vue complète, ses données et ses dépendances fonctionnent |
| Compilation ordinaire | Construction de la cible sélectionnée | Que le processus Preview démarre correctement |
| Exécution dans Simulator | Lancement de l’application dans la destination simulée | Que le Canvas ou un appareil physique se comporte de la même manière |
| Archive de publication | Préparation d’un artefact de distribution | Que chaque prévisualisation et chaque scénario d’interface ont été validés |
| Résultat constaté | Cause à examiner en priorité | Action suivante |
|---|---|---|
| Canvas indisponible ou en pause | État du Canvas et fichier ouvert | Réactiver l’aperçu, puis contrôler #Preview |
| Vue minimale visible, vue réelle absente | Paramètres, données, ressources ou services de la vue | Réduire la vue et remplacer ses dépendances par des données locales |
| Compilation réussie, Preview en erreur | Cible, runtime ou exécution de Preview | Lire le premier diagnostic et comparer les destinations |
| Erreur JIT ou accès refusé | Compte actif et propriété des répertoires concernés | Vérifier la session avant toute modification de permissions |
| Preview valide, Simulator ou archive en échec | Chaîne de validation distincte | Diagnostiquer l’exécution ou la distribution séparément |
Sur un Mac distant, le poste local qui ouvre la session n’est pas nécessairement celui qui exécute Xcode : le compte macOS, les fichiers accessibles et la session graphique du Mac hébergé font partie du diagnostic. Si vous examinez aussi le choix de votre environnement de travail, vous pouvez consulter les options de Mac distant et comparer les coûts dans les informations tarifaires.
Si Preview échoue parce que les comptes, les accès ou le runtime du Mac distant ne sont pas cohérents, votre environnement actuel peut imposer des changements de session difficiles à reproduire, une machine locale peut mobiliser du stockage et des ressources que vous souhaitez réserver à vos autres tâches, et une compilation ponctuelle sur un poste partagé peut manquer de continuité. Pour des essais isolés, conservez votre Mac local ou votre environnement existant si vous pouvez maîtriser ces contraintes. Si vous avez besoin d’un environnement macOS complet pour répéter le flux Xcode et contrôler les accès, une location auprès de MACNOX peut être plus adaptée qu’un achat dédié ; vérifiez les conditions et la formule sur la page des tarifs avant de choisir.