iPhone OS 4.0 : Vent de panique pour les SDK alternatifs
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.
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.
Apple distibue les cartes et annonce les blindes. Les joueurs autour de la table se couchent ou suivent...
Bon WE !
…la juste contrepartie de l'ouverture du multi-tâche aux applications tierces.
En même temps, si ces dévellopeurs ont tenté leur coup avec leur propres kit de devs, ils devaient bien avoir conscience du côté bancal de leur projets. Sinon ils sont bien naïfs, rien qu'à voir le jeu du chat et de la souris pour le jailbreak.
Contourner les règles fixés par n'importe quelle entreprise lorsqu'on bosse avec elle, c'est courir le risque qu'elle cesse de passer outre et qu'elle commence à serrer la vis.
C'est une politique contestable qui a longtemps été reproché a Microsoft. Le manque d'interopérabilité avait failli tuer le mac dans les années 90. Attention au retour de pelle.
Cette politique me parait risquée. Certains développeurs risquent d'en avoir marre d'Apple et de sa politique et vont se rediriger vers Android. Quand je lis qu'avec l'OS4, "apple veut maintenir son avance", je constate surtout qu'elle essaye de rattraper son retard sur Android. (multitask, folders...). Si l'interface d'android est d'une laideur à toute épreuve, le boulot fait par HTC est superbe. Je reste fidèle à l'iPhone pour le moment mais cet été, je regarderai la concurrence avant d'acheter. Idem pour une éventuelle tablette.
@Hal-9000:"Les joueurs autour de la table se couchent ou suivent..."
Ah ah. Ce qu'on constate surtout c'est qu'ils veulent suivre...contrairement à Brewenn ou Lossendae qui annonçaient des défections devant de nouvelles conditions plus drastiques.
C'est que ça rapport tout ça l'Appstore.... ;)
@Minus:"Cette politique me parait risquée. Certains développeurs risquent d'en avoir marre d'Apple et de sa politique et vont se rediriger vers Android."
Bizarre, ce n'est pas ce qui ressort de ces premières réactions.
@Psylo:" Le manque d'interopérabilité avait failli tuer le mac dans les années 90"
C'est sûr, l'interopérabilité des SDK, c'est vraiment crucial...ah ah.
Mais quelle blague...
A minus : perso j'ai un android et un ipod touch je trouve pas l'android plus môche au niveau de l'inface comme quoi les goûts et les couleurs...
Qu'en est-il de RunRev ?
Apple se rend moins compétitif.
Il est plus dur de développer un jeu en faisait le scriptage en C++ qu'en javascript, et le scriptage des jeux ne joue pas sur les performances quand on a un moteur 3D qui tourne à coté. Il sera plus dur de développer sur iPhone,et les jeux seront moins bien. Tout les jeux utilise le scriptage, apple est folle d'aller contre ca.
Apple chez a enfermer ses développeurs en les obligeant à faire des programmes non multi plateforme.
> Psylo
"attention au retour de pelle".
Je ne connaissais que la version "manivelle". :-)
@ Shenmue
Je pense que pas mal d'entre eux (voir la quasi totalité) suivront effectivement, vu le pot à rafler...
c'est bien.
je n'apprécie pas ces environnements multi-plateformes commodisés qui sont natifs nul part
cela va des applications java à QT ou mono/.net ou autre.
c'est aussi une manière de dévoyer Cocoa et XCode en faisant des logiciels une fois pour android/winmo/iphone, mais ils ne seront nul part des logiciels qui exploitent aux mieux les choix de chaque plateforme.
le blougi-boulga, c'est l'une des raisons qui expliquent pourquoi sous linux y a pas _1_ GRAND environnement à apprendre pour faire de BEAUX logiciels mais 30 000 bricolages + ou - complets et des docs à moitié complètes
j'exagère ? allez lire gtk-ruby ou les docs bindings python pour gnome. et bien entendu compiler un logiciel mono/.net avec winforms (fonctionnel sur windows donc) ne permet pas d'utiliser les aspects les plus modernes de Gnome (ubuntu si vous préférez)
mais vous me direz tout le monde s'en moque.
-
Windows. Ha mais je m'excuse, mais faire du delphi, du visual basic, du MFC ou du win32 en C, puis maintenant .net ou les milliards d'outils alternatifs pour pondre un programme windows + ou - intégré c'est ce qui a donné la bouillie informe que sont les logiciels windows.
Même au sein de microsoft, selon le kit qu'ils ont utilisé (.NET n'est _PAS_ MFC ) ca donne des choses différentes, qui ont accès à + ou - ce que le dernier windows offre.
Cela dilue la qualité et cohérence de la plateforme au final.
-
alors oui encore une fois, je l'assume, j'aime la radicalité d'Apple. c'est la radicalité que j'espérais dans le monde linux ou que j'aurais aimé que Microsoft impose (oui impose, genre MS Visual studio dev 2012 fournisse que .NET pour faire des logiciels modernes) avec la modernité de .NET/C#. Mais non ce n'est pas le cas. le blougi-boulga contiinue, et seul Apple tente de cadrer les développements sur sa plateforme.
Peu m'importe la motivation derrière (argent, pouvoir, sex.), quand l'outil est BON et MARCHE.
Je suis pas venu ici depuis un moment et je vois que ça ne change pas. On n'a toujours les même acteurs avec les même phrases de mise en garde, limite menace , contre la politique d'Apple. Ça fait des mois que vous nous la ressasser et qu'elle n'a aucune application. Bien au contraire puisque le nombres d'applications ne cesse d'augmenter. Ça doit vraiment vous empêche de dormir. Enfin on est pas inquiet on sait que ça fonctionne parce que nous ne sommes que des moutons. Vous avez jamais penser que dans le brouhaha de l'informatique et du net ou la filouterie et la feignatise pouvait exasperer plus d'une personne ?
Apple mets de l'ordre dans son jardin fermé. Personne ne vous à obligé a rentrer dedans. C'est pas parce que ça vous déplait que c'est de même pour nous. Il y aura toujours des utilisateurs mac quoique vous en dites ou pensiez. Apple le sait très bien et continue sur sa lancée. Peut importe que le reste ne comprennent pas.
On parle ici de SDK
d'outils d"ingénierie, pas d'interopérabilité pour lire des documents ou communiquer en réseau.
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
y a une classe pour quasi tout.
En concurrent, je ne vois que Java Enterprise pour être encore + complet (mais infiniment + mal fichu).
De fait, dans le cadre de cocoa, vous avez tout qui est déjà étudié et qui profite de près de 20 ans de maturation. Et apple s'en sert pour promouvoir ses choix d'interfaces, ses innovations ou ce qui différencie l'iphone de la concurrence.
C'est donc très important que les développeurs utilisent le cadre officiel pour que leur programme soit très "'iphonesque" (ou ipadesque ou mac-esque ), cela renforce la différenciation et l'intégration verticale des logiciels et de la plateforme qui est la principale qualité des solutions Apple.
Sans cela, si tous les programmes étaient plus ou moins bricolés pour marcher sur iphone, mais aussi semblable qu'un programme windows du jour, que pourrait apporter une solution apple ? un appareil en alu ? ce n'est PAS suffisant !
L'intégration logiciel-matériel est la grande force d'apple pour justifier son commerce.
et on y gagne : L'outil de développement est bon, les logiciels sont de qualité, il est très cohérent et bien documenté. Apple est encouragé à développer continuellement sa plateforme et la moderniser.
On y perd python et sa jungle ou ruby et sa steppe chaotique ? tant mieux. Sinon, y a Android et ses javaseries. On pourra faire de la cross-compilation Haskell-C-java dessus... youhou... via un script bash/cygwin trouvé dans un forum obscure.
-
On a beau dire, mais les développeurs vont vers Cocoa et qu'ils aient des regrets de pas pouvoir utiliser python comme Joe Hewitt ne change rien : le cadre de développement est tellement bon et complet qu'il éclipse tous les pleurs des passionnés de langage
et quand à ceux qui disent que "le manque d'interopérabilité a failli tuer apple", en rappelant le passif de apple avec le Mac.
je tiens à signaler que apple fait avec l'iphone et ipad (et dans une moindre mesure avec le mac _depuis_ mac os X et cocoa) la politique contraire à celle du mac en 1984.
Oui, Apple est radical, et oui ça marche. Ils n'ont jamais eu autant de passions et de gens autour de leur plateforme.
@ Nesus
Et pan sur le bec, comme sous-titre un certain journal, de certains !
Je te rassure tout de suite, il y a six mois ils râlaient car Apple ne mettait dans dans ces machines des cartes graphiques à la hauteur selon eux !
Il y a un an c'était contre la politique tarifaire des applications et il y a deux ans c'était contre je ne plus quoi !
Et demain cela sera sur le bouton rose bonbon (il faut bien rêver parfois) mis sur la gauche plutôt que sur la droite du nouveau Mac.
Cela me rappelle quand était sorti l'iBook G3. Cela râlait et pas qu'un peu, car le lecteur de disquette n'était pas présent ! Depuis ? ce choix judicieux a donné raison à Apple.
Alors ..... laissons les "coser". Ils s'occupent !
Drôle de politique quand même. Obligé d'utiliser un SDK particulier, payant (abonnement annuel) avec plein de trucs sympa dedans, mais que l'on ne peut pas utiliser comme tu veux ("je te donne un core animation mais t'es gentil tu ne copies pas coverflow). Tu développes ton application mais si j'aime pas, tu vas te gratter pour la voir sur notre store. Et puis t'es gentil, si on te permet de la mettre tu nous donne xx% de ton travail (et demain iAd obligatoire ?) Au fait c'est quoi ton application ? Un browser... Heu, non désolé va te gratter on en a déjà un... suivant...
Génial, la politique Apple, ça donne vraiment envie.
Encore une fois, je ne vois pas trop ou est le soucis ... il suffit que lesdits SDK ne "compilent" pas eux même le code, mais le génère pour le faire compiler a Xcode.
Que ce soit le SDK toto qui génère le printf "hello world"; ou que ce soit vous qui le tappiez directement, personne ne verra la différence.
Par contre, les optimisations apporté au code compilé par un compilateur unique, dédié et optimisé pour la plate-forme apple, ca, ça va se vois.
Ok donc si j'ai bien compris tous vos arguments (à part oomu) y'a tout un tas de devs qui sont de gros incompétents, qui utilisent des environnements de développement *sales*, qui n'ont donc de fait aucune raison valable ou légitime de gueuler contre cette nouvelle politique d'Apple.
Vivement le retour de l'Amiga et de l'Atari.
au moins sur amiga on ne me prenait pas le chou parce que j'utilisais K-Seka.
@psylo, faut pas exagérer non plus, sinon on en serait toujours à coder en assembleur.
Disont qu'il ne faut pas voir tout blanc ou tout noir.
Les SDK pourront toujours exister, faut juste qu'ils ne compilent pas eux même ... c'est pas la mort non plus hein ...
Sinon faire des appli en HTML/CSS/JAVASCRIPT c'est toujours faisable ou c'est mort ?
J'ai vu des bouquins sur ca a la FNAC, c'est deja "has been" ?
Un SDK c'est avant tout des bibliothèques de fonctions elamapi. (et leurs docs). si quelqu'un sort un compilateur faisant du code plus optimisé que ce que fait apple (= application plus rapide, meilleur gestion de la mémoire) qu'on il le droit de dire ? Demain, pour mon Mac je serais obligé d'acheter des applications de certains éditeurs seulement (suivant le bon vouloir de Jobs) ? On est parti pour... De quel droit ?
@ imonamac
Si tu veux investir dans l'avenir apprend Perl...
(je blague hein ! :x)
@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.
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
@ 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).
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).
@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...
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é.
"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 !
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.
"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.
Ce billet m'a fait mourir de rire à ce sujet :
[url]http://blog.joa-ebert.com/2010/04/09/what-apple-just-did/[/url]
"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 ...
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 !
[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.
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.
[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!
@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.
@ 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.
[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?
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?
@ 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 ?
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.
@Zoidberg,
Come on...combien d'applications sont rejetées par Apple et combien acceptées?
@ 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)
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.