Dossier : les développeurs face aux nouvelles règles de l'App Store

Christophe Laporte |
Marche arrière toute ! Discrètement, début septembre, Apple annonçait un virage à 180 degrés vis-à-vis de son programme de développement iOS (lire : Clauses iOS : Apple redevient raisonnable). Plusieurs clauses, dont celle qui empêchait de compiler ses programmes avec autre chose que Xcode, ont été abandonnées.

Dans le même temps, Apple publiait une liste de conseils afin de rendre le processus de validation de l’App Store moins opaque (lire : Directives de l'App Store : passage en revue). Mais les développeurs, qu’en pensent-ils ? Pourquoi Apple a-t-elle opéré ces changements ? Vont-ils dans le bon sens ?

Pour le savoir, nous avons posé une série de questions à plusieurs développeurs iOS, qui ont souvent des avis tranchés et assez différents sur ces sujets. Voici les personnes que nous avons interrogées :

- Florent Morin de Kaeli Soft, à qui l’on doit entre autres Histoire de France, MonAutoEntreprise.com ou encore celle d’AvosMac. Ce petit éditeur a également réalisé un nombre important d’applications pour le compte de grands groupes.
- Matthieu Kopp de la société Aquafadas, à qui l’on doit de nombreux logiciels sur Mac et iOS. Sur cette dernière, elle a notamment développé Ave!Comics, un lecteur permettant de regarder des BD sur l’iPhone et l’iPad
- Raphael Sebbe de la société Creaceed auteur entre autres de Prizmo, un logiciel d’OCR disponible sur Mac OS X et iOS.
- Bruno Rousseau de la société pocketDEMO, à qui l’on doit le célèbre Dimensions, un logiciel qui transforme l’iPhone en boîte à outils.
- Ingénieur iPhone, Louka Desroziers est bien connu du monde Mac pour le logiciel Ecoute. Il a récemment développé Operations, une calculatrice simple et efficace pour iPad.



- Que pensez-vous de la décision d'Apple de revoir les clauses d'iOS ? Pourquoi Apple a-t-elle agi ainsi selon vous ?

Florent Morin : Au niveau de Kaeli Soft, nous avons senti le vent tourner il y a quelque temps. Apple, qui était jusqu'à présent assez flexible sur la qualité des applications, a commencé à en rejeter certaines sur leur contenu trop commun, voir même sur leur qualité ergonomique et fonctionnelle.

En clair, les deux technologies applicatives iOS ont vu leur rôle clairement défini :
- HTML5 pour la liberté de contenu et de qualité, liée au web.
- le SDK iOS, orienté performances et utilisation des fonctionnalités propres aux appareils Apple.

C'est bien beau de demander aux développeurs plus de qualité, mais encore faut-il pouvoir les aider : c'est ce qui a été fait en proposant gratuitement les vidéos WWDC aux développeurs enregistrés. Pour nous, la qualité s'en est vivement ressentie.



Ce que nous en pensons : merci Apple pour les efforts fournis au niveau du SDK iOS. Maintenant, il serait peut-être bien de travailler un peu plus sur HTML5, afin de laisser du travail à tout le monde.

Si Apple a réagi ainsi, c'est clairement pour se démarquer de Google et les autres. Elle a une force que les autres n'ont pas : des outils de qualité et une rigueur inégalée. Là où certains prônent la liberté, Apple prône la rigueur.

Du coup, les développeurs vont devoir s'améliorer s'ils veulent rester dans la course. Les autres n'auront qu'à aller chez Google. Je pense que la stratégie d'Apple est de se distinguer sur la qualité.

Louka Desroziers : C'est une décision qui m'inquiète énormément, et je pense qu'Apple a fait volte-face afin d'éviter plusieurs procès (notamment avec le cas Adobe).

Matthieu Kopp : C'est probablement du côté des moteurs de jeu qu'il faut chercher la réponse à cette question. Le développement de jeux est complexe et les outils auteur dans ce domaine sont d'une vraie aide et permettent de s'affranchir un peu de la technique pour se concentrer sur le gameplay et les univers graphiques. Des jeux très bien sont produits avec ces outils, en 2D comme en 3D. Je pense que c'est une très bonne chose que des outils comme Unity soient maintenant officiellement acceptés pour produire du contenu.

Bruno Rousseau : La possibilité d'utiliser des outils de programmation de tierces parties concerne surtout les développeurs de jeux, ce qui n'est pas mon cas. Xcode me suffit. En ce qui concerne les guidelines, elles ne font que clarifier ce qui existait déjà. Mon opinion, c'est qu'ils ont probablement reçu des pressions des studios de jeux. Apple mise trop sur le jeu vidéo pour ne pas écouter les studios, y compris les petits studios.

Raphael Sebbe : Principalement les autorités compétentes (Europe / FTC) qui les auraient obligés tôt ou tard à revoir leur approche. Il y a aussi l'évolution rapide des plateformes concurrentes qui forcent Apple à prendre du recul.

Apple est très à la marge de pratiques commerciales douteuses avec son processus d'acceptation/rejet. Même si on peut comprendre qu'ils veulent défendre la sacro-sainte "expérience utilisateur", cela dérape très/trop facilement. Les arguments de Steve sur Flash sont fondés, il suffit de regarder son évolution sur Android pour s'en convaincre. Mais en agissant de la sorte, ils imposent leur manière de voir les choses plutôt que de laisser le marché choisir, ils attirent le regard des autorités et ils pénalisent les autres toolkits (Unity...) qui peuvent apporter de réelles plus-values au SDK iOS.


- Est-ce que cela aura un impact sur la qualité des applications disponibles sur l'App Store, selon vous ?

Florent Morin : C'est évident : la qualité des applications sur l'App Store risque fortement d'augmenter.

Louka Desroziers : Pas vraiment. Actuellement, tout le monde peut se dire "développeur iPhone" grâce à tous les exemples et tutoriels que l'on trouve sur internet. En quelques jours, n'importe quel développeur n'ayant jamais touché a l'Objective-C peut réaliser un simple coussin péteur...

L'App Store attire surtout les personnes qui pensent pouvoir se faire de l'argent rapidement avec peu d'effort. Maintenant que l'App Store regorge de "crapware", je doute que leur nombre augmente encore plus vite avec cette nouvelle clause.

Matthieu Kopp : C'est difficile à dire. Il sera nettement plus facile de développer une application en utilisant un outil auteur comme Flash et on peut donc dire qu'Apple ouvre la porte à une nouvelle communauté de développeurs qui pourront accéder à l'App Store. Il y aura sûrement de très belles choses qui seront produites, tout comme il y aura des applications de moindre qualité. Mais c'est déjà le cas, et ce n'est un secret pour personne: il est possible de faire des applications horribles avec Xcode.



Apple va ajuster ses règles de validation pour éviter la prolifération d'applications de moindre qualité (cf les guidelines qui mentionnent des applications "inutiles", "redondantes", ne "proposant pas de divertissement de longue durée"). L'avenir le dira. En tout cas, Apple a fort à faire pour maintenir la qualité et la lisibilité de l'App Store. J'espère néanmoins que le maître mot sera la qualité et non pas la "sélection" sur des critères subjectifs.

Bruno Rousseau : Sur les nouvelles clauses, c'est certain qu'à terme, la qualité va s'améliorer, mais elles ne font que clarifier sur papier les procédures déjà existantes d'Apple. Cela fait des mois qu'Apple a resserré ses critères d'acceptation. Personnellement, je ne réagis pas comme certains développeurs (je pense une minorité bruyante) qui s'offensent de telles pratiques. Franchement, je fais partie de ceux qui sont d'accord avec cette phrase d'Apple "We have lots of serious developers who don't want their quality Apps to be surrounded by amateur hour."

Oui, Apple contrôle beaucoup, oui c'est arbitraire et non ce n'est pas démocratique. Et alors ? J'ai travaillé des années sur d'autres plateformes mobiles "démocratiques". Rien ne m'empêche d'y retourner, mais pourquoi je n'y retourne pas ? Parce que c'est mal fait, non contrôlé et plein d'applis de seconde ou troisième zone ... donc pas rentable.

Apple nous garantit (à nous développeurs) des revenus très décents, une plateforme stable, et un système de vente très, très pro. En échange, Apple demande que les développeurs "s'appliquent" et sortent quelque chose de vraiment réfléchi. Rien de choquant là-dessus. Ceux qui ne veulent pas de cela peuvent "démocratiquement" développer sur d'autres plates-formes.

Raphael Sebbe : Les jeux Flash sur Internet ont un certain succès, et qui, aujourd'hui, écrit encore lui-même son moteur de jeu ? Ça existe, mais c'est assez rare.



La qualité dépend surtout du développeur, pas vraiment de l'outil choisi. Il y aura peut-être des applications de moins bonne qualité (saccadées...), mais il est aussi possible qu'un subset de Flash soit bien optimisé pour iPhone. Combiné à des outils d'authoring puissants (Adobe), ce "Flash" permettrait d'obtenir certains types d'application de qualité. Et pas que Flash d'ailleurs. Ça ouvre de nouvelles portes, et ça, c'est bien.

- Concrètement, qu’est-ce que cela change pour vous ?

Florent Morin : Nous le voyons depuis plusieurs mois : nos dernières réalisations sont d'un niveau bien supérieur à celui des applications précédentes. Prenons un exemple concret : pour le Petit Économiste (en attente de validation, ndr), que nous développons maintenant depuis plusieurs mois, nous avons eu un premier rejet de l'application par Apple. Pas qu'elle soit moche, lente ou quoi : elle n'était pas assez originale.

Première réaction : l'agacement. Puis réflexion, formation à fond (merci la WWDC) et remise à plat du code. Résultat : l'application est maintenant plutôt originale (des animations, un visuel plus sexy), plus performante (téléchargements rapides, fluidité y compris sur iPhone 3G, économe en énergie) et plus fonctionnelle (car plus de souplesse du fait des performances).

Aujourd'hui, nous sommes vraiment fiers de notre travail sur iOS : c'est difficile, Apple met la barre de plus en plus haut, mais c'est vraiment génial ! Nous pouvons fournir un travail de meilleure qualité.

Louka Desroziers : C'est une bête noire qui se profile à l'horizon.

C'est un peu comme en cuisine. Il y a une recette a suivre, mais vous êtes libre d'utiliser des ingrédients légèrement différents. Le plat final, c'est votre application, basée sur un concept (la recette). Les ingrédients peuvent de résumer au langage et à l'IDE (environnement de développement) utilisés.

Prenez les ingrédients les moins chers, et votre plat aura un goût différent.

Cela peut paraître assez grossier comme représentation, mais c'est probablement ce qui va se passer : les entreprises désireuses de réaliser une application iPhone vont pouvoir se tourner vers des développeurs moins chers, du fait que le langage de programmation et l'IDE qu'ils utilisent seront plus répandus.

Ainsi, ceux qui auront choisi de faire de l'Ojective-C/CocoaTouch leur spécialité se retrouveront obligés pour la plupart de baisser à nouveau leurs tarifs. Je pense aussi bien aux développeurs indépendants (ce qui n'est plus mon cas) qu'aux entreprises qui ont créé des emplois dans ce domaine et qui demain se retrouveront peut-être obligés de baisser leurs tarifs afin de rester sur le marché.

D'un autre côté, on peut espérer une reconnaissance de nos compétences du fait d'être spécialisés dans un langage on ne peut plus proche de iOS. Wait & See…

Matthieu Kopp : Non, pas vraiment. Nous avions envisagé d'utiliser un moteur de jeu comme Unity dans certains projets et l'annonce d'Apple nous avait évidemment interpellés. Nous savons maintenant que cette option nous est toujours ouverte.

Bruno Rousseau : Pas grand chose, vu que j'étais au courant de ces nouveaux critères. Apple est vraiment plus stricte dans ses choix.

Raphael Sebbe : A court terme peut-être pas. Par contre, pour les projets futurs, cela ouvre des possibilités.

- Où en êtes-vous dans le développement multiplateforme ? Cette annonce aura-t-elle une incidence quelconque sur vos plans ?

Florent Morin : Concernant le développement multiplateforme, nous sommes encore très dubitatif.

Comment une application pensée, en termes d'ergonomie, pour être utilisée sur iOS, peut-elle être transposée sur Android ? Et vice-versa. Hormis pour les jeux vidéos, je ne vois pas.

Il serait envisageable d'avoir un framework intermédiaire qui s'adapte à l'une ou l'autre des plateformes. Ce n'est déjà pas facile sur des interfaces de bureau, alors sur un smartphone, je n'y pense même pas. Même si c'était possible, les approches en termes de développement sont bien trop différentes pour que cela puisse fonctionner correctement. Le matériel aussi est différent.

Cette possibilité originale est un fantasme d'ingénieur et un cauchemar pour l'utilisateur. C'est la porte ouverte à tout et n'importe quoi, tout du moins sur smartphone.

En terme de développement multiplateforme, nous restons donc sur du web, dans une certaine mesure. Cela ne change absolument rien dans nos plans : nous ne nous occupons que d'une seule plateforme, mais nous le faisons bien.

Louka Desroziers : Dans mon cas, je ne me suis jamais intéressé aux autres plateformes. Je crois à 100% en l'avenir de iOS (et Mac OS). J'ai décidé depuis longtemps que le développement d'applications sur Mac OS serait mon métier, et l'arrivée de l'iPhone et de son SDK m'a été très bénéfique au vu de son succès.

Ce qui me repousse le plus sur les autres plateformes, ce ne sont pas les outils de développement, mais l'interface en elle-même des OS. Apple a toujours prôné le user-friendly, et je trouve cela passionnant.

C'est donc un métier que j'exerce avec passion pour le moment. Quand je n'aurai plus cette passion, je me tournerai vers autre chose (ce n'est pas demain la veille, du moins je l'espère).

Matthieu Kopp : Le multiplateforme, avec Ave!Comics mais aussi avec Aquafadas, est au coeur de nos produits, car nous vendons ou distribuons du contenu (BD, Magazines, documents).

Il est donc fondamental de pouvoir le lire sur des supports différents, du web au mobile. Nous avons développé notre technologie autour d'un format, le format AVE, et nous nous appuyons sur des lecteurs développés en natif. Nous allons faire des annonces dans les prochaines semaines et dévoiler une technologie similaire dans le domaine du livre enrichi et des contenus complexes (magazines, documentations,…).

Là aussi, le coeur est un format, déployable partout, sur des lecteurs natifs et optimisés pour chaque plateforme. Cette annonce a donc une incidence limitée en ce qui concerne le multiplateforme. Même si nous faisons du multiplateforme, ce sera toujours en natif. Et les Mac, iPad, iPhone resteront nos plateformes de prédilection sur lesquelles nous avons un réel plaisir à développer et à expérimenter.

Bruno Rousseau : Pour le moment, je reste sur ma ligne de conduite, à savoir que je ne bougerai pas d'iTunes. Je reste persuadé que les utilisateurs d'Android ou BlackBerry téléchargent beaucoup moins d'applications payantes que sur iPhone. Donc elles restent moins rentables pour moi.

Quant à Windows Phone 7, il va falloir attendre au moins 1 an pour que le marché vaille le coup. De ce que j'ai pu en voir des spécifications matérielles, il y a des choses qui ne me conviennent pas, mais c'est propre à l'utilisation de mon logiciel. À voir dans un an. Donc, non, cette annonce ne changera pas mes plans.



Franchement, les autres plates formes ont du travail pour rivaliser avec le professionnalisme des équipes d'iTunes. Et tant qu'elles ne s'en rapprocheront pas, je ne migrerai pas.

Par exemple, qui mentionne qu'iTunes Connect se charge à notre place de nous enregistrer auprès du fisc américain et japonais ? Qui d'autre fait ça dans l'industrie ? C'est sidérant ! Ils nous prennent par la main et gèrent tout pour nous. Cette semaine, j'ai dû faire passer mon compte iTunes d'un statut juridique vers un autre. J'avais un numéro de téléphone 0800 gratuit pour appeler. J'ai attendu 30 secondes et j'avais un représentant francophone au téléphone pour m'assister dans ma migration. Il m'a dit "Cela devrait prendre 3 jours !". J'étais aux anges, parce que cette migration n'était pas si simple et je m'attendais à 1 mois. Résultat: La migration était faite le lendemain matin !

Des tonnes de développeurs expérimentent ça avec Apple. Le problème, c'est qu'on n'entend que ceux qui se plaignent tout le temps. C'est comme les 95% d'applis approuvées en une semaine. On entend que ceux qui attendent plus longtemps.

J'ai eu des problèmes avec iTunes il y a 2 mois. J'ai pu les contacter et ils m'ont résolu ça en 2 jours. Sous Handango et Pocketgear (deux concurrents d'iTunes pour Windows Phone) et alors que je leur ai demandé il y a 4 ans de retirer mon appli de leur site, ils continuent de la vendre… mais sans me reverser de revenus ! Et je ne parle pas du respect des règles fiscales dans le monde ! Les équipes d'iTunes sont pros et leur démarche de qualité va dans ce sens.

Raphael Sebbe : Nous sommes toujours en phase d'observation sur les plateformes alternatives. iOS est en tête au niveau technique et commercial par rapport aux autres, mais on est curieux de l'évolution d'Android, Windows Phone 7 et autres. C'est sûr que si un développement s'y prête (aux autres plateformes), et bien nous choisirons de préférence des librairies adaptées pour le réaliser.

- Est-ce que vous avez appris quelque chose dans les guidelines d'Apple ? Est-ce que cela va vraiment vous simplifier la vie ?

Florent Morin: Les guidelines d'Apple nous ont appris des choses, oui et non. Même si la plupart étaient déjà connues, il est toujours intéressant de pouvoir "pré-valider" nos applications, en revoyant point à point chaque critère. C'était un réel manque.

Cela va donc considérablement nous simplifier la vie.

Louka Desroziers : Les Guidelines ne nous apprennent pas grand-chose de plus, elles permettent surtout d'être fixé sur des points noirs.

Avant l'apparition de ces Guidelines, il fallait toujours faire son petit tour sur des forums pour poser des questions et trouver des réponses afin d'être sûr que l'on n'était pas sur le point de réaliser une application qui n'apparaîtra peut-être jamais sur l'App Store, ou qui sera rejetée à cause d'une petite erreur rapide à corriger, mais qui nécessitera tout de même d'attendre jusqu'à deux semaines supplémentaires avant une nouvelle validation.



Matthieu Kopp : Nous avions déjà fait l'expérience de pas mal de ces règles ;-). Apple met noir sur blanc certaines règles, de façon assez brutale et décrit aussi certaines exceptions. Il est assez intéressant de voir qu'ils ont fait une règle spéciale pour justifier de l'acceptation (fort logique) de NewsToons. Cela reflète un point important : Apple apprend de ses erreurs.

Ce qui est un peu plus délicat, c'est le choix qu'Apple risque de faire, pour limiter la prolifération des applications. Il y a des dizaines d'applications 'Alice au pays des merveilles' : est-ce une bonne chose ? Apple doit-elle restreindre ce choix ?

J'aime cette diversité, et j'aime à penser que la communauté va petit à petit faire émerger la meilleure application 'Alice' dans les classements. Je serai déçu de me faire refuser une application 'Alice' sous raison qu'il y en a déjà des dizaines.

En ce qui concerne le contenu publié dans des applications (livre, photos, BD...), la ligne est toujours un peu floue entre ce qu'Apple va accepter et va rejeter. Il faut donc gérer chaque projet au cas par cas. La distinction entre esthétique et érotisme est assez intéressante également…

Je me demande comment cela va se manifester dans les faits. Nous publions de la BD dans laquelle il n'est pas rare de rencontrer des "nus". C'est de l'art… Apple va-t-elle le considérer autrement que par le passé ? A voir. Je me demande par exemple si Apple validerait notre application "Toxique" qui comporte des dessins de "nus" faits par Bernard Buffet. D'après les règles exposées, le "nu" (esthétique et non pas érotique dans ce cas là) ne devrait plus poser problème.

Notre expérience avec Apple, c'est qu'ils sont prudents, mais à l'écoute. Nous leur parlons de ce que nous faisons, des problèmes que certaines règles nous posent maintenant. Et il faut bien avouer qu'ils écoutent leur développeurs, même si les choses mettent parfois du temps à changer.

Bruno Rousseau : Oui, les parties "User Interface", "Purchasing & currencies" et "Media content" comportent des éléments que j'ignorais. Donc, il est important de suivre ce document avant de se lancer dans un développement, au risque de devoir tout recommencer.

On sent aussi qu'Apple reste large sur certains sujets afin de se donner le droit de refuser une appli, même si elle respecte à la lettre les règles.

Pour le reste, je le répète, tout cela met sur papier ce que je savais déjà depuis quelque temps. Je suis même étonné qu'Apple n'ait pas publié ça il y a plus longtemps, vu qu'ils rejettent des applis qui ne leur conviennent pas depuis le début de l'App Store.

Enfin, je ne crois pas que ces "Guidelines" nous simplifieront la vie. Elles nous la compliquent puisqu'il y a plus de règles à respecter. Mais je ne pense pas non plus que ce soit une mauvaise chose. Au moins, c'est clair.

Raphael Sebbe : Oui, beaucoup de choses. Ça ne va pas vraiment simplifier, mais au moins permettre de mettre des mots sur ce qui restait très flou précédemment.

Je dirais qu'elles sont beaucoup plus strictes que ce qu'Apple laissait entendre jusque-là. Il est possible qu'Apple tente de limiter l'accès à l'App Store sur base de ce document, et cette fois sans recours possible du développeur puisque les règles sont connues à l'avance. Ça fait un peu peur d'ailleurs, car lancer un projet de développement de plusieurs mois, en sachant qu'il enfreint probablement quelques points de ce document, il faut oser…

Cependant, si les applications mal réalisées (ou abandonnées) sont rejetées, c'est un bon signe pour le développeur qui veut s'investir dans la plateforme. Car je peux vous assurer qu'on est complètement étouffés dans l'App Store.  Pour l'instant, malgré quelques rares success-stories, je suis convaincu que plus de 90% des applications de l'App Store ne sont pas rentables pour les développeurs. Je souhaite que cela change bien sûr.

La course au nombre d'app risque de s'arrêter un jour, tout comme la course aux performances s'est arrêtée il y a quelques années (cf. tests Photoshop, PowerPC vs Intel). Android commence à en avoir beaucoup aussi, et donc cet argument n'en sera bientôt plus un pour l'App Store. Ces guidelines sont peut-être un premier signe de ce changement d'approche.
avatar oomu | 
"Cette possibilité originale est un fantasme d'ingénieur et un cauchemar pour l'utilisateur. C'est la porte ouverte à tout et n'importe quoi, tout du moins sur smartphone." (à propos des outils de développement "multi-plateformes") d'accord à 150%, convaincu plus que jamais, beaucoup trop d'année à subir les javaseries, les QTseries, X11 toolkit, Motif, Flash, etc. c'est un fantasme d'ingénieur qui n'a jamais été au service des utilisateurs. - "Il y aura peut-être des applications de moins bonne qualité (saccadées...), mais il est aussi possible qu'un subset de Flash soit bien optimisé pour iPhone. " Dans un monde imaginaire et idéal, oui tout est possible. Mais coup sur coup, dans le monde réel, ce ne fut PAS possible. Ce n'est pas par manque de volonté ou de moyen. C'est parce que fondamentalement, on ne peut PAS être optimisé pour une plateforme tout en étant universel. On ne peut pas être à la fois Spécifique ET Générique. C'est une impossibilité qui a été tenté tant de fois, tant de fois. Il s'agit toujours d'un compromis. Ce compromis apporte quelques avantages (ca marche partout) aux prix de concessions . Apple dit tout simplement non à ces concessions via Xcode/Cocoa. C'est ce qui leur permet de créer de tels outils et un tel environnement aussi finement intégré et cohérent. - "Combiné à des outils d'authoring puissants (Adobe), ce "Flash" permettrait d'obtenir certains types d'application de qualité. Et pas que Flash d'ailleurs." non. Cela ne concerne que les applications de contenus, tels Wired.app. En aucun cas les outils ou jeux vidéo, cela ne peut qu'accoucher de produits inférieurs. Il en est de même avec Real Basic, ou XUL (mozilla) ou QT (nokia) etc. Adobe a UNE force (qui explose tout le monde) ce sont effectivement ses solutions de grande qualité de Authoring, de créations de contenus, médias et leur diffusion. Des contenus tels des Magazines. Là oui. C'est un domaine qui ne concerne pas Xcode, que Apple ne vise pas.
avatar USB09 | 
En somme les développeurs sont sommés de faire des applications de bonne facture pour vendre leur produit, par de là augmenter la qualité du store, donc mieux vendre leur produit. ... C'est bien beau tout ça mais les entreprises sans tamponnent complètement, du moment qu ils peuvent vendre leur m******. Pour les jeux ont peut rien y faire c'est une question de savoir-faire. Mais regardez l'application AIR FRANCE. Simple en soit mais bouton pixelisés, ergonomie lamentable et ça pue le flash quand la SNCF fait de très belle appli. J'ai vu des cas ou l'on trouvait des appli a l'intérieur des appli, horrible. On peut juste espérer que les développeur prennent bonne conscience. En sachant que c'est pour leur bien.
avatar bjcrzt | 
"On peut juste espérer que les développeur prennent bonne conscience. En sachant que c'est pour leur bien." C'est surtout pour le bien des utilisateurs qu'Apple fait ça (et j'approuve à 3543686847864768 %). Marre de ces apps de merde. Même celles en Objective-C/CocoaTouch sont mal foutues niveau interface (MacG par exemple (mais il est rapide :-))). Et puis d'autres fonctionnent mal. J'aimerai qu'Apple soit sans pitié lorsqu'une app de merde est soumis à validation.
avatar USB09 | 
@ bjcrzt : Je pense des fois de même.
avatar Eurylaime | 
le choix de l'outil est un mauvais argument, il y a des pures merdes sur l'AppStore qui ont été développé avec les outils Apple.
avatar Leehalt | 
@oomu Je lis souvent avec intérêt tes interventions qui sont souvent très intéresantes. Ton point de vue sur bien des domaines semble découler de ta grande expérience de l'informatique. Mais je dois t'avouer que j'ai du mal à comprendre ton raisonnement quand tu dis que les frameworks multiplateforme ne permettent pas de réaliser des applications de qualité. Et encore plus de mal à l'approuver. Evaluer la qualité d'une appli sur le fait que le framework utilisé pour la développer est multiplateforme ou pas me semble pour le moins...radical. Une bonne appli c'est une bonne idée + un bon framework (multiplateforme ou non) + un bon développeur.
avatar rsebbe | 
@oomu il y a des boites de jeu video qui font leur authoring flash avec les produits Adobe (utilisation de timeline, import de ressources, gestion des events, etc.) et le font tourner avec leur moteur maison sur iPhone ensuite. De même, Unity propose le même genre de runtime cross-platform qui simplifie fortement le travail du développeur de jeu 3D. Dans certains cas, les middleware ont une réelle valeur ajoutée aux outil Apple: facilité et/ou possibilités et/ou cross-platform).
avatar Goldevil | 
Pour développer sur iOS, il y avait 2 possibilités : XCode (ObjectiveC/C/C++) : très ciblé, très intégré. HTML/Javacript : hyper ouvert, très universel. Je pense que l'étouffement de l'AppStore est lié en partie à cela. Certains types d'applications sont sur représentés. Il y a des tonnes de jeux, des tonnes d'applications qui se résument à un visualisateur de documents (PDF/HTML). Pourquoi ? Peut-être que la réponse est liée à la faible variété des environnement de développement. On ne fait pas tout avec du HTML5. Outre le fait que la norme est pas finalisée, on ne peut pas stocker des données sur le client, on ne peut pas utiliser une base de donnée locale, on ne peut pas accéder au système de fichier, on ne peut pas accéder au bluetooth... C'est logique car lié à la gestion de la sécurité. Mais finalement, il n'y avait rien entre les deux. Je pense qu'il y a de la place pour d'autres choses. Une bonne application n'est pas bonne parce que le développeur est un virtuose de l'ObjectiveC. Elle est bonne car les utilisateurs la trouve bonne. Il y a le concept, le design, la fiabilité, la performance, la facilité d'utilisation... Chaque langage a son approche, apporte des chemins différents pour arriver à certains résultats. ObjectiveC n'est pas le langage universel pour tout. Un moteur d'inférence pour écrire un système expert (un logiciel de diagnostique) sera toujours plus pratique que du code C et ses dérivés.
avatar USB09 | 
@ Leehalt : Pas nécessairement. Si tu as une appli multiplateforme tu prend en compte les formats différent, les couleurs de charte des supports, fonctions unique de l'appareil etc. En gros un truc sans trop de saveur. Pour un jeux ça passe. Mais comme Apple c'est cassé la tête a fournir une interface que bien des boite envoi paitre, c'est bien un résultat moyen que l'on obtient.
avatar Un Vrai Type | 
@ Leehalt, @ rsebbe : Relisez bien Oomu... Il parle d'intégration et non pas de "qualité" (laquelle d'ailleurs ?). Le vrai problème de la perfection est qu'elle n'est pas unique et que les différentes perfections sont souvent des opposés. Et je suis d'accord avec Oomu, autant un jeu vidéo plein écran peut avoir un moteur générique, autant une "liseuse" de contenu minimaliste peut-être multiplate-forme, autant une application spécifique gagne toujours (rapidité, cohérence avec l'OS etc...) a être native. D'ailleurs, des liseuses désastreuses existent bien sur Mac OS X (qui a dit flash ? Moi je parlais de WMP ou realplayer...) et l'argument est "Apple n'ouvre pas assez son SDK"... Sauf que d'autres liseuses (comme Silverlight par exemple) ne souffrent pas du même problème. Au final, si la "liseuse" de flash avait été native sur OS X, elle aurait probablement passé les exigences d'Apple pour aller sur l'iOS. Adobe n'a pas assez cru à mac OS X (flash pour OS 9 rame nettement moins...) Cela fait du bien d'entendre les 90% de la communauté des développeurs iOS muets trop souvent... Merci MacGeneration.
avatar bigham | 
"Sous Handango et Pocketgear (deux concurrents d'iTunes pour Windows Phone) et alors que je leur ai demandé il y a 4 ans de retirer mon appli de leur site, ils continuent de la vendre… mais sans me reverser de revenus !" On a inventé récemment une profession pour régler ce genre de cas : cela s'appelle un avocat. Enfin, je dis ça, je dis rien.
avatar bigham | 
@oomu: [quote]Apple dit tout simplement non à ces concessions via Xcode/Cocoa.[/quote] Disons que c'est leur vérité du moment. Juste avant, c'était HTML et JavaScript qui était la "sweet solution". Dutronc devrait d'ailleurs intenter un procès à Apple pour utilisation abusive du procédé de la veste qui se retourne toujours du bon côté. Il va être très intéressant d'observer comment la montée en puissance de la plate-forme Android (qui sera plus réelle que celle de l'équipe de France de foot) poussera (ou pas) Apple à évoluer.
avatar Frodon | 
@Goldevil Il faut revoir ta connaissance d'HTML5, deux choses que tu cite comme infaisable fait partie justement des grandes nouveauté d'HTML5, tel que le stockage en locale (Local Storage) et les bases de données en local (Web database API).
avatar adriensmart | 
Est-il possible d'avoir un lien de la photo de cet article affichée sur la page d'acceuil de MacGé afin d'en faire un fond d'écran pour mon iPhone ? Merci par avance
avatar Stalmicmac | 
Il est également intéressant de lire le commentaire sur le professionnalisme des équipes de l'iTunes Stores sur toute la partie "Legal & Tax", de savoir que - mêmes si certains se plaignent - les développeurs peuvent compter sur les équipes d'Apple pour les aider. On entends souvent des développeurs hurler au scandale lorsque ça ne va pas, mais jamais (ou pas assez souvent) on explique ni communique sur les bonnes expériences et aides obtenues par les équipes Apple. En tout cas, article très intéressant.
avatar GStepper | 
Une fois de plus, très bon article, merci à vous !
avatar NicolasO | 
@oomu: Le raisonement est faux. Beaucoup d'outils multiplateformes marchent tres bien. (Y compris ceux que vous citez) Les meilleurs moteurs de jeux sont multi-plateforme, Java fait un carton incroyable dans le monde professionel. (X11 n'est pas un framework multi-plateforme donc je n'en parlerai pas.) La seule chose qui ne marche pas bien en multiplateforme, c'est l'interface homme-machine. Reduire une application a son interface est vrai pour une partie faible des programmes. Pour tous ceux-la, la partie non IHM peut etre multi-plateforme sans aucun soucis. (Rappelons que Java est aujourd'hui aussi perforamt qu'Objective-C si ce n'est plus. Cela en dit long sur la qualite potentiel d'outils multi-plateformes. Seuls l'interface n'est pas native.)

CONNEXION UTILISATEUR