macOS 10.12.4, arrivé en version finale cette semaine après 8 bêtas, devrait apporter quelque soulagement aux utilisateurs et éditeurs d'applications PDF, confrontés à des dysfonctionnements laissés sans correction par Apple depuis des mois.

Il aura fallu quatre mises à jour successives de Sierra pour que ce problème soit clairement mis en avant par Apple. Les notes de version de la bêta de 10.12.4 demandaient de vérifier le bon fonctionnement des rouages du système dédié à l'utilisation de PDF : « Reading, writing and navigating PDFs using system-provided APIs ». Ça c'était pour les développeurs, côté utilisateurs la version finale promet du mieux avec les rendus et les annotations de PDF dans Aperçu.

• Les PDF mal gérés de macOS Sierra
• Sierra : utiliser les ScanSnap malgré les bugs de compatibilité

Ces ennuis n'étaient pas nouveaux, dès la sortie de Sierra des bugs variés ont touché toute une collection d'utilitaires spécialisés dans la production et l'utilisation de documents PDF. Au départ, cela semblait provenir de ces logiciels puis leurs auteurs ont pointé du doigt "PDFKit", l'un des nombreux frameworks de macOS.

Un seul PDFKit pour macOS et iOS

En voulant réécrire la version macOS de PDFkit pour l'unifier avec celle d'iOS, Apple a cassé la compatibilité de cette boite à outils avec les applications qui piochaient dedans depuis quelques versions du système. Au début de l'année, Christian Grunenberg, développeur de Mindwrap, écrivait :

Apple veut utiliser une fondation commune pour iOS et macOS. Seulement, [PDFKit] a été lancé trop tôt, et pour la première fois (…) Apple a rendu obsolète plusieurs fonctions sans se soucier de leur compatibilité. Et pour corser les choses, beaucoup de ces anciennes fonctions sont maintenant cassées ou pas du tout intégrées, ce qui veut dire que nous devons mettre au point des solutions de contournement ou développer les nôtres.

Cette obligation de réinventer la roue est également l'option qu'a retenue le petit éditeur belge iSolid avec son application PDFZone [1.0 Gratuite en version d'essai Lite ou 25,99 €]. Cet outil, fraichement sorti, est spécialisé dans l'extraction automatique et par lot d'informations contenues à l'intérieur de PDF et leur export dans le format CSV prisé par les tableurs. Si par exemple vous devez récupérer tous les mois des données d'une facture à des fins comptables, il suffit de cibler une fois ces éléments dans un document type et la moulinette de PDFZone procèdera ensuite automatiquement pour tous les PDF de même nature.

Les développeurs laissés dans le noir

Comme DEVONthink, ScanSnap, DocumentSnap, ou encore Bookends, ce logiciel a pris de plein fouet les modifications réalisées à la hussarde par Apple. Malchance supplémentaire, iSolid lançait ici la toute première version de son application. Pour compliquer encore la vie de tout le monde, Apple n'avait pas documenté ces changements dans son framework. PDFKit figurait parmi les thèmes abordés dans l'une des sessions de la WWDC 2016, mais il faut croire que le message sur ses évolutions n'a pas été correctement transmis ou alors qu'il était superficiel.

Jonathan, l'un des deux développeurs chez iSolid, explique la situation qui prévalait il y a quelques mois pour les développeurs :

Le problème est surtout au niveau des fonctions qui d'apparence ne changent pas (la définition est la même), mais pour lesquelles Apple a changé leur implémentation (le code derrière). En théorie, ces changements devraient être invisibles puisque la fonction est censée faire la même chose ! En pratique, beaucoup d'entre elles étaient tout simplement cassées. Ça illustre vraiment le manque de tests faits par Apple.

PDFKIt contient des API toutes prêtes pour gérer le glisser déposer de documents PDF et les afficher, pour surligner des passages, ajouter des annotation ou bien isoler les images et le texte du fichier.

Des solutions maison pour éviter les bugs d'Apple

Dans le cas de PDFZone, son développement a démarré à l'époque d'El Capitan et tout fonctionnait correctement. C'est à partir de Sierra que les choses sont allées de mal en pis, malgré des signalements effectués par des développeurs alors que le système était encore en bêta. En août, octobre, novembre, décembre et les mois suivants, la litanie des plaintes à l'égard du nouveau PDFKit dans le forum développeurs d'Apple ne s'est pas interrompue. Ce qui a commencé à poser un sérieux problème pour iSolid :

N’étant pas la seule équipe de développement rencontrant des problèmes (exemple majeur: Fujitsu et leur ScanSnap dont les PDFs scannés devenaient tout blancs une fois ouverts avec Aperçu), nous nous sommes dits que macOS 10.12.1 règlerait rapidement le souci étant donné son ampleur. Hélas non… Même histoire pour macOS 10.12.2. Pendant ce temps, PDFZone ne pouvait toujours pas être mis en ligne sur le Mac App Store.

L'éditeur belge s'en émeut auprès de Craig Federighi. Le patron des équipes logiciels d'iOS et macOS accuse réception et demande plus d'informations, comme de lui préciser le ou les numéros de rapports de bugs que l'équipe a peut-être déjà soumis.

La mi-décembre arrive et la troisième mise à jour de Sierra sort en bêta, sans les correctifs attendus. Les notes de version n'indiquent que des banalités et la version finale fin janvier ne parlera que de la correction d'un bug avec la recherche dans les PDF.

On était encore loin du compte expliquent les développeurs d'iSolid qui ont décidé de ne plus attendre et éviter les bugs d'Apple en développant leurs propres fonctions internes chaque fois que possible, avec comme objectif de lancer enfin leur application :

• Le glisser déposer de PDF sur la PDFView (la fenêtre d'affichage, ndlr) ne fonctionnait tout simplement plus, rien ne s’affichait. PDFZone ne pouvait dès lors plus être utilisé, car on ne pouvait plus définir un modèle d'extraction. Nous avons contourné le problème en créant une vue transparente au-dessus de la PDFView pour détecter le glisser déposer. À partir de là, l’application demande (d’une façon différente que le glisser déposer qui ne fonctionne plus) à la PDFView d’afficher le PDF.
• Lorsque l’application demandait à la PDFView de ne plus rien afficher et qu’un PDF était affiché auparavant, un bug graphique apparaissait. Détail amusant, ce bug ne se produisait pas avec tous les PDFs, seulement certains. Pour ce problème, nous ne pouvions malheureusement rien faire (en tout cas pas dans un temps raisonnable), mais il n’affecte pas le bon fonctionnement du logiciel, seulement l’interface utilisateur.

Ce ne sont là que deux exemples partagés par l'éditeur, bien d'autres problèmes pénalisaient le bon fonctionnement de PDFZone et de ses camarades. En définitive, le développement de ces solutions de contournement a porté ses fruits et rendu l'utilitaire fonctionnel sur Sierra. Même Apple semble avoir opté pour cette voie. Dans un article sur Tidbits, un développeur constatait qu'Aperçu dans Sierra n'était pas affligé des bugs constatés ailleurs, comme si ses auteurs chez Apple avaient eux-aussi créé des solutions de fortune en attendant que PDFKit soit corrigé.

Avec la bêta du 10.12.4, Apple a commencé à faire le ménage dans ses bugs, cependant iSolid préfère conserver ses propres solutions « pour assurer une compatibilité avec les anciennes versions de Sierra. Les futures mises à jours de PDFKit seront suivies de très près de notre côté ».

Il y a toutefois un mal pour un bien dans cette histoire, conclut l'éditeur « PDFZone sort finalement avec six mois de retard, mais ce temps n’était pas que perdu, nous en avons profité pour améliorer les algorithmes et le design de l’application. »

Ce malheureux épisode rappelle quelque peu celui de 2015 avec les services système Discoveryd et mDNSResponder. Le premier avait remplacé le second et généré toute une série de problèmes réseau dans OS X et iOS avant qu'Apple ne rebrousse chemin.

Dans le cas de PDFKit, il est désolant de constater qu'il aura fallu quatre mises à jour de Sierra pour que le problème soit pris à bras le corps. Qui plus est pour du PDF, un format de fichiers historiquement bien loti sur Mac.