iPhone OS 4.0 : Vent de panique pour les SDK alternatifs

Nonoche |
Les nouvelles conditions d'utilisations de l'App Store ont beaucoup fait parler d'elles au sujet de Flash CS5 (et à vrai dire les conditions existantes ne lui étaient déjà guère favorables, lire : Et si Apple refusait les applications Flash ?), mais le logiciel d'Adobe est loin d'être le seul moyen alternatif de développer des applications pour iPhone.

Un vent de panique a traversé les forums consacrés aux différents environnements de développement, leurs utilisateurs s'inquiètent de savoir si leurs projets risquent d'être remis en question. Il est en effet difficile de trancher, la formulation d'Apple dans ses nouvelles règles pouvant être sujette à interprétation.

Ce dont on peut être certain, c'est que les environnements de développement qui permettent de créer une application pour iPhone sans passer par un projet Xcode en Objective-C sont désormais interdits par Apple. C'est le cas de Flash CS5, alors qu'Adobe s'apprête à le mettre sur le marché (lire : Flash sur iPhone : comment ça marche ?). Mais qu'en est-il des autres ?

Unity permet de développer des jeux en 3D pour iPhone, et il est possible de programmer en utilisant 3 langages : JavaScript, C# et Boo (une sous-catégorie de Python), qui s'appuient tous trois sur des bibliothèques .NET grâce à Mono. Il faut passer par Xcode pour compiler les applications créées avec cet environnement de développement, mais il faut malgré tout inclure le runtime Mono. Un développeur rapporte sur le forum que lors de la validation d'une application réalisée avec Unity, l'équipe d'Apple lui a indiqué qu'il était recommandé de ne pas utiliser des API externes. Si son application a malgré tout été validée, l'anecdote semble indiquer que Unity est bel et bien concerné par ces changements.

Précisément, Novell propose également un kit de développement Mono dédié à l'iPhone, MonoTouch, qui sans surprise offre le support de C# et des bibliothèques .NET. MonoTouch s'appuie sur Xcode mais en ajoutant un FrameWork C#, qui risque donc de poser problème.

Garage Games propose avec son moteur Torque de créer des jeux pour iPhone. Les sources sont fournies et compilables avec Xcode.

PhoneGap permet de créer des applications en utilisant JavaScript et HTML. La société a réagi sur Twitter : « Que tout le monde se détende au sujet de la nouvelle politique. Les applications PhoneGap sont acceptées par Apple. »


Corona permet de programmer à l'aide du langage script Lua. Son éditeur, Ansca Mobile, indique sur son blog : les applications créées avec Corona sont entièrement traduites en Objective C/C++, il n'y a aucune inquiétude à avoir selon Ansca Mobile.

ShiVa, tout comme Corona, utilise le langage de script Lua pour créer des jeux en 3D. Son éditeur, la société StoneTrip, a simplement répondu de « ne pas s'inquiéter » sur son forum.

Appcelerator Titanium permet d'utiliser les technologie du web (HTML, CSS, JavaScript, Python, Ruby) pour créer des applications pour iPhone. Pour l'heure la société reste quelque peu dans l'expectative, en indiquant que rien n'est encore gravé dans le marbre tant qu'iPhone OS 4.0 n'est pas disponible, et qu'elle compte travailler avec Apple pour s'assurer qu'elle respecte à la lettre ses exigences.

GameSalad est un environnement de développement dédié aux jeux qui ne nécessite pas de programmation. Si le logiciel permettait dans un premier temps de créer un projet Xcode, ça n'est plus le cas depuis la version 0.6.1, qui fournit directement une application compilée sans utiliser Xcode. GameSalad fait donc partie des logiciels directement visés par les nouvelles conditions d'utilisation, mais son éditeur a tenu à rassurer ses utilisateurs sur son forum:

« Nous sommes en train de digérer l'information, mais je tenais à vous faire savoir que nous sommes à l'écoute. Pour le moment nous avons trois choses à dire :

1) Nous sommes en train d'étudier la question
2) Nous ne pensons pas que ça sera un problème
3) Nous sommes futés

Je ne manquerai pas de revenir vers vous pendant que nous nous penchons sur ce problème. »



Les circonstances varient d'un cas à l'autre, et il faudra probablement que certains environnements s'adaptent à cette nouvelle donne, en espérant qu'aucun n'arrive dans une impasse. Ceci étant, en appliquant à la lettre la formulation des termes du contrat, les applications doivent être écrites originellement en Objective-C, C, C++ (le JavaScript est également autorisé mais uniquement s'il est exécuté par le moteur WebKit interne à l'iPhone), et non passer par un "traducteur", ce qui concerne la majeure partie des environnements concernés. Malgré ce que les différents acteurs peuvent en dire, on n'aura de confirmation effective qu'en jugeant sur pièces si Apple valide ou non les applications réalisées avec leurs kits de développement. Quoi qu'il en soit ce sont pour ces outils et leurs utilisateurs des mois de travail qui sont dans la balance.
avatar elamapi | 

@bugman.

Tes bibliothèques de fonctions,juste avant d'être une librairie binaire a loader, c'est bien du code non ? Xcode peut donc les recompiler aussi non ? Ton argument à ce sujet n'est donc pas recevable.

En ce qui concerne le compilateur qui pourrait pondre un binaire plus optimisé, tu as tout a fait raison. On "devrait" pouvoir choisir. Seulement voila, c'est choix stratégique.

Est ce qu'on ferme tout, on blinde tout pour assurer un maximum d'homogénéité et de stabilité, quite a fruster certaine personne (politique par defaut d'apple) ou est ce qu'on ouvre les vannes, on autorise tout pour supporte le plus de techno possible et toucher le plus de gens possible ?

Les deux choix sont viable: Microsoft s'en sort tres bien, et apple aussi. Et perso, je suis ravi de cet état de fait.

Je ne souhaites pas qu'apple s'ouvre plus que ça. Si je choisi apple, ce n'est pas pour l'ouverture, mais pour l'homogénité, pour la stabilité et pour la convivialité.

Je sais que je ne pourrais pas faire certaine chose que d'autre peuvent faire nativement ou avec quelque bidouille. C'est un choix.

Sinon, je serais resté sous windows ou revenu sur linux.

avatar daito | 

je remets :

John Gruber a produit sur son site l'analyse qui me semble la plus intelligente. En clair il dit entre autre à juste titre qu'Apple ne veut pas que d'autres plateformes de développement viennent surplomber Cocoa Touch pour ainsi garder l'attractivité de la plateforme pour les développeurs.

Il souligne aussi le fait qu'Apple, là encore avec raison, veuille garder le contrôle sur sa plateforme de manière à ce que les nouvelles fonctions proposées soient directement utilisées (et donc pas dépendre des autres pour l'implémentation d'une nouvelle fonction dans une application développée avec une plateforme alternative).

Enfin il discute les conséquences pour les différents acteurs, d'Apple à l'utilisateur. En particulier pour l'utilisateur il a un argument pertinent. C'est vrai que le développement "Cross-plateform"n'a pas été signe de grande qualité pour les plateformes d'Apple, spécialement sur Mac (le plus bel exemple est justement Flash). Donc un développement unique en Cocoa Touch sur l'iPhoneOS est indéniablement un gage de qualité des applications proposées à l'utilisateur. C'est l'avis de Gruber, je suis d'accord avec ça.

Il illustre d'ailleurs son propos avec un bel exemple : l'application Kindle d'Amazo. Sur Mac OS X, c'est vrai, elle n'est pas terrible alors que la version iPhone est de très bonne qualité. Bien l''application Mac OS X a été développée avec le framework Cross-plateform Qt toolkit alors que l'application iPhone avec CocoaTouch. À méditer!!

http://daringfireball.net/2010/04/why_apple_changed_section_331

avatar bugman | 

@ elampi : En cherchant un peu sur le store je trouverais bien aussi des applications soit écrites avec les pieds, soit avec une interface douteuse ou de mauvais gout (pourtant utilisant le SDK Apple). Concernant les sources à compiler avec XCode, là est tout le "problème" (note les guillemets). Je pense (mais je me trompe peut être), les devs offrant un moyen alternatif de coder sur iMachin n'ont jamais eux les sources des Api Apple.
A noter (c'est important), je n'ai rien contre le SDK Apple, je pense juste aux petites structures qui n'ont pas une armé comme EA (par exemple) et qui veulent que leurs jeux (ou applications) soient facilement portés sur plusieurs plateformes.
En ce qui me concerne, les applications je les teste. Si elle est efficace (marche correctement et est agréable), j'achète (qu'elle soit écrite en C en Basic voir en Logo, je m'en contre fous).

avatar Nicosun | 

Je ne suis pas spécialiste mais il me semble qu'Apple rationalise sur ses appareils, c'est tout. Quand je vois les portages bidons de jeux fait sur certaines consoles. Je préfère plus d'exclu et moins de quantité.

Il y aura peut être moins de devs sur l'appstore et encore, mais apparemment on va gagner en qualité, stabilité et homogénéité à terme.
Il y a des gens comme moi qui sont chez Apple pour la simplicité et la stabilité, il suffit de comprendre que ce genre de confort d'utilisation implique des règles (comme par exemple on achète pas l'iphone si l'on ne peut vivre sans flash).

avatar Micout | 

@crakou : pour ce qui concerne RunRev, Kevin Miller le CEO m'a indiqué ce matin qu'il entretenait de très bonnes relations avec Apple et qu'il entamait des discussions pour trouver une solution permettant de sortir Rev Mobile comme prévu... à suivre...

avatar notorious_hanz | 

Moi a la place d'adobe je reporterais les versions mac a venir de toutes ses applications comme ça on verra bien. pas de flash 10.1, pas de CS5 sur mac, etc... Vous serez tous bien content :-)
Sinon ce serai marrant aussi que Google ne permette pas a Safari d'accéder a ses services pour une question d'homogénéité.

avatar françois bayrou | 

"pourquoi les developpeurs sont venus par légions, parce que la plateforme est solide (fiable, complète, fonctionnelle) et l'environnement cocoa est ultra-complet"

Non.
Le SDK sous Mac est tout aussi solide, est ce qu'il a eu le même succès ?
Ils sont venus parce que la plate forme - l'iphone - fait un carton, c'est tout !

avatar Ast2001 | 

Je ne suis pas tout à fait certain qu'Apple ait mesuré la portée de son geste. Ce ne concerne pas que Flash mais aussi tout ceux qui veulent faire d'une façon ou d'une autre du multi-plateforme.

C'est en train de devenir totalement hallucinant et commence à relever un peu de la psychiatrie :) . Et je trouve aussi dément les commentaires de ceux qui défendent systématiquement les actes d'Apple sans réfléchir une seconde et qui prennent pour argent comptant tous les propos de S. Jobs.

avatar lukasmars | 

"Moi a la place d'adobe je reporterais les versions mac a venir de toutes ses applications comme ça on verra bien. pas de flash 10.1, pas de CS5 sur mac, etc... Vous serez tous bien content :-) "

Jamais Adobe ne fera ça , d'abord parce la clientèle Mac pirate peu et que vu le prix de ses softs, Adobe se priverai de dizaines ( centaines ) de millions pour une guerre stérile .
Les dirigeants de Adobe sont moins irréfléchis et sanguins que Jobs qui adore se trouver des meilleurs ennemis.
En plus Adobe à le beau rôle et laisse Jobs se couvrir de ridicule avec ses positions extrémistes , ils disent "nous on a bossé pour ameliorer Flash sous Mac mais Jobs ne veux pas en entendre parler ".
Celui qui prend sa clientèle en otage, c'est Jobs.
C'est bien plus fin mais la finesse, il ne connait pas l'autre bouffeur de pommes.

avatar cloudy | 

Ce billet m'a fait mourir de rire à ce sujet :

[url]http://blog.joa-ebert.com/2010/04/09/what-apple-just-did/[/url]

avatar lukasmars | 

"Musician: Well but I do not like GarageBand. I would like to use Ableton Live.
Apple: Sorry but you are not allowed to use that.
Musician: But it is suited very well for electronic music.
Apple: Use GarageBand then. It is a magical and amazing product!"

C'est exactement la réponse que Jobs a donné a un type qui demandais si picasa serai dispo sur l'Ipad," Iphoto est meilleur " lui a t il répondu ...

avatar Francois Simond | 

daito :

Je comprend assez mal qu'un développeur dise

"Je préfère qu'Apple me prive de choix d'environnement de développement.
La concurrence diminuerai l'attractivité de la plateforme ."

[i]Quoi ?[/i]

A part pour se rassurer d'avoir fait un choix moins pire que ceux qui risquent de voir des mois de travail jeté à la poubelle, ça ne peut pas être une analyse intelligente !
Plutôt le résultat d'un syndrome de Stockholm ?

Je vois par ce nouveau mouvement de la pomme qu'ils cherchent à enfermer autant leurs développeurs que leurs clients.
En tant que développeur, j'apprécie pas...

A mon avis, ce nouveau revirement suit la démonstration d'AIR sur iPad, qui allait de manière très logique devenir le standard pour publier tout ce qui est magazine sur iPad + tablettes Android + tablettes Windows + autres tablettes exotiques.

En effet, avec des compétences déjà présentes, un développement multi-plateforme et plutôt adapté à la logique métier, je vous laisse imaginer la part de marché qu'AIR allait se tailler en un temps record.

Risque pour Apple, c'est pas sûr qu'Apple arrive à forcer tous ces magazines risquer de gaspiller des ressources pour du tout X-Code/Objective-C.
Au contraire, on verra + de HTML5, et ils percevront 0%, c'est pas bien malin !

avatar daito | 

[quote]En effet, avec des compétences déjà présentes, un développement multi-plateforme et plutôt adapté à la logique métier, je vous laisse imaginer la part de marché qu'AIR allait se tailler en un temps record. [/quote]

Entre les faits réels et le discours généraliste qui ne repose sur pas grand chose, il y a un monde. Encore une fois le développement cross-plateform n'est pas synonyme de qualité. Il y a de nombreux d'exemples sur Mac et Gruber donne un exemple pertinent avec l'application Kindle MacOSX/iPhone OS.

[quote]Je vois par ce nouveau mouvement de la pomme qu'ils cherchent à enfermer autant leurs développeurs que leurs clients.
En tant que développeur, j'apprécie pas... [/quote]

Tu n'apprécies pas. La solution est très simple, va développer ailleurs. La situation est simple pour les développeurs. Ceux qui utilisent Xcode n'ont aucun soucis à ce faire et cette nouvelle règle ne change rien. Pour les autres qui veulent faire de l'exotique, la porte est grande ouverte, Apple n'oblige pas les développeurs à accepter leurs conditions. Toi perso tu n'apprécies pas, tu sais maintenant ce qu'il fait faire.

[quote]Risque pour Apple, c'est pas sûr qu'Apple arrive à forcer tous ces magazines risquer de gaspiller des ressources pour du tout X-Code/Objective-C. [/quote]

À mon avis, si l'iPad est un gros succès, le tout Xcode ne leur posera aucun problème.

avatar Leehalt | 

Perso, cette nouvelle règle d'Apple me fait tiquer car elle réduit la liberté des développeurs, et au final des utilisateurs. La toute première intervention de bugman tape dans le mille.
Mais de toutes façons, Jobs et Apple sont pragmatiques : ils tentent le forcing dans la beta du SDK iPhone OS 4 et si ça passe, tant mieux. Par contre si les développeurs lèvent bien haut leurs boucliers et protestent de façon virulente contre cette nouvelle règle, eh bien il suffira d'assouplir/supprimer la règle au moment de sortir la version finale. Faut pas rêver.

avatar daito | 

[quote]Perso, cette nouvelle règle d'Apple me fait tiquer car elle réduit la liberté des développeurs,[/quote]

Apple ne réduit pas la liberté du développeur. Apple dit juste que sur l'iPhone, les développeurs ont toute la liberté de développer ce qu'ils veulent mais avec CocoaTouch. Sinon, je n'ai pas trop compris en quoi ces nouvelle règles réduisent la liberté de l'utilisateur.

[quote]Par contre si les développeurs lèvent bien haut leurs boucliers et protestent de façon virulente contre cette nouvelle règle, eh bien il suffira d'assouplir/supprimer la règle au moment de sortir la version finale. Faut pas rêver.[/quote]

L'iPhone+iPodTouch, c'est un marché de 85 millions d'appareils (et l'iPad arrive). Je ne pense pas que les développeurs concernés vont "lever leurs boucliers" mais juste se mettrent au boulot!

avatar notorious_hanz | 

@lukamars on verra mais si Apple/Jobs les poussent a bout ...on ne sait jamais
Ce qui est con c'est qu'Adobe avait commencer a faire un effort en annoncant des améliorations pour flash 10.1
Moi qui voulait tester Openframeworks pour iphone c'est foutu je crois.

avatar bugman | 

@ daito : La liberté de développer UNIQUEMENT sur les machines Apple, nuance. Le développement sur plusieurs plateformes (facilement) est aujourd'hui mis au rebut par Apple (si j'ai bien compris), c'est soit nous, soit les autres, point barre. Au niveau de l'utilisateur ? Heu (autre sujet mais ça montre bien la politique de l'entreprise quand même) : alors Opera sur téléphone portable, t'en penses quoi, bien ? (ou il vaut mieux que je demande à un utilisateur d'Androïd ?) Voila tout est dit. Maintenant, si tu trouves ça plus intéressant pour l'utilisateur et pour le dev... oui, pourquoi pas.

avatar daito | 

[quote]La liberté de développer UNIQUEMENT sur les machines Apple, nuance. Le développement sur plusieurs plateformes (facilement) est aujourd'hui mis au rebut par Apple (si j'ai bien compris), c'est soit nous, soit les autres, point barre. [/quote]

développer uniquement sur les machine Apple......et??? C'est quoi le problème???
Encore une fois, au niveau de l'utilisateur, c'est l'expérience qui le démontre. Il est tout à fait compréhensible qu'Apple saisisse l'opportunité avec l'iPhone OS d'imposer que leur plateforme de développement CocoaTouch quand on voit ce que le développement cross-plateform a produit sur Mac. Plus les raisons que j'ai évoqué dans ma première réaction.

[quote]alors Opera sur téléphone portable, t'en penses quoi, bien ? [/quote]

J'en pense quoi??? Bien déjà, pourrais-tu me spécifier précisément ce que je dois penser au sujet d'Opera. C'est quoi le sujet?

avatar Zoidberg | 

daito: "Apple dit juste que sur l'iPhone, les développeurs ont toute la liberté de développer ce qu'ils veulent mais avec CocoaTouch" t'es certain du 'ce qu'ils veulent'? ou alors par "ils" tu veux dire Apple?

avatar bugman | 

@ daito :

Le problème (point 1) : Disons que des sociétés veulent peut être développer pour plusieurs plates-formes et qu'Apple dû coup les empêche de le faire facilement.

Point 2 : concernant Opera, j'ai pris ça pour exemple vu que tu as parlé du niveau utilisateur. Je lance iTunes (faut vérifier un minimum quand même)... Je tape "Opera" dans le moteur de recherche... je cherche dans les apps... et rien, pas de navigateur. Recherche sur internet... site opera.com... rien pour l'iPhone. Ils ont pourtant fait une demande de validation pour leur browser sur l'AppStore.

Alors le sujet ? Et bien simple : La politique Apple nuit-elle à l'utilisateur final ? Perso, j'aime bien Safari, mais j'aime encore plus avoir le choix. Pour les devs de l'application je n'en parle même pas (et si ça tombe ils ont même utilisé le SDK Apple, c'est dire)... Normal d'après toi ?

avatar daito | 

1) Apple empêche les sociétés de développer pour plusieurs plateformes?? Ahh bon?? Apple impose juste de développer pour l'iPhone en utilisant CoCoaTouch. Apple n'empêche pas aux développeurs de développer pour d'autres plateformes avec d'autres outils.

2) Opera. Pourtant j'ai essayé d'explique ce point sur ce site. En fait il s'agit spécification de l'application OperaMini, on est d'accord. Avec OperaMini le rendu des pages est réalisé sur un serveur proxy (donc le problème de l'obligation d'utiliser Webkit ne se pose pas). Par contre, justement le code "cross-plateform" était écrit en Java que l'iPhone ne supporte pas.
Donc pour permettre à OperaMini de fonctionner sur l'iPhone, il suffisait de récrire l'application en Cocoa/Objective-C. C'est ce qu'ils ont fait je pense avec l'application soumise à l'AppStore il y a quelques temps?
L'application n'est pas dans l'AppStore car elle encore en cours de validation. Pour l'instant elle n'a pas été rejetée. Donc je ne vois pas vraiment pourquoi tu cites le cas d'Opera pour argumenter tes propos.

avatar daito | 

@Zoidberg,

Come on...combien d'applications sont rejetées par Apple et combien acceptées?

avatar bugman | 

@ daito :

1) Rien en effet (manquerait plus que ça tiens). Mais Apple, aujourd'hui, [b]oblige[/b] à un choix ou le double de temps (ou pas loin) de travail pour le dev (voulant du multi). Pourquoi ? (moi quand on [b]impose[/b] ça fait comme un "tilt"... mais c'est moi, je sais.)

2) Pour Opera on en reparle dans quelques temps. Pour moi Opera ne passera pas (sinon, ce serait déjà fait... et puis c'est oublier Safari). On en reparlera plus tard donc... mais quand on voit qu'un utilisateur (moi) se pose la question et qu'un éditeur pose un compteur sur son site y'a de quoi se poser des questions sur la position de son (comment dire) fournisseur de materiel...
Alors passera, passera pas ? Le flou ! (mais c'est cool...made in Cupertino)

avatar daito | 

1) Pour le pourquoi, je t'invite à relire ce que j'ai écrit plus haut ou lire l'analyse de Gruber :
http://daringfireball.net/2010/04/why_apple_changed_section_331
Ensuite, je considère pas l'argument du "le développeur a plus de boulot" comme un argument valable. Si le développeur veut son app dans l'AppStore il se met au boulot et apprend CocoaTouch (il verra c'est merveilleux).
Enfin, l'AppStore est à Apple. Apple a donc le droit d'imposer ses conditions comme de nombreuses choses nous sont imposées dans la vie dans de nombreux domaines.

2) Encore une fois, il existe de nombreux autres navigateurs dans l'AppStore qui utilisent Webkit et qu'Apple accepte. Dans le cas d'OperaMini, comme le rendu des pages se fait sur un serveur proxy et comme j'imagine l'appli n'a plus de code Java, je pense qu'elle sera acceptée.

Pages

CONNEXION UTILISATEUR