La note de version de Xcode 27.1 RC signalait que le simulateur iPhone Duo ne pouvait pas exécuter ni déboguer la plupart des App Extensions (notes de version de la RC). Si une extension échoue, vérifiez d’abord sa catégorie et les notes de la version finale de Xcode 27.1 : cet avertissement RC ne prouve pas que la version finale présente la même limite. Séparez ensuite les vérifications d’interface possibles dans le simulateur des comportements d’extension qui restent à valider dans un environnement pris en charge.
À qui s’adresse ce diagnostic ? Aux développeurs indépendants dont un widget, une extension de partage ou une autre extension ne démarre pas dans le simulateur iPhone Duo. Il concerne aussi les équipes qui doivent choisir un environnement macOS/Xcode ou préparer une validation avant publication.
Dernière mise à jour : 23 octobre 2026. Les informations de disponibilité et de version sont à vérifier dans les annonces Apple Developer, la préparation des apps pour iPhone Duo et les notes officielles de Xcode 27.1. La présence d’une note pour la RC ne permet pas, à elle seule, de conclure sur l’état de la version finale.
Établir d’abord si le simulateur est la limite
Une extension qui ne démarre pas dans le simulateur ne démontre pas que son code est défectueux, ni qu’elle échouera sur un appareil pris en charge. Le premier diagnostic consiste à distinguer une restriction documentée du simulateur d’un problème de configuration propre au projet.
La note de Xcode 27.1 RC mentionne une limite concernant la plupart des App Extensions sur le simulateur iPhone Duo. Elle ne dit pas que toutes les extensions sont concernées, et ne précise pas à elle seule le comportement de chaque catégorie. Il ne faut donc pas transformer cette observation en règle générale, ni attribuer automatiquement à la version finale un problème signalé pour une version candidate.
Pour connaître l’état actuel, consultez l’entrée correspondant à la version finale dans les versions de Xcode publiées par Apple, puis ouvrez ses notes de version. Comparez-les à l’entrée RC, sans confondre les deux. Si les notes finales ne confirment ni la limite ni sa résolution, consignez le statut comme « à vérifier » plutôt que de choisir l’une de ces conclusions.
Apple indique que l’iPhone Duo a commencé à être proposé aux utilisateurs le 23 octobre 2026 dans son annonce de préparation destinée aux développeurs. Cette information situe le contexte de publication ; elle ne constitue pas une preuve de compatibilité de chaque extension avec le simulateur.
Réduire le problème à une catégorie et à un déclencheur précis
La question « pourquoi l’extension ne s’ouvre-t-elle pas ? » recouvre plusieurs situations. Un widget, une extension appelée depuis une feuille de partage et une extension découverte par une app ne suivent pas nécessairement le même parcours de lancement. Apple décrit séparément le débogage des widgets et les mécanismes liés aux App Extensions ; ces documents sont plus utiles qu’une déduction à partir d’un seul projet.
Avant de modifier le code, consignez les éléments suivants :
- le type exact de l’extension, tel qu’il apparaît dans la configuration du projet ;
- l’action qui doit la déclencher : ajout d’un widget, commande de partage ou autre entrée ;
- le nom de l’app hôte et la cible de l’extension sélectionnée dans Xcode ;
- l’appareil ou le simulateur choisi, ainsi que l’orientation ou l’état d’affichage lors de l’essai ;
- l’étape qui échoue : l’entrée est absente, le lancement échoue ou l’extension s’ouvre puis se comporte mal.
Pour un widget, suivez les consignes de débogage des widgets publiées par Apple. Pour les autres extensions, vérifiez la documentation Apple consacrée à l’ajout de la prise en charge des App Extensions et à leur découverte par une app. Ces références décrivent des comportements spécifiques ; elles ne justifient pas d’étendre une restriction à des catégories qu’elles ne mentionnent pas.
Distinguer une entrée absente d’un lancement qui échoue
Le symptôme donne une piste, pas encore une cause certaine. Une extension absente du menu ou de la galerie peut être un problème de découverte ou d’installation ; une entrée visible qui échoue au lancement appelle une vérification différente. Un lancement suivi d’un écran vide ou d’une erreur de communication peut impliquer l’intégration avec l’app hôte, mais la corrélation ne suffit pas à identifier le composant fautif.
| Symptôme observé | Vérification prioritaire | Ce que le résultat permet de conclure |
|---|---|---|
| L’extension n’apparaît pas dans son point d’entrée | Confirmer l’installation de l’app hôte et de la bonne extension ; vérifier le parcours de découverte correspondant à son type | Une entrée absente oriente vers l’installation, la configuration ou la découverte, sans établir à elle seule une limite du simulateur |
| L’entrée apparaît, mais le lancement échoue | Confirmer la cible sélectionnée, le résultat de compilation et les journaux associés à l’essai | Un échec peut être lié au projet ou à l’environnement ; il faut rapprocher le message observé des limites documentées |
| L’extension démarre, puis l’interface ou l’échange avec l’hôte échoue | Reproduire avec le même hôte et le même déclencheur ; relever les erreurs de l’extension et de l’app | Le démarrage réussi ne valide pas toute l’intégration ; le défaut reste à isoler |
| Le problème ne se produit que sur iPhone Duo Simulator | Comparer les notes de version et répéter le parcours dans un environnement pris en charge si disponible | L’écart constitue un indice d’une limite d’environnement, pas une preuve suffisante d’un bogue Apple ou d’un bogue applicatif |
Gardez les journaux autour de l’instant du déclenchement, le message complet de Xcode et une description reproductible de l’action effectuée. Évitez de conserver uniquement une capture de l’erreur : elle indique rarement si le système n’a pas trouvé l’extension, si son processus n’a pas démarré ou si une opération a échoué ensuite.
Vérifier l’app hôte, le schéma et le produit compilé
Une limite du simulateur et une configuration incorrecte peuvent produire des symptômes voisins. Avant de classer l’incident comme non pris en charge, assurez-vous que le schéma actif, la destination d’exécution, l’app hôte et la cible d’extension correspondent tous au même essai. Apple explique comment personnaliser les schémas de build et comment lancer une app dans un simulateur ou sur un appareil physique.
| Élément à contrôler | Action dans Xcode | Écart à relever |
|---|---|---|
| Schéma | Ouvrir la liste des schémas et sélectionner celui qui correspond à l’app hôte testée | Un schéma de test ou une app hôte différente de celle attendue |
| Destination | Vérifier la destination d’exécution sélectionnée avant le lancement | Un simulateur différent de celui utilisé lors de la reproduction |
| Cible de l’extension | Confirmer que la cible existe dans le projet et qu’elle est incluse dans le parcours de compilation prévu | Une cible non compilée ou une configuration différente de celle de l’hôte |
| Produit compilé | Examiner les résultats du build et vérifier que l’app hôte livrée contient le produit d’extension attendu | Un produit absent, ancien ou issu d’une autre configuration |
L’inspection des réglages de build est une vérification utile quand les valeurs du projet et celles appliquées à la cible semblent diverger. La référence Apple des réglages de build permet de vérifier le sens des paramètres concernés. Dans le rapport de build, relevez notamment quelle cible a été compilée et quel résultat a été produit. Ne concluez pas que l’extension est correctement installée simplement parce que la compilation s’est terminée sans erreur : contrôlez aussi le produit associé à l’app hôte.
Pour garder une trace reproductible, vous pouvez lancer une inspection du schéma et des réglages avec les outils de ligne de commande fournis avec Xcode :
xcodebuild -list
xcodebuild -showBuildSettings -scheme "$SCHEME"
Exemple de sortie à rechercher, sans présumer des valeurs propres à votre projet :
Targets:
App
WidgetExtension
Build settings for action build and target WidgetExtension:
PRODUCT_BUNDLE_IDENTIFIER = …
Si la cible d’extension attendue n’apparaît pas dans la liste, ou si ses réglages ne correspondent pas à la configuration testée, corrigez d’abord le projet ou le schéma. Si le produit est présent mais que le lancement échoue uniquement dans ce simulateur, cette vérification ne supprime pas l’hypothèse d’une limite de support : elle permet simplement d’écarter certaines erreurs de préparation.
Utiliser cette liste pour décider de la prochaine action
Cochez les contrôles au fur et à mesure. Un élément non confirmé doit rester une réserve dans le compte rendu, et non être traité comme un test réussi.
- [ ] Relever la version exacte de Xcode et vérifier si l’essai porte sur une RC ou sur une version finale.
- [ ] Consulter les notes de version de la version finale ; séparer explicitement leur contenu de celui de la RC.
- [ ] Identifier le type d’extension, l’app hôte et l’action qui doit déclencher l’extension.
- [ ] Vérifier le schéma, la destination d’exécution et la cible compilée dans le même essai.
- [ ] Contrôler que le produit de l’extension est bien intégré au produit attendu de l’app hôte.
- [ ] Classer le symptôme : entrée absente, lancement impossible ou anomalie après lancement.
- [ ] Consulter la documentation Apple propre au type d’extension et noter ce qu’elle confirme réellement.
- [ ] Si le simulateur ne permet pas la vérification du comportement, désigner ce point comme « non vérifié » jusqu’à un essai dans un environnement pris en charge.
| Résultat des contrôles | Décision raisonnable | Suite à donner |
|---|---|---|
| L’entrée ou le produit attendu manque, ou le schéma ne correspond pas | Problème de configuration à traiter en premier | Corriger le projet, reconstruire l’app hôte puis répéter le même parcours |
| La configuration est cohérente et la note officielle confirme une limite applicable | Limite d’environnement documentée | Vérifier séparément l’interface dans le simulateur et le comportement de l’extension dans un environnement pris en charge |
| La configuration est cohérente, mais les notes finales ne tranchent pas | Cause non établie | Conserver les journaux et les étapes de reproduction ; éviter de conclure à un défaut du code ou à une incompatibilité générale |
| Le problème disparaît dans un autre environnement pris en charge | Écart lié à l’environnement à investiguer | Comparer les conditions d’essai et documenter la différence sans la présenter comme une cause démontrée |
Un essai réussi de l’interface dans le simulateur n’équivaut pas à une validation complète de l’extension. Si son entrée, son démarrage ou son échange avec l’app hôte n’a pas été testé dans un environnement adapté, indiquez clairement que ce comportement reste à valider.
Séparer l’adaptation d’affichage de la validation de l’extension
Le simulateur iPhone Duo peut servir à contrôler les scénarios d’affichage qu’il prend effectivement en charge, conformément aux consignes de préparation des apps pour iPhone Duo. Cette vérification concerne la présentation de l’app dans les conditions proposées par le simulateur. Elle ne prouve pas que chaque catégorie d’extension peut y être lancée, ni que son fonctionnement avec l’app hôte est complet.
| Parcours de validation | Ce qu’il peut établir | Ce qu’il ne faut pas en déduire |
|---|---|---|
| Contrôle d’affichage dans iPhone Duo Simulator | Le rendu de l’app pour le scénario reproduit dans ce simulateur | La prise en charge générale de tous les points d’entrée d’extension |
| Vérification de compilation et d’intégration du produit | La présence des cibles et produits attendus dans le résultat examiné | Le fonctionnement de l’extension dans chaque environnement d’exécution |
| Essai de l’extension dans un environnement officiellement pris en charge et accessible à l’équipe | Le comportement observé pour le type d’extension et le parcours testés | La compatibilité de toutes les catégories ou configurations non testées |
En l’absence d’un appareil iPhone Duo ou d’un autre environnement de test que la documentation Apple considère approprié pour le comportement visé, ne présentez pas le test comme une acceptation complète. L’équipe peut tout de même contrôler le build, l’intégration du produit et les scénarios d’interface disponibles, puis marquer les comportements d’extension comme non vérifiés. La bonne conclusion est alors limitée à ce qui a été observé.
La vérification d’un iPhone Duo réel ne remplace pas non plus la lecture des notes de version : si Apple documente une limite propre à une version ou à un parcours, consignez cette information et expliquez pourquoi le test a été effectué dans l’environnement retenu. Pour préparer un poste macOS destiné à ce type de contrôle, le guide de démarrage NUMACS aide à vérifier les étapes d’accès et de mise en route ; il ne constitue pas une preuve de compatibilité de l’extension.
Consigner un résultat que l’équipe peut réexaminer
Un compte rendu utile doit permettre à une autre personne de reprendre le même essai sans deviner le contexte. Notez la version exacte de Xcode, le type d’extension, le schéma, la destination, l’app hôte, l’action déclenchée et le symptôme. Ajoutez les messages de build et les journaux pertinents, en distinguant les faits observés des interprétations.
Terminez par une des trois conclusions suivantes :
- Vérifié : le comportement visé a été reproduit et contrôlé dans un environnement adapté ; précisez le parcours effectivement testé.
- Non vérifié en raison d’une limite : certains contrôles ont réussi, mais le simulateur ne permet pas d’établir le comportement de l’extension.
- À examiner davantage : les notes officielles ne tranchent pas le cas, ou les résultats ne permettent pas d’isoler la cause.
Reprenez cette fiche si Apple publie une mise à jour de Xcode 27.1, complète les indications de prise en charge du simulateur ou modifie les exigences de test pour iPhone Duo. Pour comparer les conditions d’accès à un Mac distant avec un poste acheté et entretenu par l’équipe, consultez aussi la comparaison des solutions proposée par NUMACS.
Quand aucun environnement macOS/Xcode adapté n’est disponible, un Mac distant NUMACS peut être envisagé pour exécuter des vérifications complémentaires sans acheter une machine dédiée. Il convient toutefois de comparer les contraintes : une configuration locale offre un accès direct au matériel et reste préférable si des interfaces physiques sont indispensables ; un environnement distant dépend de la connexion et ne dispense pas de disposer d’un appareil réel lorsque le parcours l’exige. Si le besoin est temporaire, pour une campagne de régression ou une vérification de version, la location peut éviter de financer un poste qui resterait ensuite inutilisé. Vérifiez les conditions et les environnements proposés sur les offres NUMACS, puis classez chaque résultat comme vérifié, limité ou encore à confirmer.
Pour aller plus loin
Numacs Mac dans le cloud
Poursuivez vos tests Xcode sur un Mac dédié avec NUMACS
Reproduisez vos builds et vos tests dans un environnement macOS stable sur un véritable Mac mini Apple Silicon, et non sur une machine virtuelle.