Oh non pas ça ... Quand on voit les améliorations qu'ont données le changement en natif pour Facebook, on peut pas facilité la création en HTML5 ...

Vivement la WWDC qu'on reparle un peu d'Apple , parceque la c'est que de Google qu'on parle ...

@chabodmathieu Le problème avec les applications natives est qu'elles doivent être écrites en Objective-C, ce qui ne facilite pas le portage sur d'autres plateformes. Il faudrait autoriser un autre langage comme le C++ par exemple.

Quand je vois le sort qu’a réservé Apple à sa page consacrée aux webapp : http://www.apple.com/webapps/whatarewebapps.html je doute de l’issue d’une telle initiative...

Ca, pour moi, ca sent clairement la tentative de rebouchage de brèche de la barque IOS pour contrecarrer la montée d'Android.

html5 serait vraiment une daube alors ? pour qu'il faille passer par du code natif

"Quand on voit les améliorations qu'ont données le changement en natif pour Facebook, on peut pas facilité la création en HTML5 ..." Oui enfin faut aussi dire que niveau html5, facebook avait aussi fait de la grosse merde. D'ailleurs, linkedin est passé au natif pour une raison principale, et ça a été dit par leur responsable : l'absence d'outils pour html5. Facebook a quand même réussi à se faire humilier par sansha, une petite boîte qui avec deux devs en quelques semaines a proposé une webapp facebook mille fois plus performante que l'app officielle, pour justement prouver à facebook que leur problème venait davantage de leurs devs et leur façon de coder n'importe comment que de html5... Mais bon, c'est même plus la question aujourd'hui, vu que les raisonnables s' accordent à dire qu'on va vers une complémentarité web app + app native.

@Jean-Jacques Cortes Rien ne vous empêche de publier une application iPhone en C ou en C++. Il y a même des outils pour les faire en Ruby …

le code natif est toujours supérieur à du code interprété en terme de vitesse (évidemment) et d'intégration dans la plateforme (par définition). Mais du code interprété/managé apporte certaines flexibilités. Mais voulons nous vraiment cette flexibilité ? Déjà qu'il faut se méfier des bugs de safari au cas où une escaladation de droits soit possible Avec du code natif, il faudra aussi se méfier des bugs du processeur. Je pense toujours que simplifier l'exécution de code binaire depuis internet est une erreur. C'est une jolie erreur pour l'ingénieur, c'est beau et pratique. C'est une catastrophe pour l'utilisateur à terme. (faille de sécurité, perversion/dévoiement de la plateforme). Du code binaire chargé depuis le net est essentiellement une boite noire -- "Le problème avec les applications natives est qu'elles doivent être écrites en Objective-C, ce qui ne facilite pas le portage sur d'autres plateformes. Il faudrait autoriser un autre langage comme le C++ par exemple. " en quoi c'est un problème pour Apple ? c'est même carrément un avantage. Non, il ne faut pas "autoriser" C++ D'abord, il est "autorisé". Si vous avez un compilateur/environnement de développement basé C++ qui génère du code pour le runtime Objective C alors ça passe. Notons au passage que cela n'est pas si facile : Objective C est compatible C. Par nature : objective C est une extension de C. Objective C n'est PAS compatible C++. C++ est un dérivé de C, mais il n'est plus du C. Objective C a été une force pour Apple, pas un boulot. En 15 ans le nombre d'applications Objective C a _explosé_. Ce n'est pas sans raison. Objective C et Cocoa sont plus que liés, ils sont fondamentaux l'un à l'autre. Le runtime Objective C met en oeuvre des concepts de base sur lesquels Cocoa est bâti. en gros: ils vont ensemble et Xcode met en oeuvre cette synergie. Du coup, quand on dit "objective C", on parle surtout de la force de cocoa. et Cocoa va bien au delà de C++/lib standard c++/QT/MFC/etc.

Ce que demande Apple, et pour de solides raisons dont nous profitons tous, c'est que des apps sur ios soient conçues pour la plateforme applicative COCOA (donc le runtime objective C en dessous). Apple ne veut pas se retrouver comme pour Os X responsable de maintenir la compatibilité des applications de tierces parties avec des plateformes applicatives de tierces parties (en vrac: java, qt, silverlight, flash, python, ruby, etc) chaque fois qu'elle veut améliorer ios et proposer de nouveaux usages. Apple veut pouvoir faire progresser IOS et Xcode sans considération pour les plateformes de concurrents. ET que les développeurs soient du coup incités à suivre les "merveilleuses nouveaux outils" de Cocoa du nouvel ios. Steve Jobs avait été très clair sur comment la dépendance à une plateforme applicative d'une autre entreprise est un danger pour Apple. Son propos se tient encore en 2013. - Cela est aussi vrai pour Os X, où tout serait nettement + simple s'il suffisait d'ajouter à Cocoa le support des Versions de Documents pour que PAF ! Photoshop ou Office le gère aussi, d'un coup, magique. Apple lentement, se débrouille pour rendre Cocoa _nécessaire_ sur Os X.

@Armas : D'où ça sort ? De quelle "brèche" tu parles ? IOS est toujours le terrain de jeu préféré des développeurs et le marché qui leur rapporte le plus. La majorité des devs développent d'abord pour iOS avant de passer par Androïd. Y a peut-être plus de tel Androïd en circulation mais les payeurs sont sur iOS. Par ailleurs, une webapp est bien plus limitée qu'une App native en terme d'accès système, donc je ne vois pas les devs abandonner le native pour du Web... Ton fantasme n'est pas près de se réaliser.

Quand je pense qu'il y a encore des Gus pour se persuader que si Apple n'a pas accepté Flash sur iOS c'était pour protéger l'Appstore des jeux gratuits... C'te vaste blague quand même...

@oomu "Objective C n'est PAS compatible C++" C'est totalement faux! Personnellement, toutes mes Apps iOS sont écrites en Objective C++. Pour cela, il suffit de renommer les fichier source .m en .mm et le compilateur accepte le code C++. De plus, le compilateur clang qui est celui utilisé par défaut dans XCode 4.6 est compatible avec les dernières nouveautés de C++ 11 qui vient d'être finalisé. Jusqu'à récemment, il était difficile d'inclure des objets C++ dans un objet Objective C, car les constructeurs et destructeurs n'étaient pas appelés lors de l'initialisation de l'objet Objective C. Ce n'est plus le cas actuellement. Avec l'utilisation de ARC qui simplifie la gestion de la mémoire du côté Objective C, le mélange des deux langage est un délice. Je dirais que l'intégration des deux langages est presque parfait. Je m'attends à ce que les dernières limitations disparaissent dans XCode 5. Il est vrai que la documentation à ce sujet est lacunaire. J'utilise Objective C pour réaliser les interfaces utilisateur et l'accès aux ressources systèmes puisque les APIs ne sont disponible que dans ce langage, mais pour le reste, j'écris tout en C++. On pourrait guerroyer en mode croisade durant des siècles sur les mérites respectifs des différents langages, mais il faut rester pragmatique et utiliser ceux qui sont le mieux adaptés à la plateforme pour laquelle on programme, soit C# pour windows, Java pour Android et Objective C++ pour iOS / OS X.

@oomu : +1 et +1 ;) Et ça à commencé au début des années 90 avec NEXTSTEP !. "The piece of software the most respected in the World". (d'une avance considérable à l'époque !) Etudiant à cette époque, quel panard j'ai pris à utiliser Objective-C, Interface-Builder (toute mon admiration à JM Hullot mon Frenchy préféré) / Project Builder (Xcode d'aujourd'hui) et l'Application Kit. Alors que dans le même temps le c++ m'ennuyait profondément... Petit moment de nostalgie ;-)

Ca attirerait simplement plus de développeurs, donc plus d'apps.

@ricky mclane Je compatis avec les difficultés que tu as rencontré en programmant en C++ durant la dernière décennie du précédent millénaire, car je les ai vécues aussi. Il est vrai qu'à l'époque, objective C était plus facile à utiliser, car les concepts majeurs de C++ tels que l'héritage multiple étaient très très mal implémentés par les compilateurs. Mais la situation a beaucoup évolué depuis et C++ a atteint sa pleine maturité et n'a plus rien à envier à Objective C, bien au contraire. Il y a bien un concept majeur de Objective C qui est absent de C++, c'est celui de delegate/protocol. J'ai longtemps trouvé que ce serait cool de pouvoir utiliser ce concept en C++. J'ai fini par construire l'équivalent à l'aide d'une classe C++ très simple et de quelques #define. Le résultat est tout a fait comparable à ce qu'offre Objective C, mais en mieux, grâce à l'héritage multiple et aux fonctions virtuelles. Il faudra bien qu'un jour, je me décide à documenter cette classe et que je la publie sur le web, mais je suis si paresseux.

@KrummenHacker : J'avoue bien humblement que je ne me suis plus jamais intéressé au C++, et veux donc bien croire qu'il a bien évolué sur divers aspects tant syntaxiques que conceptuels même si je reste très dubitatif sur le paradigme de l'héritage multiple qui semble séduisant sur le principe (au même titre que la surcharge des opérateurs) mais un vrai "sac de nœud" dans certaines circonstances.

Effectivement je developpe beaucoup en Objective C++ aussi. Par contre perso je n'utilise pas ARC et j'utilise aussi des bibliotheques C et c'est la qu'on voit le b*rdel que ca peut etre de gerer la memoire C/Objective C/C++ dans un meme programme.

@ricky mclane Les cas d'usage necessaire de l'heritage multiple sont tres rares. C'est vraiment le truc a eviter dans la majorite des cas. De toute maniere objective-C et C++ ne repondent pas aux memes contraintes et comme toujours en informatique il s'agit d'utiliser le bon outil pour resoudre le bon probleme.

@robrob Alors, si la gestion de mémoire d'Objective C te paraît un b*rdel, ce que je confirme, il faut absolument que tu essaies ARC! J'ai personnellement mis plus d'une année avant de tenter l'expérience, tant j'étais effrayé par la perspective de devoir revoir tout mon code. Lorsque j'ai fais le pas, ça ma pris quelques heures pour corriger tous les retain et release que le compilateur refusait désormais. Il m'a fallu revoir certaines bidouilles que j'avais dû faire pour contourner des contraintes désormais obsolètes de compatibilité avec C++ (probablement du genre de celles que tu mentionnes). Le résultat est un code bien plus simple et propre. Les fuites de mémoires ne sont plus que de mauvais souvenirs. Je ne reviendrais pour rien au monde en arrière, tu comprendras pourquoi une fois que tu auras franchi le pas. Le temps perdu à convertir les projets existants est amorti très rapidement, tant ARC facilite le travail.

@ricki mclane La surcharge des opérateurs? Pour des raisons de compatibilité multi plateforme et de performances (NSString est très mauvais pour des chaînes de caractères très longues >100KB, j'utilise une classe de gestion de chaînes de caractères maison (je n'utilise pas du tout la librairie standard de C++) qui répond à mes besoins particuliers. La surcharge de l'opérateur = me permet de convertir entre NSString et ma propre classe de manière totalement implicite. Ce n'est qu'un exemple parmi tant d'autres. La surcharge d'opérateur est justement une des fonctionnalités de C++ qui me facilite son intégration avec Objective C.

@KrummenHacker C'est surtout le melange des modeles memoire qui est b*rdelique. Chacun pris a part c'est simple. Un exemple utiliser des objets d'OpenCV melanges avec de l'objective C et des bibliotheques non objective C necessitant les C*ObjectRetain et Release. Pas insurmontable juste penible que ce soit pas un peu mieux unifie.

@robrob Ben justement, avec ARC, tu ne te préoccupes plus de retain, ni de release, ni de autorelease, etc. À quelques exceptions près (CGRef etc.), je dois l'admettre. Mais dans ces quelques rares cas, le compilateur te le signale lors de la conversion vers ARC. Ah! Évidemment, un objet alloué en C++ avec new doit quand même toujours être libéré par un delete. Ça, ça ne change pas. C++ 11 introduit aussi des smart pointers, mais je n'ai pas expérimenté. Faudra que j'essaie un jour.

J'utilise les smart pointers au boulot mais pas dans mes projets persos. Juste en raison de la taille qui ne le justifie pas sinon c'est comme ARC, c'est pratique. Le probleme est bien les CGRef et autres combine aux new/delete, combine a ARC ou non-ARC. D'ailleurs je comprends toujours pas pourquoi on a toujours autant de bibliotheque en C et non objective-C.

RubyMotion fait mieux que tout le monde... C'est la meilleure solution du moment pour passer outre l'objective-c

La multiplicité des plateformes est un véritable casse-tête, mais elle génère aussi un énorme business. Une multinationale ou une grande entreprise a les moyens de développer des Applications pour différentes plateformes, mais cela a un coût. Pour le fun, nous avons développé une application sur iPhone. C'était instructif, mais elle aurait aussi pu être écrite sous la forme d'une WebApp (HTML/CSS/JS). Par contre, s'il faut l'adapter à Android, ce sera un peu la galère pour notre petite équipe. Comme le dit l'un d'entre vous à chaque problème son langage. Objective-C est très fort parce qu'il répond nativement à certains "design-patterns", rien n'empêche du reste d'écrire des morceaux de code dans d'autres langages (C, C++, etc.). Il y a donc des intérêts contradictoires entre ceux qui veulent développer pour du multiplateforme de façon rapide universelle (et même si franchement le trio infernal évoqué plus haut n'est pas extraordinaire en termes de performance et de clarté, il a le mérite d'être le seul à offrir cette possibilité) et les éditeurs/constructeurs qui veulent rendre les utilisateurs captifs tout en ayant la plus grande part de marché.

@robrob PER-FOR-MAN-CES! Répète avec moi: PER-FOR-MAN-CES! Apple a beau mettre en avant les performances d'Objective C, appeler une méthode dans un langage dynamique ou l'existence de la méthode est évaluée à l'exécution restera toujours beaucoup plus coûteux que d'appeler une fonction à une adresse définie à la compilation. C'est la principale justification du maintien de librairies C telles que OpenCV, CoreGraphics, etc.

Cette histoire de passage de Facebook d'une app hybride vers du natif est soit 1) une légende 2) soit un manque de compétence de la part des Dev de Facebook. Car Sencha a reproduit l'app de Facebook avec leur propre Framework à base d'html et de Javascript et le résultat est identique à la version native. Chercher dans votre moteur de recherche: Sencha et fastbook De plus pour info de nouveau moteur font leur apparition pour améliorer js et même des Frameworks Javascript vont dans ce sens également . Je vous invite à regarder la demo de http://famo.us Cela dit, Je suis d'accord que du C est plus rapide que du code interprêté. Il y a tout de même de belle avancé...

@ KrummenHacker : « C++ a atteint sa pleine maturité et n'a plus rien à envier à Objective C, bien au contraire. » Euh… si, tout de même. Ce qu'il peut le plus envier à Objective C / Cocoa (comme dit plus haut, les deux sont indissociables), c'est une syntaxe simple, légère et très claire (ce dont C++ s'éloigne de plus en plus). Mais aussi une orientation facilitant énormément l'approche « duck typing ». Une syntaxe permettant de distinguer explicitement la déclaration d'un comportement (via les protocoles) et la déclaration de l'adoption d'une implémentation d'un comportement (via l'héritage). Bref, principalement clarté et simplicité d'utilisation — tout devient si vite bordélique en C++. À côté de ça, il peut encore envier des trucs pratiques comme les catégories, ou un modèle de gestion de la mémoire qui était déjà, en mode « semi-automatique », bien plus pratique que celui de C++ et qui est devenu encore plus un plaisir grâce à l'ARC.