Clause 3.3.1 : RunRev se concentrera sur Android

Anthony Nelzin-Santos |
skitchedKevin Miller, le PDG de RunRev, a réagi à la clause 3.3.1 de l'iPhone OS SDK, qui barre l'accès de l'App Store aux applications qui ne sont pas codées en Objective-C, C++ ou JavaScript. Une clause qui met en péril revMobile, l'environnement de développement multiplateforme de RunRev.

Miller revient d'abord sur les ambitions de revMobile, faisant de revTalk, le langage de programmation qu'il utilise, le fils spirituel d'HyperCard, l'environnement de programmation simple d'Apple. Comme revMovile utilise ce langage, il contrevient directement à la clause 3.3.1, un fait qui désole Miller, qui considère son produit comme un des environnements de développement les plus simples. Il pense qu'un projet visant à déployer des iPad dans des écoles au Malawi risque d'être remis en cause, car il ne pourra plus utiliser revMobile.

Pour se sortir de l'ornière, RunRev aurait proposé à Apple de modifier substantiellement leur logiciel en créant une version spécifique à l'iPhone, supportant 100 % des API de l'iPhone OS SDK, n'ayant aucun problème avec le multitâche ou la durée de vie de batterie, utilisant au départ une version modifiée de revTalk, ensuite traduit en code natif.

Apple aurait refusé — encore une fois, la clause 3.3.1 indique que les applications doivent être codées dès le départ dans un des trois langages autorisés. Miller fait d'ailleurs bien la différence entre les environnements de développement alternatifs qui utilisent Objective-C, C++ ou JavaScript, et les autres, dont le sien.

revMobile poursuivra sa route, même si les développements spécifiques à l'iPhone et l'iPad se limiteront à des corrections de bogues, et à l'ajout du strict minimum : c'est en effet vers Android que RunRev concentrera désormais ses efforts.

« Android est le PC du marché des téléphones et il est prévu qu'il dépasse l'iPhone et l'iPad », explique Miller, reprenant les chiffres qui indiquent que la part de marché d'Android a dépassé celle de l'iPhone OS, en oubliant cependant de préciser que cela n'était valable qu'aux États-Unis (lire : Android dépasse l'iPhone : Apple répond).

avatar Frodon | 
@NicolasO Pas la peine de me rappeler ce que j'ai parfaitement lu et qui d'ailleurs est a l'origine de ma réaction. Je ne suis pas aussi sûr que toi que cela soit interdit , ce qui est interdit c'est de compiler depuis du code dans un langage autre qu'Objective-C/C/C++, mais RunRev n'a pas fait valider une solution où le code serait d'abord transcrit en Objective-C, le framework serait lui écrit dès le départ en Objective-C, avant d'être compilé via XCode. En effet, la solution que runRev a proposé à Apple et qu'Apple a rejeté est une solution qui consistait à compiler le code revTalk en natif, sans passer par la case Objective-C, ni la case XCode. De ce fait, RunRev n'a même pas cherché à faire valider une solution où le framework serait en 100% Objective-C/C/C++ (sans traduction, développé réellement en Objective-C/C/C++), utilisant uniquement les APIs documenté, et le code de chaque projet serait transcrit en Objective-C et soit compilé via XCode (et uniquement XCode). Bref, avec un outils qui produirait du code originellement en Objective-C avant compilation via XCode. Etant donné que personne n'a fait valider ce type de solution, car je le répète ce que runRev a proposé à Apple n'ai pas cette solution, mais une solution qui compilait directement le code revTalk en code natif (donc sans passer par la case Objective-C, et pire sans passer par la case XCode), ce qui est évidement interdit. La clause est très clair la dessus, et je ne comprend d'ailleurs pas comment ils espéraient que cela passe. Et la solution que j'évoque personnellement n'a rien à voir avec la solution rejeté que RunRev avait proposé, et je ne vois pas ce qui rentrerai en désaccord avec la clause concernant la solution que je décris. Donc tant que personne n'aura fait validé ou non ce type de solution auprès d'Apple, on ne pourra pas affirmer que cela est interdit ou non.
avatar USB09 | 
@ frodon Sans doute, mais qui ne risque rien n'a rien. Si ça passe ils ont tout a gagné. Premièrement que les develloppeur qui passeront pas l'objective C, verrons mieux les outil d'Apple et feront de plus belle et meilleur appli. Et au final c'est mac OSX qui gagne.
avatar Frodon | 
@Usb09 Exactement ce que je dis. Sauf qu'ils ne vont pas tenter justement, ils ne veulent pas prendre le risque.
avatar Feroce | 
"Premièrement que les develloppeur qui passeront pas l'objective C, verrons mieux les outil d'Apple et feront de plus belle et meilleur appli." C'est bien connu, Objective C corrige les bugs de méthode.

Pages

CONNEXION UTILISATEUR