Au départ, Apple ne souhaitait pas ouvrir ses appareils mobiles aux développeurs tiers. L'entreprise avait dû céder devant une demande rendue visible par le succès du jailbreak, non sans imposer ses conditions. Apple voulait même garder l'entier contrôle sur ce qui était proposé sur l'App Store : chaque application devait donc être soigneusement analysée et approuvée avant d'être proposée sur le magasin.
Mais manifestement, Cupertino n'avait pas prévu un tel succès (lire : 100 millions de téléchargements sur l'App Store) : outre des temps d'attente très longs, plusieurs refus ont mis en valeur des décisions arbitraires de la part de l'entreprise. Et voici qu'un nouveau cas pose problème et cette fois, il n'est pas le fait d'un petit développeur, mais pas moins que de Google...
Google Mobile App [0.3.142 – Français – Gratuit] a fait sensation la semaine dernière en proposant une fonction de recherche par commande vocale (lire : Google : la recherche vocale avec votre iPhone). Mais pour offrir cette fonction, il semblerait que Google ne respecte pas les règles du SDK de l'iPhone...
La recherche vocale de Google innove non seulement par des résultats annoncés comme fiables (à condition d'avoir le bon accent...) mais aussi par une interface très simplifiée et intelligente. En effet, la recherche ne se fait pas en "tapotant" un bouton, mais en portant son iPhone à l'oreille. Il suffit donc d'un geste pour lancer une recherche, ce qui est une excellente idée et une bonne utilisation des capteurs de proximité présents dans l'iPhone.
C'est bonne idée, certes, mais comme le souligne John Gruber sur son blog, Apple n'a pas prévu que les développeurs utilisent cette fonction. Le kit de développement (SDK) mis à disposition des développeurs comprend une série d'API (interface de programmation en français : ce sont des sortes de briques utilisées pour bâtir un programme) publiques et documentées que les développeurs doivent exclusivement utiliser. Toutes les applications utilisant d'autres API sont censées être refusées.
Or John Gruber a découvert que Google utilisait une API non documentée, c'est-à-dire une API privée qu'Apple ne documente pas. Ces API sont éventuellement utilisés par Apple, mais pas par les développeurs et pourront disparaître ou être modifiées lors d'une mise à jour. C'est notamment le cas pour le capteur de proximité : les développeurs y ont accès, mais uniquement pour éteindre et bloquer l'écran, comme l'iPhone le fait lors d'une conversation téléphonique. Google a réussi à utiliser le capteur pour une action différente (déclencher le micro et enregistrer la commande de l'utilisateur), ce que ne permet pas le SDK. En faisant cela, Google contrevient aux règles qui accompagnent le SDK.
Apple avait prévenu dès le départ que toutes les applications vendues sur l'App Store seraient préalablement vérifiées. L'entreprise s'est toujours donné, par ailleurs, le droit de refuser toute application qui ne respecterait pas les règles du jeu. Or celle de Google ne les respecte clairement pas et est pourtant disponible sur l'App Store. Dès lors, trois hypothèses s'imposent :
Quelle que soit la raison, ce nouvel exemple témoigne, à nouveau, des problèmes liés au contrôle des applications. Ce dernier est bien trop opaque et devient contre-productif : il semble de plus en plus que les applications qui sont rejetées ou validées le sont un peu aléatoirement, comme si Apple, à la manière des contrôles de bagages dans les aéroports, contrôlait vraiment une application de temps en temps.
C'est en tout cas ce que semble indiquer ce nouvel épisode dans la série des refusés de l'App Store. Cette fois cependant, il ne s'agit pas d'un refus, mais d'une application qui n'aurait pas dû être acceptée. BdEmailer [1.1 – Français – 0,79 €] cherche à améliorer l'application mail native en proposant notamment un mode horizontal et des réponses rapides, ce qui n'a rien d'original. Mais la nouvelle version, disponible depuis quelques jours, comprend un serveur SMTP qui permet l'envoi et la réception de mails.
En clair, cette application duplique une fonction des iPhone et iPod touch. Or c'est justement pour cette raison — copier une fonction proposée par Apple — que des applications comme Podcaster (lire : Du rififi sur l'App Store) ou MailWrangler (lire : Apple a les ciseaux faciles) avaient été refusées.
Qu'Apple impose ses règles semble normal puisque, après tout, l'App Store est son magasin. Mais si elle impose des règles aux uns, elle doit absolument les imposer à tous, que ce soit pour un géant comme Google ou pour un petit développeur qui code à ses heures perdues ! La politique d'Apple devient tous les jours plus confuse au fur et à mesure que le nombre d'applications augmente. On peut comprendre qu'Apple soit débordée devant l'ampleur de la tâche, mais cela n'empêche pas d'être logique : soit l'entreprise décide d'imposer un réel contrôle et d'une part elle s'en donne les moyens (quitte à rallonger le processus, déjà long, de contrôle) mais surtout, d'autre part, elle définit clairement les conditions d'accès et s'y tient. Soit Apple décide d'arrêter totalement le contrôle et accepte toutes les applications.
Il semble évident que cette dernière solution n'est même pas envisageable. Dès lors, espérons qu'Apple se décidera à expliciter rapidement ses règles. C'est le seul moyen de rassurer les développeurs qui commencent à être inquiets : développer une application sans savoir si elle sera acceptée, ni avoir aucun moyen de le deviner, c'est autant d'argent potentiellement perdu.
Mais manifestement, Cupertino n'avait pas prévu un tel succès (lire : 100 millions de téléchargements sur l'App Store) : outre des temps d'attente très longs, plusieurs refus ont mis en valeur des décisions arbitraires de la part de l'entreprise. Et voici qu'un nouveau cas pose problème et cette fois, il n'est pas le fait d'un petit développeur, mais pas moins que de Google...
Google Mobile App [0.3.142 – Français – Gratuit] a fait sensation la semaine dernière en proposant une fonction de recherche par commande vocale (lire : Google : la recherche vocale avec votre iPhone). Mais pour offrir cette fonction, il semblerait que Google ne respecte pas les règles du SDK de l'iPhone...
C'est bonne idée, certes, mais comme le souligne John Gruber sur son blog, Apple n'a pas prévu que les développeurs utilisent cette fonction. Le kit de développement (SDK) mis à disposition des développeurs comprend une série d'API (interface de programmation en français : ce sont des sortes de briques utilisées pour bâtir un programme) publiques et documentées que les développeurs doivent exclusivement utiliser. Toutes les applications utilisant d'autres API sont censées être refusées.
Or John Gruber a découvert que Google utilisait une API non documentée, c'est-à-dire une API privée qu'Apple ne documente pas. Ces API sont éventuellement utilisés par Apple, mais pas par les développeurs et pourront disparaître ou être modifiées lors d'une mise à jour. C'est notamment le cas pour le capteur de proximité : les développeurs y ont accès, mais uniquement pour éteindre et bloquer l'écran, comme l'iPhone le fait lors d'une conversation téléphonique. Google a réussi à utiliser le capteur pour une action différente (déclencher le micro et enregistrer la commande de l'utilisateur), ce que ne permet pas le SDK. En faisant cela, Google contrevient aux règles qui accompagnent le SDK.
Apple avait prévenu dès le départ que toutes les applications vendues sur l'App Store seraient préalablement vérifiées. L'entreprise s'est toujours donné, par ailleurs, le droit de refuser toute application qui ne respecterait pas les règles du jeu. Or celle de Google ne les respecte clairement pas et est pourtant disponible sur l'App Store. Dès lors, trois hypothèses s'imposent :
- Google a demandé, et obtenu, l'autorisation à Apple pour utiliser cette API : John Gruber n'y croit pas. La demande n'aurait sans doute pas abouti, et de toute manière, l'API aurait alors été documentée et autorisée officiellement, ce qui n'est pas le cas à ce jour.
- Apple n'a pas vu que Google utilisait cette API non documentée. Cela semble assez peu probable quand on pense à l'énorme buzz créé par Google au moment de la sortie de l'application. La vidéo de présentation était très claire et les ingénieurs de Cupertino pouvaient très facilement constater que l'application s'arrangeait avec le SDK sans devoir en inspecter minutieusement le code (ou alors il faut s'inquiéter).
- Apple a bien vu que Google utilisait une API interdite, mais a laissé faire le géant d'Internet. Ce serait, après tout, bien possible, et ce, pour deux raisons. Soit parce qu'Apple ne veut (ou ne peut) pas froisser Google devenu, aujourd'hui, absolument incontournable. Soit parce que Google a, en quelque sorte, forcé la main d'Apple en annonçant, plusieurs jours avant la sortie de son application, la nouveauté, créant une grosse attente et obligeant l'entreprise à la pomme d'accepter. Cela expliquerait, peut-être, le retard de l'application par rapport au calendrier initialement prévu, ce qui serait le signe d'un débat en interne selon John Gruber.
Quelle que soit la raison, ce nouvel exemple témoigne, à nouveau, des problèmes liés au contrôle des applications. Ce dernier est bien trop opaque et devient contre-productif : il semble de plus en plus que les applications qui sont rejetées ou validées le sont un peu aléatoirement, comme si Apple, à la manière des contrôles de bagages dans les aéroports, contrôlait vraiment une application de temps en temps.
C'est en tout cas ce que semble indiquer ce nouvel épisode dans la série des refusés de l'App Store. Cette fois cependant, il ne s'agit pas d'un refus, mais d'une application qui n'aurait pas dû être acceptée. BdEmailer [1.1 – Français – 0,79 €] cherche à améliorer l'application mail native en proposant notamment un mode horizontal et des réponses rapides, ce qui n'a rien d'original. Mais la nouvelle version, disponible depuis quelques jours, comprend un serveur SMTP qui permet l'envoi et la réception de mails.
En clair, cette application duplique une fonction des iPhone et iPod touch. Or c'est justement pour cette raison — copier une fonction proposée par Apple — que des applications comme Podcaster (lire : Du rififi sur l'App Store) ou MailWrangler (lire : Apple a les ciseaux faciles) avaient été refusées.
Qu'Apple impose ses règles semble normal puisque, après tout, l'App Store est son magasin. Mais si elle impose des règles aux uns, elle doit absolument les imposer à tous, que ce soit pour un géant comme Google ou pour un petit développeur qui code à ses heures perdues ! La politique d'Apple devient tous les jours plus confuse au fur et à mesure que le nombre d'applications augmente. On peut comprendre qu'Apple soit débordée devant l'ampleur de la tâche, mais cela n'empêche pas d'être logique : soit l'entreprise décide d'imposer un réel contrôle et d'une part elle s'en donne les moyens (quitte à rallonger le processus, déjà long, de contrôle) mais surtout, d'autre part, elle définit clairement les conditions d'accès et s'y tient. Soit Apple décide d'arrêter totalement le contrôle et accepte toutes les applications.
Il semble évident que cette dernière solution n'est même pas envisageable. Dès lors, espérons qu'Apple se décidera à expliciter rapidement ses règles. C'est le seul moyen de rassurer les développeurs qui commencent à être inquiets : développer une application sans savoir si elle sera acceptée, ni avoir aucun moyen de le deviner, c'est autant d'argent potentiellement perdu.
