Sandboxing OS X : deux expériences de développeurs

Florian Innocente |
sandboxingapple-1
Le sandboxing des applications dans Lion sera obligatoire pour qu'elles soient acceptées sur le Mac App Store. Apple a informé les développeurs cette nuit que le délai de mise en conformité avait été repoussé au début de l'année prochaine (lire Mac App Store : bac à sable obligatoire en mars 2012). Deux développeurs expliquent concrètement ce que cela implique pour leurs logiciels.

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.

alfred10


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.

sleepytime


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…

avatar oomu | 
"Mais ça implique de rajouter du code. Le sandboxing n'est donc pas aussi facile qu'Apple veut bien le laisser entendre" le sandboxing est FACILE à _ACTIVER_ (c'est une case, via xcode) Apple n'a jamais dit que c'était facile de faire ensuite la même chose qu'avant ! - Comme d'habitudes avec les changements, les développeurs s'y feront. Apple rajoutera des fonctionnalités surveillées pour les usages les plus importants etc.
avatar pwetpwet | 
Malgré ces témoignages, encore et toujours les mêmes illuminés pour défendre tout ce qu'Apple dit ou fait... un autre témoignage de la part du développeur de BetterTouch Tools : http://blog.boastr.net/?p=2698 Lui non-plus n'est pas franchement ravi par cette nouvelle. Mais bon, "c'est pour notre bien"
avatar laurange | 
@Eaglelouk "Quand je dis que je ne vois pas ce qu'apporte le sandboxing en terme de sécurité, je me suis mal exprimé. En fait ce que je veux dire c'est que je doute que l'utilisateur lambda s'en pré-occupe. On a jamais eu de problème de sécurité concernant la majorité des applications sur Mac" C'est pour que l'utilisateur lambda n'ait jamais à s'en préoccuper que le sandboxing est utile, et qu'il n'ait pas besoin d'anti virus-malware-keylogger. Si Apple peut assurer à 99,9% que les apps du MAS sont fiables, c'est une raison de plus pour acheter les yeux fermés ces softs à moins de 10 euros. Je suis informaticien et je veux laisser les problèmes d'ordinateur au boulot, pas à la maison, c'est pour ça que j'ai un mac ( en fait juste un ipad depuis peu ).
avatar rokdun | 
@ Santa Claus ce qui compte ce n'est pas la concision mais la clarté du code. Ce sont des notions variables selon les programmeurs, mais un code plus courts ne signifie pas forcément qu'il sera plus propre et plus maintenable. Quand Eaglelouk parle de code dégueulasse, il parle certainement de code lourdingue, avec des tas de cas spéciaux et d'exceptions, susceptible de cesser de fonctionner brutalement en cas de mise à jour du système par exemple. C'est pénible pour un développeur de faire ce genre de bricolage. Mais bon. C'est la vie. Les développeurs doivent souvent se débrouiller pour contourner les limitations du système...
avatar Santa Claus | 
@rokdun : ok... Merci pour les explications...

Pages

CONNEXION UTILISATEUR