Blogue

3.3.9

Michael Tsai, en conclusion de son billet sur les implications de la section 3.3.1 du nouveau iPhone Developer Agreement, demande « Quel sera le prochain changement aux règles ? » Ça n’aura pas été long. MacStories viens tout juste de dévoiler la section 3.3.9, qui banni la collecte de données statistiques.

  • All use of User Data collected or obtained through an Application must be limited to the same purpose as necessary to provide services or functionality for such Application. For example, the use of User Data collected on and used in a social networking Application could be used for the same purpose on the website version of that Application ; however, the use of location-based User Data for enabling targeted advertising in an Application is prohibited unless targeted advertising is the purpose of such Application (e.g., a geo-location coupon application).

  • You may only provide or disclose User Data to third parties as necessary for providing services or functionality for the Application that collected the User Data, and then only if You receive express user consent. For example, if Your Application would like to post a message from a user to a third party social networking site, then You may only share the message if the user has explicitly indicated an intention to share it by clicking or selecting a button or checking a box that clearly explains how the message will be shared.

  • Notwithstanding anything else in this Agreement, Device Data may not be provided or disclosed to a third party without Apple’s prior written consent. Accordingly, the use of third party software in Your Application to collect and send Device Data to a third party for processing or analysis is expressly prohibited.

Ça semble bien pour préserver la vie privée des gens. Essentiellement, ça interdit aux développeur de collecte de statistiques sur les habitudes des utilisateurs, sauf pour les besoins légitimes de communication de l’application.

Ça interdit aussi la communication de données de l’appareil (« device data ») à une tierce partie. Mon interprétation est qu’un développeur peut collecter des statistiques sur par exemple la version du iPhone OS utilisé (seulement quand l’application a à communiquer avec le serveur du développer pour des raisons légitimes) mais ne peut dévoiler ses statistiques à quiconque.

Je ne suis pas un fan des sites web, applications ou des firmes de publicité qui collectent des informations sur mes habitudes sans mon consentement, donc d’une certaine façon je ne peux pas être tout à fait contre ces règles. Je trouve cependant que le non-dévoilement à de tierce partie des données de l’appareil un peu restrictive : il n’y a rien de mal à communiquer des statistiques intéressantes.

Malheureusement, j’estime qu’Apple ne s’en tiendra pas aux même standards (Apple n’est pas une tierce partie dans cet accord). Si une application utilise les iAds d’Apple, vraisemblablement vous aurez droit à des publicité ciblés selon votre emplacement géographique, et des données seront collectés par Apple sur vos habitudes. Ces données pourront ensuite être attachés à votre compte iTunes. Et d’une certaine façon c’est pire pour votre vie privée : quand plus en plus de développeurs passeront aux iAds, toutes ces informations seront concentrés dans les mains d’une seule compagnie : Apple.

AdMob (appartenant maintenant à Google) et les autres services de publicité mobiles (MediaLets, MobClix) seront les plus affectés par ce changement. Bien qu’il n’empêche pas d’autre firmes d’offrir un service de publicité, la valeur de leur publicités risque d’être diminué par ces règles.

Et évidemment, les services tiers de statistiques (Flurry, SimpleGeo) sont maintenant complètement bannis. Peut-être les statistiques feront-t-elle partie des iAds, mais je suis pas mal certain qu’Apple ne laissera pas ces données s’échapper très facilement.


Dommages collatéraux

Le SDK du iPhone OS 4.0 apporte beaucoup de nouvelles fonctionnalisées à la plateforme, il amène aussi un nouveau iPhone Developer Agreement. John Gruber de Daring Fireball fait remarquer que la nouvelle section 3.3.1 de cet accord banni tout ce qui n’est pas originellement écrit en C, C++ ou Objective-C :

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

On y lit clairement qu’il n’est plus permis de développer pour iPhone OS avec le langage de son choix. Ceci rend inutile le compilateur Flash d’Adobe qui était presque prêt — et c’était probablement le but — mais ça empêche aussi l’utilisation d’autre langages dans les jeux et les applications qui pourrait en bénéficier. Essentiellement, Apple dicte les outils pour la création non seulement de l’interface utilisateur, mais du « back-end » du logiciel.

Michael Tsai en fait la description parfaite :

Leaving aside the question of whether it’s reasonable to ban cross-platform applications rather than let customers decide whether they’re useful, I worry that this new regulation will also affect native applications. There are a variety of reasons that a developer might want to leverage other languages (either at build time or runtime) for code reuse, libraries, or development speed and power. Consider, for example, an AI or game engine written in Lisp that compiles down to ARM assembly or C.

Et ne peut qu’être d’accord Hank Williams sur ce point :

Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not “originally” written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is INSANE.

Steve does not want to allow Adobe’s tools to be able to generate compiled code for the iPhone. But with this additional twist he doesn’t even want Adobe to be able to generate objective-C which is then compiled by Apple’s tools. The ridiculousness of specifying the manner in which one writes their code is hard to understate.

C’est complètement insensé. Si j’ai à écrire un parseur pour mon application, est-ce que je peux l’écrire avec Lex/Yacc ? Non, parce que même si ces outils ne font que générer des petits bouts de codes en C à partir d’une grammaire, ce n’est pas du code écrit en C à l’origine. Qu’en est-t-il pour les expressions régulières ? Que dire d’une routine optimisé avec du code assembleur ?

Et comment peuvent-il faire respecter cette règle ? Avec suffisamment d’« inlining » dans le code compilé, il n’est pas vraiment possible de dire dans quel langage il a été écrit à l’origine. Certainement, certain cas seront évidents, mais dans beaucoup de cas ça va passer sans se faire remarquer.

Mon impression est que les règles de ce genre ne sont là que pour donner un semblant de cohérence. On sait déjà qu’Apple se réserve le droit de refuser une application pour n’importe quelle raison, et même de les enlever après approbation. Une règle qui interdit pratiquement tout mais qu’il n’est pas possible de faire respecter de façon cohérente est une bonne façon de justifier des décisions arbitraires sans avoir à dévoiler la vrai raison.



iPhone+iPad DevCamp à Québec, rétrospective

Hier, j’ai participé au DevCamp organisé par Mirego, et j’y ai fait une présentation sur l’utilisation de contenu audio dans une application iPhone. La soirée comprenait 11 présentations au total, environ 15 minutes chacune, et beaucoup d’opportunités pour jaser avec les autres participants.

Lors de ma présentation, j’ai parlé d’Asounding et son développement lors du portage de Tumiki Fighters. J’ai vu des commentaires sur Twitter disant « on veux plus de code », mais j’ai de la difficulté à savoir si ça se rapporte à ma présentation (ce qui se pourrait vu l’heure où ils ont été posté) ou par rapport à la soirée en général. Dans tous les cas, le code est disponible sur le site web d’Asounding si ça vous intéresse.

Toujours selon les commentaires sur Twitter, plusieurs personnes semblent avoir été déçu du manque de présentations à caractère technique. Il faut dire qu’avec une soirée qui convient à la fois aux experts en communication, aux développeurs web et aux développeurs d’application native, c’est difficile de faire une présentation qui plait à tout le monde.

En tant que présentateur d’un sujet « technique », j’ai trouvé la limite de 15 minutes un peu contraignante. Le code et les détails intéressants viennent généralement après une introduction du sujet ; en 15 minutes je n’ai pu que faire un survol plutôt rapide lors de ma présentation.

D’ailleurs, si vous êtes intéressés par les diapos de ma présentation (PDF, 305 Ko), vous les avez maintenant.

Pour un prochain événement, placer les présentations techniques en après midi, et le reste en soirée, pourrait être une bonne idée. Et idéalement ça se ferait la fin de semaine pour permettre une plus grande participation durant la journée. J’aurai peut-être quelque chose d’autre à présenter alors…



  • © 2003–2024 Michel Fortin.