Andrew Pepperrell, l'auteur du lanceur multifonction Alfred a publié un billet sur son blog. (lire aussi Alfred 1.0 en approche).
Il rappelle que son utilitaire sollicite diverses ressources d'OS X pour lancer des fichiers, ouvrir des URL, exécuter des AppleScripts ou commandes Terminal «Il est en résumé une interface rapide avec le coeur de Mac OS X».
Le PowerPack est une option payante d'Alfred qui déverrouille des fonctions supplémentaires (accès à Carnet d'adresses, historique d'album, création de commandes Shell par l'utilisateur, etc). Même si ce PowerPack utilise des interfaces de programmation publiques, sa nature contrevient au sandboxing d'OS X puisqu'il met en relation étroite Alfred avec d'autres applications ou éléments système.
Un obstacle technique qui se double d'une perte financière puisque l'absence de cette option dans Alfred sur le Mac App Store - désormais un puissant circuit de promotion pour une application - représente une source de revenus en moins pour l'auteur.
Pepperrell va donc proposer deux versions d'Alfred, celle du Mac App Store sans cette option intégrée et une autre, complète, distribuée depuis son site web. La solution intermédiaire qui consisterait à proposer le PowerPack sur le Mac App Store pour ensuite l'ôter à compter de mars prochain - au grand dam des clients qui verraient leur achat déprécié fonctionnellement - étant pour lui exclue.
Autre expérience, celle de Louka Desroziers, développeur du lecteur audio Ecoute qui s'appuie sur le contenu d'iTunes sans avoir besoin qu'il soit ouvert [2.0.9 – Français – 6,99 € – Louka Desroziers].
J'ai essayé de faire passer Ecoute dans son bac à sable… sans grande satisfaction. Déjà, il faut entièrement retester son application, parce qu'il y aura toujours un petit quelque chose qui ne marchera pas. Après avoir regardé les choses d'un peu plus près, le premier problème auquel je me heurte est bel et bien l'accès simple en lecture des fichiers. Mais je suis un cas assez isolé. Ecoute se sert d'un fichier XML généré par iTunes. Ce fichier contient les informations des morceaux de votre bibliothèque iTunes, ainsi que le chemin d'accès de chacun des fichiers audio et vidéo.
Problème, ce chemin est absolu et il est récupéré via un fichier (et non pas au moyen d'interfaces de programmation conçues pour récupérer divers dossiers clés d'OS X). Ça pose donc un gros problème pour quelqu'un comme moi qui laisse iTunes gérer l'organisation de ses fichiers. C'est à dire dans '~/Musics/iTunes/'. Or, il s'agit là du dossier 'Music' qui, une fois l'application mise dans son bac à sable, n'est plus accessible comme auparavant. On est obligé de passer par la sandbox pour accéder à ce dossier spécifique du système.
Bien sûr ça peut toujours être résolu en détectant que le fichier se trouve dans le dossier "Music" de l'utilisateur, et en transformant donc le chemin en utilisant directement l'API permettant de récupérer le 'NSMusicDirectory'. Mais ça implique de rajouter du code. Le sandboxing n'est donc pas aussi facile qu'Apple veut bien le laisser entendre.
Autre problème, je n'ai, pour le moment, pas trouvé comment autoriser mon application à envoyer des notifications à travers OS X. C'est bien utile pour les développeurs tiers qui souhaiteraient faire une application qui se servirait d'Ecoute.
Je pense notamment à Sleepytime [2.0 – US – 3,99 € – 24,1 Mo – Michael Fortin] qui utilise les notifications envoyées par Ecoute à chaque fois que le lecteur change d'état ou de morceau.
La réponse d'Apple à ce sujet est claire: le sandboxing n'autorise pas les 'distributed notifications' qui contiennent un 'userInfo', autrement dit, il est impossible d'envoyer une 'distributed notification' avec des informations complémentaires.
Apple stipule (officieusement, car ça n'est marqué nulle part, mais c'est la réponse qu'un développeur chez Apple m'a donnée) qu'il faudra préférer créer plusieurs notifications ayant des noms différents, ce qui permettra de distinguer les actions dans mon application. Autrement dit, plutôt que d'avoir une notification qui indique, de par son nom, que l'état du lecteur d'Ecoute a changé, puis ajouter un 'userInfo' contenant cet état, il faudra créer une notification par état. SleepyTime devra donc être mis à jour quand Ecoute sautera dans son bac à sable…
De plus, j'ai vraiment du mal à comprendre en quoi le sandboxing donne une impression de sécurité. Pour moi, c'est plus un sentiment de limitation. L'avantage avec iOS, c'est qu'on était prévenu dès le début, avant même que la première application n'apparaisse sur le store. OS X, même depuis l'arrivée du Mac App Store, restait un bonheur pour certains développeurs qui souhaitaient se libérer un peu de l'emprise d'Apple sur iOS. Le Mac App Store risque de devenir un magasin d'applications limitées. Et Cydia for OS X sera la bienvenue pour certains utilisateurs…
