Lors du débogage à distance d’une application macOS qui ouvre des documents, un cas revient souvent : le fichier d’essai s’ouvre quand on désigne explicitement l’application dans le terminal, mais un double-clic sur ce même fichier placé sur le bureau lance une autre application, ou macOS demande laquelle utiliser. Le premier succès montre seulement que l’application peut recevoir le fichier ; il ne valide pas l’association du type de fichier. Pour comprendre ce qui se passe, il faut vérifier séparément la déclaration du type, la prise en charge par l’application et l’ouverture par défaut.
Prenons l’exemple d’un fichier personnalisé .notejson. Son contenu est du JSON, tandis que son extension sert à identifier les documents propres à l’application. Effectuez les vérifications sur une application macOS déjà compilée et exécutable. Le fichier d’essai ne doit contenir que des données fictives, jamais un document de production.
Déclarer le type de fichier avant de se limiter à son extension
Un format propre à une application doit posséder un identifiant de type stable. Dans cet exemple, il s’agit de dev.sample.notejson, associé à l’extension notejson et à un contenu conforme à JSON. La déclaration doit couvrir deux points : exporter ce type et indiquer que l’application peut l’ouvrir. Tester l’extension du nom de fichier dans le code ne suffit pas à créer une association dans le Finder.
Après avoir configuré le type exporté et les Document Types dans la cible de l’application sous Xcode, examinez l’Info.plist du paquet applicatif obtenu. La déclaration du type exporté doit contenir son identifiant, son extension et le type parent auquel il se conforme. Le type de document doit faire référence au même identifiant. Si l’application d’exemple permet seulement de consulter les fichiers, définissez son rôle documentaire sur Viewer ; ne lui attribuez pas une capacité de modification qui n’existe pas encore.
La vérification porte sur le paquet applicatif compilé, pas sur un réglage visible dans le projet mais absent du résultat de compilation.
Si le format n’est pas réellement du JSON, ne le déclarez pas conforme à JSON pour les besoins de l’exemple. La relation entre types doit refléter le contenu réel. Après toute modification de la déclaration, recompilez l’application : un ancien paquet ne se met pas à jour tout seul lorsque les réglages du projet changent.
Examiner les déclarations dans le paquet livré
Placez d’abord l’application à valider à un emplacement fixe. Les commandes suivantes utilisent /Applications/NoteReader.app comme exemple ; avant de les exécuter, adaptez APP au chemin de votre application :
APP="/Applications/NoteReader.app"
test -d "$APP/Contents" || exit 1
plutil -extract UTExportedTypeDeclarations json -o - "$APP/Contents/Info.plist"
plutil -extract CFBundleDocumentTypes json -o - "$APP/Contents/Info.plist"
Dans la première sortie, vérifiez la présence de dev.sample.notejson et de notejson ; dans la seconde, vérifiez le même identifiant de type et le rôle documentaire. Si plutil signale qu’une clé est absente, revenez à la configuration de la cible et au résultat de la compilation avant de passer au test par double-clic. Certains projets génèrent la liste de propriétés finale à partir des réglages de compilation : c’est bien le fichier présent dans le paquet qui fait foi.
Sur le Mac distant, assurez-vous également de vérifier l’exemplaire que vous venez de compiler. Si des applications de même nom se trouvent à la fois dans le dossier des téléchargements et dans celui des applications, le test effectué dans le terminal avec un chemin explicite et celui de l’ouverture par défaut dans le Finder peuvent concerner deux copies différentes. Notez le chemin du paquet et retirez les anciennes copies exclues du test : c’est souvent plus utile que de modifier plusieurs fois la déclaration du type.
Distinguer les pannes avec deux modes d’ouverture
Créez un fichier d’essai temporaire. Ouvrez-le d’abord en désignant l’application, puis testez le choix par défaut du système :
APP="/Applications/NoteReader.app"
CASE="$(mktemp -d)"
printf '{"title":"association-check"}\n' > "$CASE/demo.notejson"
open -a "$APP" "$CASE/demo.notejson"
open "$CASE/demo.notejson"
Si open -a réussit, l’application désignée a reçu la demande de traiter le fichier. Vérifiez ensuite qu’elle affiche réellement le contenu d’essai : l’apparition d’une fenêtre ne prouve pas que la lecture est terminée. Seule la deuxième commande, qui ne désigne aucune application, passe par le choix de l’application par défaut. Vous pouvez aussi double-cliquer sur le même fichier dans le Finder et observer quelle application s’ouvre effectivement.
L’association par défaut dépend des applications déjà présentes sur ce Mac et des choix de l’utilisateur. Dans le compte rendu de validation, consignez donc séparément le « résultat avec l’application désignée » et le « résultat de l’ouverture par défaut pour l’utilisateur actuel ». Ce dernier ne permet pas de conclure que tous les Mac se comporteront de la même façon. Si le système affiche une fenêtre de choix d’application, notez-le également : ce n’est pas une association automatique réussie.
Diagnostiquer d’après les symptômes sans modifier à tort le code de lecture
| Constat | À vérifier en priorité |
|---|---|
| La déclaration du type ou du document manque dans le paquet applicatif | Configuration de la cible, résultat réel de la compilation |
| Le fichier reste illisible même en désignant l’application | Contenu du fichier, logique de réception et d’analyse dans l’application |
| L’application désignée lit le fichier, mais l’ouverture par défaut lance autre chose | Association par défaut de l’utilisateur actuel, autres copies de l’application |
| L’application démarre, mais affiche un document vide | Gestion des erreurs après réception du fichier et état de l’interface |
Les deux derniers cas prêtent particulièrement à confusion. Même si le système transmet le fichier à l’application, celle-ci peut refuser de l’analyser parce que le format du fichier d’essai est incorrect. À l’inverse, une application peut parfaitement analyser le fichier sans être choisie par défaut par le système. Déterminez d’abord à quelle étape l’aiguillage échoue, puis modifiez le code concerné.
Une fois la validation terminée, supprimez le fichier d’essai temporaire. Conservez dans le suivi de compilation le chemin du paquet applicatif, l’identifiant de type, l’extension du fichier d’essai et les résultats des deux modes d’ouverture. Lors d’une prochaine modification de l’Info.plist ou du code de lecture des documents, reprenez les mêmes vérifications : vous pourrez déterminer si le changement concerne l’association du type ou le fonctionnement interne de l’application, sans vous contenter d’un « j’ai essayé de double-cliquer ».
Questions fréquentes
Pourquoi le double-clic lance-t-il une autre application alors que open -a fonctionne ?
open -a impose l’application choisie et ne vérifie pas l’association par défaut. Inspectez les déclarations de type dans le paquet, puis ouvrez le fichier sans -a ou par double-clic.
Que vérifier si le fichier arrive dans l’application mais ne peut pas être lu ?
L’association et l’analyse du contenu sont deux étapes distinctes. Vérifiez le format réel du fichier, puis le code de lecture et le message d’erreur produit par l’application.
Intégrez un Mac dans le cloud à votre flux de travail
VPSPush propose des Mac physiques dédiés accessibles à distance. Choisissez un emplacement et une durée, puis vérifiez les informations de connexion et le montant final dans votre commande.