Je viens de découvrir Backdrop. Cette application sert à masquer le Bureau et ses icônes en les remplaçant par un autre fond. Ceci s’avère bien utile pour préparer des copies d’écran de votre application avant sa publication sur le Mac App Store.
Essayez-là, elle est bien faite et gratuite.
Dans l‘article précédent, je vous expliquai comment maintenir à la fois une version de votre application pour le Mac App Store et pour votre site web. Dans le présent article, nous verrons comment se prémunir du piratage de l’application en validant le reçu fourni par Apple.
Un répertoire _MASReceipt est incorporé au bundle de l’application téléchargée sur le Mac App Store:
.../SampleApp.app/Contents/_MASReceipt/receipt
Ce reçu constitue la pierre angulaire de la protection anti-pirate. Il s’agit de vérifier qu’il a bien été émis par Apple et que son contenu correspond bien à notre application. Malheureusement, Apple ne fournit pas d’API pour effectuer ces vérifications. Devant la difficulté de concevoir un service invulnérable, Apple a baissé les bras et s’est déchargée du travail sur nos épaules de développeurs. C’est donc à chaque application de faire les vérifications, qui n’ont rien de trivial!
Apple a rédigé un document (réservé aux développeurs inscrits) qui décrit le contenu d’un reçu et les étapes de la validation. Comme vous le verrez, les indications pour l’implémentation concrète sont laconiques. Le but avoué est d’éviter que tous les développeurs utilisent le même code de validation. Le problème, c’est que peu de développeurs possèdent les connaissances nécessaires pour implémenter ces vérifications. Face à cette complexité, des développeurs ont décidé de créer une solution open-source: Roddi-ValidateStoreReceipt. On trouve aussi cet exemple d’Alan Quatermain, qui fut précurseur mais est moins abouti. Attention toutefois, il ne faut en aucun cas réutiliser ce code tel quel: il serait trop facile à repérer et modifier.
Comparons un peu la solution de Roddi et les préconisations d’Apple.
Apple donne quelques indications pour vérifier la signature du reçu en utilisant OpenSSL, et indique qu’il faut utiliser le certificat Apple Root CA, mais pas comment l’obtenir. Le code de Roddi va chercher le certificat dans le Trousseau. Celui de Quatermain le récupère sur le site d’Apple, ce qui présente le défaut d’exiger un accès à Internet au lancement de l’appli.
La partie “Payload” du reçu comprend les informations que nous allons vérifier par la suite: Bundle Identifier, version de l’appli, une valeur opaque (=aléatoire) et un hâchage. Apple préconise l’utilisation d’un obscur outil en ligne de commande, asn1c, pour décomposer la Payload. J’ai installé macports, installé asn1c et généré grâce à lui un fichier C permettant la décomposition.
Voici mon constat:
Comparez le Bundle Identifier de votre appli (pour moi, ”com.ceroce.PortraiMatic”) à celui du reçu. Ceci garantit que le reçu correspond bien à votre appli, et qu’on n’a pas remplacé le reçu de votre appli par celui d’une autre appli… (Hein, Angry Birds!) Faites de même pour la version: vous ne voudriez pas que l’utilisateur utilise le reçu de la version 1.5.3 pour valider la version 2.1.0… Il peut être tentant de récupérer ces deux informations depuis Info.plist: mauvaise idée. Ce fichier peut être modifié sans impact sur le reçu. Stockez le Bundle Identifier et la version ”en dur” dans votre code. De même, évitez — en les obscurcissant — que ces deux chaînes apparaissent quand on ouvre l’application avec un éditeur hexa. Notez que le code de Roddi compare les chaînes en dur avec celles d’Info.plist pour éviter les étourderies.
Le GUID est en fait l’adresse mac de l’ordinateur autorisé. Pour une fois, Apple fournit du code pour la récupérer (adopté tel quel chez Roddi). Il faut concaténer le GUID + la valeur opaque + Bundle Identifier et appliquer au tout un hâchage SHA-1. Ce hâchage doit correspondre au hâchage stocké dans la payload. !!! En conclusion Nous l’avons vu, la validation n’est pas facile. Heureusement, d’autres ont déjà essuyé les plâtres! Peut-être qu’Apple nous proposera une solution plus simple dans un avenir proche.
Installer une application sous Mac OS ”Classic” (c’est à dire jusqu’à sa version 9 incluse) n’était pas très facile: il fallait lancer un installateur qui décompressait et copiait ses fichiers un peu n’importe où sur votre disque dur. En dehors du fait que chaque installateur semblait différent, ils avaient tendance à placer beaucoup de fichiers indésirables tels que des alias sur le bureau ou la barre de lancement (ceux qui pratiquent Windows connaissent bien cette situation).
Mac OS 10.0 apporta une nette amélioration: depuis, il suffit d’ouvrir une image disque qui monte sur le bureau; on y trouve une application qu’il ne reste plus qu’à glisser sur le disque dur. Les installateurs restent nécessaires pour les applications qui modifient le système d’exploitation et n’ont donc pas totalement disparu, mais au moins l’installateur est toujours celui d’Apple. Quoi que vous en pensiez, ce système est encore très perfectible.
Sachez que beaucoup d’utilisateurs ne savent pas installer une application. Il est nécessaire de mettre une image en fond de l’image disque qui dise “Pour installer l’application glissez-là dans le dossier Application ou tout autre dossier”. Quand une application est traduite dans plus de trois langues cette solution n’est plus envisageable, il faut alors dessiner une flèche ou un symbole similaire.
Même avec ces indications, je me rends compte (au téléphone, avec les clients au bout du fil), que certains utilisateurs lancent PortraiMatic depuis l’image disque. Aussi certaines applications détectent cette situation et affichent un message. Pour finir, notez que l’utilisateur a accès à au moins deux dossier Applications: celui qui est commun à tout le monde (Disque dur/Applications) et le sien (~/Applications). Or, il faut un mot de passe administrateur pour écrire dans le premier…
Jeter une application à la corbeille ne la désinstalle pas totalement. Sur les forums, on peut voir beaucoup de messages d’utilisateurs qui ne comprennent pas pourquoi leur problème n’est pas réglé alors qu’ils ont désintallé puis réinstallé l’application. En effet, certains fichiers restent présents sur la machine, notamment les fichiers de Préférences et le dossier Bibliothèque/Application Support.
Sous iOS, l’utilisateur n’a pas accès au système de fichiers. Ceci rend complexe l’échange de fichiers entre les applications et avec d’autres machines, mais procure des avantages énormes: il n’y a plus besoin de ranger ses fichiers, et désinstaller une application retire tous les fichiers qui lui sont rattachés, documents inclus.
Concrètement, sous le capot, iOS utilise un système de fichiers classique (sans doute HFS+ ou UFS). Les applications n’ont le droit que d’écrire dans leur ”bac à sable”, un répertoire qui leur est réservé, et dans les fichiers de préférences. Quand on désinstalle une application, le système d’exploitation n’a donc plus qu’à supprimer le répertoire associé.
La volonté d’Apple avec le Mac App Store est de reproduire sous Mac OS ce fonctionnement. Ainsi, les emplacements dans lesquels peut écrire l’application sont délimités. Toute application qui écrit ailleurs (sans intervention explicite de l’utilisateur) sera donc rejetée par les validateurs d’Apple. Certes, cela limite le Mac App Store à certains types d’applications plutôt grand public, mais admettez que cette solution est convaincante par sa simplicité.
À l’annonce du Mac App Store, j’ai pu lire ici et là qu’il s’agissait d’une bonne nouvelle, “les logiciels Mac étant trop chers” (sic). Voici l’avis partial d’un développeur Mac sur la question.
Sachez qu’à ce sujet, les discussions entre développeurs vont bon train sur le forum d’Apple. Un consensus semble pourtant se dégager: que l’application soit vendue au même prix sur l’App Store que sur le site de l’éditeur. C’est à dire que l’éditeur rogne déjà sur sa marge, à cause de la ponction de 30% des gains par Apple. L’App Store iOS est passé par là, et a démontré que l’intuition naïve de vendre à prix plancher en espérant se rattraper sur le volume n’avait fait le succès que de peu d’élus. Pourtant, certains croient encore vendre leurs applis ”sans marketing” du fait de leur seule présence sur l’App Store. L’expérience App Store iOS a totalement démonté cette théorie: il est inconcevable de vouloir vendre une appli iOS aujourd’hui sans avoir un bon plan marketing derrière, avec un site web dédié et de l’affiliation à tout va. Ceci dit, le prix moyen d’une application Mac va baisser: nul doute que nous allons assister à la naissance de nombreux ”crapwares” — ces logiciels aussi mal conçus qu’inutiles, qui pullulent au sein de l’App Store iOS. Même si Apple a durcit ses règles de validation sur cette plateforme.
Fixer le prix d’une application est difficile; d’ailleurs, il existe même des livres qui y sont consacrés. La première approche est de se dire que le coût de développement doit être couvert par les ventes. Ainsi, si vous mettez quatre mois à développer un logiciel, que vous vous payez 2000 € par mois (ce qui coûte réellement autour de 4000 € à la société), et que vous vous attendez à 1000 ventes, le juste prix serait de 4000 € x 4 mois / 1000 ventes = 16 € HT. Evidemment, ce n’est pas aussi simple. Déjà parce que tous les développeurs n’ont pas la même productivité, et surtout parce qu’évaluer le volume de ventes est impossible avant de lancer le produit. Si quelqu’un connaît une méthode d’évaluation valide, qu’il m’en fasse profiter, j’écrirai un bouquin et deviendrai riche.
Ensuite, parce que les logiciels ne se vendent pas tout seuls: j’ai fait moi-même l’erreur de le croire au départ. Votre logiciel aura beau être génial, il faut faire du marketing, sinon il passera inaperçu. Je consacre aujourd’hui un tiers de mon temps à cette activité. Si vous suivez toujours le raisonnement sur le prix de vente, il faudrait donc vendre le logiciel un tiers plus cher, soit 21 € HT.
Le calcul du paragraphe précédent n’a aucun sens parce qu’il fait abstraction de la première règle du marketing:
Le bon prix est celui que le client est prêt à payer.
En y réfléchissant, cette règle est très logique: le client se fiche du temps passé à programmer l’appli. Il a un besoin (rationnel ou non) à satisfaire. Si le prix ne lui paraît pas déraisonnable, il achètera. De fait, la réflexion doit porter sur la découverte de ce prix raisonnable, pour lequel nombre de paramètres entrent en jeu: les prix de la concurrence, la qualité perçue, les moyens du public visé, etc.
Prenons le problème par l’autre sens: la culture du store iOS est de vendre à prix plancher: à quatre euros, une application paraît déjà chère! De fait, une stratégie adoptée avec succès par certains est de consacrer le minimum de temps au développement et de miser sur le marketing.
En conclusion, on en revient au problème du coût de développement: le prix actuel des logiciels Mac permet la réalisation de logiciels ambitieux en termes de qualité et de fonctionnalité. En ce sens, la baisse des prix ne serait pas forcément une bonne nouvelle pour les utilisateurs.
Si vous lisez ce blog, vous savez sans doute qu’Apple a annoncé mardi la disponibilité prochaine d’un Mac App Store, qui permettra d’acheter, de télécharger et d’installer automatiquement les logiciels sur son Mac. J’ai l’intention de rendre PortraiMatic disponible par ce canal (qui — ne nous méprenons pas — va vite devenir incontournable), mais qui n’est pas sans poser de questions.
Ma première question est la part qu’Apple prélèvera sur les transactions. La boutique équivalente pour iOS prélève 30% de commission: c’est élevé, comparé à mon système de paiement actuel, basé sur Kagi, qui prélève environ 15% (et qui est déjà cher). Je serais obligé d’augmenter le prix du logiciel, ma marge étant déjà peu élevée.
Ma seconde question est si le magasin, à l’instar de son homologue sous iOS, permettra les achats ”in-app” (à l’intérieur de l’application). Ceci pourrait ouvrir de nouvelles perspectives commerciales.
Ma dernière question, qui n’en est pas une, est qu’il faudrait que je maintienne deux versions:
ou alors, si je pouvais faire toutes mes ventes par l’App Store:
Cette deuxième solution offre l’avantage de la simplicité, mais pose un autre problème: PortraiMatic est compatible avec Mac OS 10.5. Devrais-je abandonner cette compatibilité ? Nous devrions y voir plus clair lors du lancement de la boutique en décembre.