Les SDK alternatifs toujours dans l'expectative
Les réactions aux nouvelles règles d'Apple concernant le SDK d'iPhone OS 4.0 continuent d'arriver (lire : iPhone OS 4.0 : vent de panique pour les SDK alternatifs).
GarageGames propose une version dédiée à l'iPhone de son moteur de développement de jeux, Torque Engine. Celle-ci était donc susceptible d'être visée par les nouvelles règles d'utilisation d'Apple.
Le producteur associé de la version iPhone du Torque Engine, Michael Perry, s'est dit confiant : « Notre moteur source, qui est complètement ouvert pour nos licenciés, a été écrit dès l'origine en C++. Nous avons une couche dédiée à la plateforme iPhone, qui est entièrement écrite en Objective-C. Les deux parties du moteur sont liées l'une à l'autre, sans aucune couche intermédiaire. A tout moment les programmeurs peuvent accéder directement aux API native du SDK iPhone. On ne peut pas faire plus direct que ça » a-t-il déclaré lors d'une interview pour iGameRadio.
Cependant Perry n'a pas eu confirmation de la part d'Apple que son moteur serait sain et sauf. Dans l'éventualité du contraire, GarageGames se dit prête à s'adapter.
De son côté, Unity Technologies a publié sur son blog un billet qui se veut rassurant, bien qu'il n'élude pas le pire : signé du PDG et co-fondateur de la société, David Elgason, le texte reconnait que selon l'interprétation la plus stricte des nouvelles règles d'utilisation d'Apple, nombre de produits pourraient se voir interdits d'App Store, mais il souligne également que les termes étant sujet à interprétation, Unity pourrait tout aussi bien s'en sortir indemne.
Unity indique faire son possible pour en savoir plus auprès d'Apple, mais n'a pour l'heure aucune réponse. Cependant la société souligne que son outil d'authoring a fourni des centaines, voire des milliers de jeux à l'App Store, dont un nombre conséquent s'est fort bien vendu, et elle n'imagine pas qu'Apple puisse vouloir se passer de cette force. Cependant il serait irresponsable de garantir une issue heureuse, et Unity Technologies se contente de promettre de faire tout son possible pour remédier au problème et de tenir ses utilisateurs informés dès qu'elle aura obtenu de nouveaux éléments.
Quoi qu'il en soit, la situation est particulièrement inconfortable pour les utilisateurs de ces SDK, qui ignorent le sort qui sera réservé à leurs projets en cours. Une épée de Damoclès qui est inhérente à ce mode de développement, comme ne manque d'ailleurs pas de le rappeler David Helgason. Précisément, même si Unity devait passer entre les mailles du filet, le mal est fait : ses utilisateurs savent dorénavant qu'Apple pourra encore changer ses règles à l'avenir, et que le seul moyen d'avoir un minimum de garanties est d'en passer par les outils bénéficiant de l'aval de la firme de Cupertino.
GarageGames propose une version dédiée à l'iPhone de son moteur de développement de jeux, Torque Engine. Celle-ci était donc susceptible d'être visée par les nouvelles règles d'utilisation d'Apple.
Le producteur associé de la version iPhone du Torque Engine, Michael Perry, s'est dit confiant : « Notre moteur source, qui est complètement ouvert pour nos licenciés, a été écrit dès l'origine en C++. Nous avons une couche dédiée à la plateforme iPhone, qui est entièrement écrite en Objective-C. Les deux parties du moteur sont liées l'une à l'autre, sans aucune couche intermédiaire. A tout moment les programmeurs peuvent accéder directement aux API native du SDK iPhone. On ne peut pas faire plus direct que ça » a-t-il déclaré lors d'une interview pour iGameRadio.
Cependant Perry n'a pas eu confirmation de la part d'Apple que son moteur serait sain et sauf. Dans l'éventualité du contraire, GarageGames se dit prête à s'adapter.
De son côté, Unity Technologies a publié sur son blog un billet qui se veut rassurant, bien qu'il n'élude pas le pire : signé du PDG et co-fondateur de la société, David Elgason, le texte reconnait que selon l'interprétation la plus stricte des nouvelles règles d'utilisation d'Apple, nombre de produits pourraient se voir interdits d'App Store, mais il souligne également que les termes étant sujet à interprétation, Unity pourrait tout aussi bien s'en sortir indemne.
Unity indique faire son possible pour en savoir plus auprès d'Apple, mais n'a pour l'heure aucune réponse. Cependant la société souligne que son outil d'authoring a fourni des centaines, voire des milliers de jeux à l'App Store, dont un nombre conséquent s'est fort bien vendu, et elle n'imagine pas qu'Apple puisse vouloir se passer de cette force. Cependant il serait irresponsable de garantir une issue heureuse, et Unity Technologies se contente de promettre de faire tout son possible pour remédier au problème et de tenir ses utilisateurs informés dès qu'elle aura obtenu de nouveaux éléments.
Quoi qu'il en soit, la situation est particulièrement inconfortable pour les utilisateurs de ces SDK, qui ignorent le sort qui sera réservé à leurs projets en cours. Une épée de Damoclès qui est inhérente à ce mode de développement, comme ne manque d'ailleurs pas de le rappeler David Helgason. Précisément, même si Unity devait passer entre les mailles du filet, le mal est fait : ses utilisateurs savent dorénavant qu'Apple pourra encore changer ses règles à l'avenir, et que le seul moyen d'avoir un minimum de garanties est d'en passer par les outils bénéficiant de l'aval de la firme de Cupertino.
Ignorer les SDK et middleware c'est ignorer la complexité du dev moderne, apple se goure s'ils croient pouvoir interdire ces outils
"Ignorer les SDK et middleware c'est ignorer la complexité du dev moderne, apple se goure s'ils croient pouvoir interdire ces outils"
non, ils ont raison, pour éviter la recréation du Mac 84.
-
Apple se contre-fiche de créer une énième plateforme pour sauver le monde.
Il s'agit de protéger et favoriser l'éclosion autour de l'ipad/iphone de logiciels qui EXPLOITENT les avancées ou spécificité de l'ipad/iphone.
il est possible d'imaginer qu'apple assouplisse (pour le jeu vidéo) en autorisant l'inclusion dans un logiciel de runtime de scripting (typiquement LUA)
mais au delà, Apple va tout faire pour empêcher que l'ipad/iphone soit commodisé et invisible avec android/winmo/symbian dans une cross-plateforme.
_non_
Cela ferait perdre à Apple la possibilité de différenciation de son offre commerciale, cela encouragerait les développeurs à ne faire que pour le plus grand dénominateur commun ( et ce GDC, il est nul).
Voulez vous vraiment qu'apple continue à faire en boucle du Mac ? Ce Mac où Adobe par exemple n'a jamais trouvé de raison pour s'investir dans les avancées et évolutions du mac (voyez le temps qu'à mis CS pour passer à os X en natif, pour passer à intel ou exploiter cocoa et le 64b, de même avec MS office) préférant se limiter à ce que windows sait faire.
Apple profite de la synergie autour de cocoa/itunes store/iphone/ipad pour ne PAS recréer la situation du Macintosh de 1984.
Ils feront donc l'inverse de tout ce les hackers disent et feront tout pour torpiller les middlewares (le vrai nom de ces outils de créations cross-plateformes)
-
Ce n'est pas dans l'intérêt du consommateur et d'une industrie concurrentielle de se fracasser dans un monde de logiciel JAVA, AIR ou QT.
Dans le monde de l'entreprise, cela a donné les joies des logiciels JAVA (qu'on tente de matiner de web maintenant). et c'est pas la joie justement
-
le WEB est ce middleware futuriste, libre, ouvert, soutenu par tous (dont apple), et qui est hackable par le plus grand nombr
la "la complexité du dev moderne" ressemble furieusement à ce qui se faisait déjà dans les années 80 sans les icônes et outils de profiling agréables.
Il y avait déjà des middlewares et des rêve de panacées multi-plateformes.
le Torque Engine ne devrait pas être concerné.
Je pense que Apple vise plus les trucs du style Flash / Air / MonoTouch que des moteurs 3D du type Torque Engine (qui de plus est codé en ObjC / C++ et ne semple donc pas violé les règles) ou Unity.
Sinon pour le reste je rejoins totalement l'avis de oomu donc je ne m'étendrais pas plus :)
Voici une liste de jeux extrêmement populaires et leurs utilisation de SDK :
https://spreadsheets.google.com/ccc?key=0ApLAS6djiVwydGhJMmh1YjYwb0QzUDl6dEVzV1hwVnc&hl=en
Les jeux plein écran utilisant des widgets propres n'ont pas besoin d'utiliser les api graphiques widget apple; le middleware est obligatoire. on va pas demander aux game designer de perdre du temps a scripter en C.
Pour du logiciel utilitaire je comprend mieux, mais même avec des outils apple opéra fait des horreurs.
[i]Apple profite de la synergie autour de cocoa/itunes store/iphone/ipad pour ne PAS recréer la situation du Macintosh de 1984[/i]
Par contre pour le Big Brother de 1984, c'est bien parti !
Que pourrait-on dire d'une app fonctionnant à la Filemaker? (un moteur écrit en obj C et des fichiers scriptés par des utilisateurs pour leurs besoins et interprétés par ledit moteur). Comme une feuille Excel dans Office aussi?
o [13/04/2010 15:35]
Apple profite de la synergie autour de cocoa/itunes store/iphone/ipad pour ne PAS recréer la situation du Macintosh de 1984
Par contre pour le Big Brother de 1984, c'est bien parti !
Si je comprend bien il faudrait qu'apple soit toujours une sous-merde dont personne n'a que faire.
Les type d'adobe ont que des PC dans leur bureau. La CS, elle meme, a des icônes Windows dans les menu.
Tu préfères etre sur mac ou PC ? faudrait savoir.
Ce que demande Apple, c'est d'acheter des mac pour développer sur leur plateforme, ou est le mal ?
Ah ah, ici, il n'est pas question d'interdire les SDK ou les bibliothèques mais bien la compilation en dehors de XCode (ce qui est totalement ridicule). Ici le SDK peut être intégré à XCode puisque les utilisateurs ont le code source => no stress.