Apple et les développeurs : c'est compliqué !

Christophe Laporte |

Les développeurs indépendants gravitant autour de l'écosystème d'Apple doivent avoir la tête qui tourne. Ces dernières années, ils avaient déjà dû se dépasser avec la montée en puissance d'iOS. Proposer une application entièrement fonctionnelle sur iOS et OS X n'est pas de tout repos.

Ce qui est souvent présenté comme étant très simple par Apple est dans les faits beaucoup plus compliqué pour les développeurs. On l'a vu avec de nombreux éditeurs comme The Omni Group qui propose des apps de qualité sur chacune des plates-formes d’Apple, mais à qui il a fallu beaucoup de temps pour y arriver. Chaque plateforme a ses avantages, mais également ses spécificités et ses contraintes. De plus, le fait d’avoir une même app sur plusieurs plates-formes amène de nouvelles problématiques, dont celle de la communication entre elles. Il faut pouvoir passer d’un appareil à l’autre sans contrainte.

L'art est d'autant moins facile qu'iOS et OS X évoluent en permanence. Pour répondre aux attentes des utilisateurs, il faut donc à la fois faire évoluer son application pour qu'elle soit meilleure que ses concurrents directs, tout en exploitant au mieux les nouvelles fonctionnalités des systèmes d'exploitation d'Apple. Un marathon sans fin…

Les développeurs qui étaient déjà bien occupés viennent de voir apparaitre en l’espace de quelques mois deux nouvelles plates-formes estampillées Apple : watchOS pour l’Apple Watch et tvOS pour l’Apple TV. À cette liste, il faut également ajouter l’iPad Pro qui n’est pas un iPad comme les autres. Sur le papier, ces nouveaux produits leur offrent dans bien des cas de nouvelles opportunités, mais le jeu en vaut-il la chandelle ? La question mérite d’être posée.

Du point de vue d’Apple, les choses sont très simples. La firme de Cupertino compte plus que jamais sur ses développeurs pour rendre encore plus attractifs ses nouveaux produits. Avoir quelques killer-apps est une condition clé au succès de l’Apple Watch, l’Apple TV et l’iPad Pro.

Mais pourquoi les développeurs seraient-ils prudents ?

Lorsqu’Apple a lancé l’App Store, il y avait une sorte de ruée vers l’or. Pour le Mac App Store, le parc de Mac était déjà important et les portages aisés dans la plupart des cas. Enfin, l’iPad a été lancé dans un climat d’euphorie comme Apple en a peu connu dans son histoire. La marque à la pomme était véritablement à son apogée.

Comment pousser les développeurs à faire la killer-app pour l'Apple TV ou l'Apple Watch ? Sans parler d'étude de marché, il y a certains aspects qui sont difficiles à prendre en compte. Les développeurs ont une idée assez précise du parc installé de Mac, d'iPhone et d'iPad. Tout le monde en revanche connait le mutisme d'Apple vis-à-vis du nombre de montres qu'elle a vendues. Le « tout va bien » de Tim Cook ne suffira pas forcément à les convaincre à passer quelques mois à concevoir l’application qui pourrait tout changer.

Même chose pour l'Apple TV. D'ailleurs, c'est suffisamment rare pour être signalé, Apple a été très gentille avec les développeurs en leur permettant d'obtenir un exemplaire pour 1$ symbolique dans l'espoir de voir naître des vocations, le tout un mois avant son lancement.

Pour le moment, il n’y a pas de véritable dynamique autour de ces produits. Dans certains cas, on trouve même des développeurs qui préfèrent rester à l’écart. L’exemple le plus marquant est sans doute celui de Bohemian Coding avec l’iPad Pro.

Cet éditeur, à qui l’on doit Sketch, un éditeur de dessin vectoriel adulé (lire : Design : pas de portage de prévu sur iPad Pro), a préféré se tenir à l’écart de la nouvelle tablette d’Apple. La raison invoquée est l'impossibilité de proposer une démo pour un titre vendu 100 € :

Le plus gros problème est la plateforme. Les applications iOS sont généralement vendues à des prix faibles en raison de l'absence de version d'essai. Nous ne pouvons pas porter Sketch sur iPad si nous ne sommes pas sûrs du retour sur investissement.

Sketch sur iPad Pro serait très probablement un outil formidable, qui constituerait pour un nombre non négligeable d’utilisateurs un motif suffisant pour acquérir la grande tablette.

Apple et les développeurs : je t'aime, moi non plus !

Les relations entre les développeurs et la firme de Cupertino ne sont pas forcément au beau fixe. Il y a des points d'achoppements qui reviennent souvent sur le coin de la table. Le plus récurrent est sans doute qu'Apple ne leur permet pas de proposer des mises à jour payantes. On pense également à d'autres points comme les délais de validation, le système des commentaires sur l'App Store qui ne permet pas de dialoguer avec les utilisateurs confrontés à des bugs…

Mais le nerf de la guerre, comme le montre l’exemple de Sketch, est souvent d’ordre financier… Comment s’y retrouver avec une application vendue une poignée d’euros ? L’argument est souvent mis en avant par les développeurs.

Face à ce problème, des solutions existent pourtant. Il y a ceux à l’image de The Omni Group qui n’hésitent pas à garder une tarification élevée. Son gestionnaire de tâches, OmniFocus 2, coûte 39,99 € sur l’App Store. L’éditeur qui jouit d'une excellente réputation parvient à maintenir des prix de cet ordre sur tous ses logiciels.

Il y a également la voie du freemium qui est de plus en plus utilisée. C’est très facile à mettre en oeuvre dans certaines applications, notamment dans les logiciels graphiques où l’éditeur peut réserver certains outils aux utilisateurs payants. Enfin, il y a la voie de l’abonnement qui est de plus en plus prisée. Les deux cas les plus symboliques sont Adobe et Microsoft.

Cercle vertueux ou cercle vicieux ?

Avec l’App Store et l’iPhone (puis l’iPad), Apple est parvenue à créer un cercle vertueux. Avec l’Apple TV, l’Apple Watch et l’iPad Pro, la tâche s’annonce plus ardue.

Ces produits sont des promesses et sont amenés, au moins à court terme, à vivre dans l’ombre de l’iPhone, qui plus que jamais constitue le centre de gravité d’Apple et des développeurs. Le Mac App Store en sait quelque chose (lire : Le Mac App Store est-il un échec ?), alors même qu’il bénéficie d’un parc d’ordinateurs installé important. Mais il y a une vie après l’iPhone, et c’est sans doute aussi pour cela qu’Apple s'attache à ouvrir tant de nouveaux marchés.


avatar xavier25 | 

En tant que dév, deux trois choses de mon expérience :
- chaque année, il faut se mettre à la page (apparition de Swift, nouveaux appareils, nouveaux process), c'est devenu très chronophage (on le fait par passion, mais on finit par se mettre à la page qu'en fonction des besoins des projets, on explore l'essentiel).
- Adapter une app à chaque plate-forme n'est jamais quelque chose de simple et la multiplication des devices (mobile, tablette, montre etc) explose le temps de développement donc on restreint le nombre de plate formes en attendant de voir (clients frileux sur la pertinence)
- enfin, hors demande client, trouver un concept qui permet de gagner de l'argent n'est pas forcément une mince affaire, d'autant plus sur une montre (dont les perfs laissent à désirer) ou un boitier TV dont on a aucun retour sur les volumes. Donc oui certaines plate formes peinent à décoller, ce n'est pas faute de vouloir faire des apps, mais le temps de développement est devenu très important sans aucune garantie de retour sur investissement.
Les iTV et iWatch, c'est un peu le windows mobile d'iOS. Y'a les outils, on a envie de tester, mais on n'a pas envie de se bruler les ailes.

avatar marc_os | 

« chaque année, il faut se mettre à la page »

Euh... c'est pas un peu vrai pour tous les langages en informatique, quelque soit la plateforme ?
Sauf en Cobol peut-être...

avatar xavier25 | 

Ben disons que si t'es dev web, même si t'as de nouveaux frameworks (que tu n'as pas d'obligation à suivre), c'est moins lourd que les changements d'OS et d'ajout de matos à prendre en compte.
Mais bien sur que la base en tant que dev, c'est de se documenter en continu, mais je trouve ça + "prenant" sur mobile.

avatar marc_os | 

@ xavier25
Je pense exactement l'inverse.
Un dev web complet doit maîtriser au moins cinq langages et deux frameworks: php (ou un autre langage serveur), sql, javascript, html, css, less, xml, etc. et les frameworks qui vont bien comme ZendFramework et JQuery. Et maîtriser l'Ajax. En plus faut aussi gérer les différentes capacités des navigateurs en fonction et de la plateforme, et de la version. Savoir que Microsoft a du mal avec les coins arrondis, (d'où les tuiles carrées :P ) et les png si je me souviens bien. Et ça n'arrête pas de changer.
En comparaison, le développement pour OS X ou iOS me paraît incomparablement plus stable. J'ai pas à me poser la question si avec Internet Explorer version tartampion ou Opera ça marche ou pas. Encore récemment j'ai dû zapper Safari (à jour sous Maverick) et utiliser Firefox parce qu'un site à la con marchait mal avec Safari. Ah oui, il me semble que c'était le site de cdiscount.

avatar xavier25 | 

Oui ton avis se défend ^^
Je précise que je ne fais que des apps web pour dépanner (Rails), ce n'est pas mon job, donc je ne comparerai pas davantage.
Disons que je fais iOS + Android et je trouve quand même qu'il y a beaucoup de changements à intégrer (et de + en + au fil des ans).
Après c'est sûr, ce n'est peut être pas aussi contraignant en terme de "compatibilité", mais a-on a quand même plein de formats à gérer, d'interface à re-penser, là où bootstrap fait des merveilles avec 3 fois rien.
De plus, et ce n'est pas négligeable, quand j'envoie en prod, c'est beaucoup plus critique que sur un projet web. On ne peut pas intervenir immédiatement en cas de bug et on peut se faire descendre très rapidement sur les stores (sans pouvoir répondre).

Bref c'est un autre monde, avec des contraintes, peut-être pas autant de languages à maitriser (quoique pour te citer, php (ou un autre langage serveur), sql, javascript, html, css, xml je les utilise dans les apps, et les frameworks iOS ou Android demandent tout autant d'investissement qu'un Zend ou un Symfony2 pour être bien appliqués. Après, j'avoue, les problèmes liés à IE ça doit être désespérant au quotidien...

avatar RyDroid | 

C, C++, Java, JavaScript, Common Lisp, GNU R, GNU Octave ne cassent pas la compatibilité, et ça n'empêche pas les 4 premiers cités d'être parmi les 10 langages de programmation les plus utilisés au monde et d'être multi-plateformes.

avatar BeePotato | 

@ RyDroid : « C, C++, Java, JavaScript, Common Lisp, GNU R, GNU Octave ne cassent pas la compatibilité »

Quel rapport avec ce qu’il disait ? Il parlait de devoir « se mettre à la page ».
Ok, pour le C, ça fait un moment qu’on n’a pas trop eu ce besoin. Mais pour C++ et Java, par exemple, il y a régulièrement des mises à jour importantes nécessitant de se mettre à jour sérieusement.

Quant au côté multi-plateformes, on ne voit pas trop ce qu’il vient faire là dedans…

avatar nemrix | 

Sinon il y a la méthode de Firecore avec le player Infuse qui fait "repayer" un in-app (appelé "pro") qui débloque des fonctions supplémentaires lors des mises à jour majeurs (sorte de mix entre freemium/premium et upgrade payant).

C'est une manière de faire payer les upgrade lorsqu'ils sont importants tout en permettant un accès gratuit (limité mais largement utilisable) aux utilisateurs ne souhaitant pas payer les nouvelles fonctionnalités.

Cela reste malgré tout un moyen de contourner cette limite imposée par Apple et qui dans certains cas est handicapant pour les dev et les client (J'aurais déjà un iPad pro si Sketch était adapté à la tablette [et au pencil])

avatar fousfous | 

Je trouve que c'est plutôt les développeurs qui veulent avoir le plus en faisant le moins possible.
Passer d'une plateforme à une autre est justement ultra simple grâce aux apis et ça ne prend pas de temps, mais évidement y en a pleins qui ne veulent pas utiliser ces apis, dans ce cas il ne faut pas venir se plaindre...

Pour les versions d'essais je ne vois pas où est le problème, j'ai connu une époque où sur l'app store il y avait dès version lite gratuite et la version complète payante, donc encore un faux problème.
Et pour les MAJ payante (bien que je sois contre se principe), il y a toujours la solution de utiliser les bundle qui permettent de réduire le coût d'achat pour les gens ayant déjà la précédente version tout en baissant le prix de la précédente version et en lui apportant des corrections de bug pour ne pas abandonner les gens qui ne sont pas passé à l'autre version qui coute beaucoup plus chère.

Donc il y a des solutions, juste que les développeurs ne veulent pas les utiliser pour je ne sais qu'elle raison...

avatar treizep | 

@fousfous

Tous des flemmards les développeurs c'est bien connu, sauf Apple bien sur.

avatar iGeek07 | 

@fousfous :
Lorsqu'on parle de version d'essai, on parle d'un logiciel entièrement fonctionnel pour un temps limité au bout duquel l'achat est obligatoire pour profiter de l'application. Pas des versions Lite amputées de fonctions (car elles ne peuvent être limitées dans le temps). Pour remplacer ces versions "Lite" il y a maintenant l'application avec l'achat in-app intégré pour débloquer les fonctionnalités. Et les développeurs utilisent beaucoup ce mécanisme, mais ce n'est pas une version d'essai à proprement parler.

avatar heret | 

Va apprendre à programmer sur iOS et OSX, rien que ça, même pas tvOS ou watchOS, et tu arrêteras de dire des conneries. Et je ne vais pas t'expliquer pourquoi, ça t'instruirait...

avatar ovea | 

@heret
Ben !? Justement instruis-nous … ça évitera d'être un gros cow boy qui au fil du temps devient intransigeant … par plaisir ou par intérêt

avatar LimeJuicy | 

@fousfous :
Bon, je débute donc je peux me tromper, mais je ne suis pas d'accord avec toi.

Adapter une app à l'iPad n'est pas le plus compliqué grâce aux API similaires. Or, sur watchOS et tvOS ce ne sont pas les mêmes.

De plus il ne faut pas oublier la question du design de l'application qui est une réflexion qui peut prendre du temps.

Donc je ne sais pas si tu es toi même développeur, mais soit j'ai manqué quelque chose (ce qui est possible, je débute) soit tu minimise beaucoup le travail que peut avoir un développeur pour designer une app et la porter sur des systèmes différents...

avatar Bigdidou | 

@fousfous :
En tout cas, ce qui fait l'essentiel de l'intérêt de la plateforme iOS, c'est la qualité de l'offre logicielle (variété et qualité intrinsèque) et donc des développeurs qu'il y a derrière. Dans chaque domaine qui m'intéresse, il y a de véritables bijoux, où, souvent, les développeurs rivalisent d'ingéniosité pour pallier les limitations imposées par Apple.
Partir en croisade contre eux et leur expliquer que leur métier est facile quand on ne connaît pas me paraît quelque peu inapproprié et injuste.
Mais, je te l'accorde, ça fait bien partie de l'ambiance actuelle de ces réactions aux News ou dénigrer tout et n'importe quoi à coup d'arguments de café du commerce et d'affirmations binaires, surtout si on n'y connaît rien soi-même, est devenu le sport à la mode.

avatar fousfous | 

@Bigdidou :
Enfin quand tu parles de qualité malheureusement j'en vois plus beaucoup...
Je ne dépense presque plus rien en app (et pourtant je suis demandeur) parce qu'il n'y a plus d'app de qualité, dit c'est remplis de bug, soit ça ne sert à rien ou alors c'est gangrené par là pub, et j'en veux beaucoup aux devs pour avoir laissé faire ça.
Quand on a connu un store remplis d'app de qualité et qu'on voit le relâchement de ces dernier temps ça ne donne pas envie de faire confiance aux développeurs pour la suite.
Surtout que je remarque qu'il y a beaucoup de conservatisme, de gens qui se plaignent que ça va trop vite, mais c'est quand même le principe de la technologie, ce serait idiot de s'arrêter...

avatar Un Type Vrai | 

"Quand on a connu un store remplis d'app de qualité"

Ces applications ont disaprus puisque le store n'a plus d'applications de qualité.
Donc la qualité ne paye pas et et en danger l'entreprise qui publie ces applications.
C'est pour ça que la qualité baisse, pas à cause des développeurs.

Soit ce raisonnement s'applique, soit ton discours ne tiens pas.

Choisi.

avatar vrts | 

Foufous au secours d'Apple sur tous les fronts, même quand c'est pour raconter n'importe quoi...

avatar BeePotato | 

@ fousfous : « Passer d'une plateforme à une autre est justement ultra simple grâce aux apis et ça ne prend pas de temps »

Toi, tu n’as jamais fait de développement d’application pour ces OS et tu ne connais rien du tout à ce domaine, c’est bien ça ? ;-)

avatar Ducletho | 

@fousfous :
Je trouve que c'est très difficile d'être d'accord avec toi.
Bon à part certains, mais ils sont au même niveau que tes commentaires.
Un jour peut être que quand t'auras l'impression de sortir une connerie je serais d'accord avec toi.
John MEynard doit te manquer.

Un dose de réflexion, bouge, mange au moins 5 fruits et légumes par jour et tout ira bien pour toi

avatar Domsware | 

@fousfous :

Tu te trompes lourdement. Passer d'une plateforme à l'autre n'est pas si simple que tu le penses. Ne serait-ce que l'interface utilisateur qui est entièrement différente et qu'il faut repenser.

Ensuite à chaque mise à jour d'OS il y a les nouveautés et aussi les bugs qui vont avec. Pour les nouveautés, cela prend du temps de la prise de connaissance à la mise en pratique.
Quand aux bugs cela est très chronophage : entre ce qui marchait avec l'OS n-1 et qui ne marche plus avec l'OS n, les bugs sur les nouvelles fonctionnalités, les bugs dans Xcode...

Donc oui cela est chronophage même si je pense que Sketch exagère énormément le trait. Sketch est une application très connue et reconnue qui dispose ainsi d'une large base de clients potentielle pour une version iPad. Reste que l'éditeur de Sketch a tout de même intérêt à débarrasser son outil de ses nombreux bugs.

avatar marc_os | 

@ Domsware
« ce qui marchait avec l'OS n-1 et qui ne marche plus avec l'OS n »

Pourrais-tu citer au moins deux exemples de bogues pour chaque passage de n à n+1 que tu as dû contourner ?
(Je dis deux, car le monde n'étant pas parfait nulle part, tu en trouveras certainement un).

avatar Domsware | 

Disons la gestion des fichiers PDF dans les assets, la création d'atlas de textures à partir d'images dynamiques, la gestion des images selon la résolution de l'appareil...

Pour t'en convaincre, je t'invite à prendre le temps d'aller sur StackOverflow ou bien sur le forum des développeurs d'Apple : et là tu trouveras plus que 2 bugs.

avatar iGeek07 | 

Je suis d'accord qu'Apple à dévoilé beaucoup de nouvelles plateformes ces derniers temps, mais il faut aussi se rappeler que le nombre de plateformes ne devrait pas trop changer avant un certain nombre d'années maintenant.
Même s'il est vrai qu'il faut aussi maintenir les logiciels avec les nouveautés de chaque plateforme, qui ne manqueront pas d'être dévoilées chaque année…

avatar iPal | 

Pour mon team, on "bloque" tous les développements pendant le mois d'octobre. C'est le mois "mise à niveau, recherche et formation". C'est aussi là qu'on fait une petite retraite d'une semaine pour aller geeker au calme.

Tant qu'Apple reste fidèle à son calendrier, c'est facile à organiser. Plus que l'ajout de matériel et techniques, ce serait un changement de calendrier (WWDC, sorties iOS, etc) qui poserait problème.

avatar JustThink | 

@iPal :
Excellent. Très bon esprit.

avatar ovea | 

Ceci étant c'est pas pire que les dèv. Microsoft qui sont entretenus pour réinventer la roue chaque fois que l'éditeur réinvente informatique … pour donner du boulot l'industrie et apparaître comme LE sauveur de l'humanité

ces dèv. même qui viennent dire que Apple c'est le diable tout simplement parse que Apple se mettait à faire de l'argent en leurs piquant une soit disant expertise de pacotille !

Non ! Le vrai soucis de l'industrie informatique, c'est de capter le temps des développeurs pour une plateforme propriétaire … ce que Apple semble avoir bien pigé

Et c'est une bonne nouvelle pour les utilisateurs pour qui les consultants en informatique on toujours été retissant et même catégorique pour ne pas s'investir dans le système d'entreprise tellement merdique, que la prise de risque est suicidaire

Là le boulot concerne d'abord, avant tout et toujours chez Apple : l'utilisateur ! Donc ça en vaut la peine

avatar iPal | 

@ovea :
Bien vu. +1 pour Microsoft qui lance des technos plus vite que des piafs dans Angry Birds et qui a aussi la capacité d'abandonner des technos très vite.

avatar Tomn | 

1 semaine d'attente de validation entre chaque mise à jour de l'app c'est long aussi…

avatar ovea | 

L'exemple de Visible Body et son Atlas d'anatomie humaine est instructif :

Pionnier dans la visualisation du corps humain, l'appli. iOS est à 30€ (c'est logique) et d'autres appli. sont dispo. pour le compléter mais elles sont restées en anglais pendant longtemps, avec des versions distinctes ou réservées au seul iPad … maintenant dispo. en universelle, en français et en achat supplémentaire dans l'appli. principale

Ils ont encore un problème pour énoncer le texte affiché … mais vu leur détermination et la constance de leurs mise à jour, ça devrait arriver

avatar marc_os | 

C'est pourtant pas bien compliqué de localiser un application OS X ou iOS (bien sûr si le développeur n'a pas codé les message en dur et a bien suivi quelques règles de développement très simple pour la localisation).
La difficulté est surtout de trouver des traducteurs "natifs" comprenant de quoi il retourne (s'il y a des termes techniques).

avatar Domsware | 

Attention, cela dépend de l'application. Changer les chaînes et gérer les traductions et les traducteurs cela se fait sans trop de soucis.
Lorsque le design est spécifique, comme pour un jeu, cela peut poser beaucoup de tracas. Je parle d'expérience !

avatar marc_os | 

@ Domsware
« Lorsque le design est spécifique »

Ça veut dire quoi ça ?
C'est sûr, si le texte est incrusté dans les images comme le faisaient certains développeurs de CD-Roms dans les années 90...
Quelque soit le design, si les localisations sont dans des fichiers séparés, voire même une base de donnée comme pour certains sites web, on peut charger le texte correspondant à la langue voulue !
Quant aux vidéos et bandes son, le fait d'avoir plusieurs pistes n'a rien d'extraordinaire.
Donc j'insiste, si un projet est conçu correctement, la seule difficulté devrait être la traduction elle même. S'il y a des difficultés techniques généralisées sur un projet, c'est que celui-ci a été mal conçu. Qu'il y ait des difficultés pour des cas particuliers, des trucs vraiment tordus, peut-être, même si je ne vois pas quoi, mais en général, non.

avatar BeePotato | 

@ marc_os : « si les localisations sont dans des fichiers séparés »

Les traductions et non les « localisations ». Puisqu’on parle de traduire, autant le faire aussi dans les commentaires. :-)

Pour le reste, je suis d’accord : pour la majorité des applications, il ne devrait pas y avoir de réel obstacle technique.
Reste le coût d’une bonne traduction, plus encore dans le cas de jeux où il faut enregistrer une nouvelle bande son.

avatar Domsware | 

@marc_os Je me permets de te dire que tu ne sais pas de quoi tu parles. Alors je t'invite à tater par exemple du framework SpriteKit ainsi tu verras comme cela est facile de localiser un jeu. Et de réaliser que lorsque l'on sort des sentiers battus alors cela devient complexe.

Selon les langues la taille du texte peut être fort différente : donc la super interface chiadée développée en français ou en anglais explose en allemand ou en italien. Et les outils fournis par les frameworks pour gérer ces cas ont des limites. Alors oui globalement cela fait le job néanmoins le jour où tu tombes sur une situation particulière tu comprends vite que les choses sont bien plus délicates à faire qu'à dire.

avatar françois bayrou | 

+1 Ovea
Le problème n'est pas propre à Apple. Les devices et les frameworks qui évoluent, les langages qui changent, ...
Apple a au moins pour elle d'avoir une doc de malade, comparé à d'autres, accompagnée d'exemples en veux-tu en voilà.

"Lorsqu’Apple a lancé l’App Store, il y avait une sorte de ruée vers l’or"

Pour mémoire, Steve Jobs ne voulait pas d'App Store au début, et avait parié sur des apps non natives écrites en HTML5/JS. Le natif était réservé aux gros partenaires : Google, MS, ...
Un gros framework JS nommé "sproutCore" ( beurk le nom ) était mis en avant et Apple poussait les devs à l'utiliser. Sauf que ca n'a pas marché, les devs voulaient du natif.

Ce n'est que sous la pression de ces devs que Apple a finit par sortir un XCode à jour et un store avec ses règles ( droit de refus d'une app, 30% de com' , ... ) ouvert à tout dévéloppeur inscrit qu programme (... tout le monde a applaudi et c'est là que les coussins péteurs sont arrivés )

Et maintenant ca pleurniche parce que c'est compliqué ? Ha. Ha. Ha. Ha. Ha.

avatar Lemmings | 

@françois bayrou : le concept de Jobs était en l'état impossible à utiliser. La puissance manquait cruellement, les API HTML pas finalisées... Le natif était la seule solution pour avoir un environnement riche et performant. On le voit bien avec la watch d'ailleurs, la v1 non native était décriée pour cette raison en partie.

avatar BeePotato | 

@ françois bayrou : « Ce n'est que sous la pression de ces devs que Apple a finit par sortir un XCode à jour et un store avec ses règles ( droit de refus d'une app, 30% de com' , ... ) ouvert à tout dévéloppeur inscrit qu programme »

C’est surtout après avoir pris le temps de développer un SDK — qui n’existait évidemment pas encore au moment de la sortie de la toute première version d’un iPhone OS qui sentait encore beaucoup la peinture fraîche — et de mettre en place un store, après avoir défini ses règles. Tout ça ne se fait pas d’un claquement de doigts. La rédaction d’une « doc de malade » ne se fait pas en deux semaines — et encore moins le peaufinage des API, avant même de songer à les documenter.
Ce n’est sûrement pas juste suite à un caprice qu’Apple n’a pas offert tout ça d’emblée en 2007.

« (... tout le monde a applaudi et c'est là que les coussins péteurs sont arrivés ) »

Pas tout de suite pour les coussins péteurs : rappelons qu’ils ont d’abord été (logiquement) refusés par Apple, avant d’être autorisés face à une vague de protestation face à cette « censure ».
On retrouve fort probablement, d’ailleurs, des défenseurs d’alors de cette « liberté d’acheter des applications à la con » parmi ceux qui se plaignent maintenant de la trop grande présence de ce genre d’applis…

avatar anotherbitethedust | 

Article qui a le mérite de poser de bonnes questions qui sont bien de la réalité actuelle.
Après avoir discuté avec un développeur hier soir justement qui vient de terminer une app sur IOS et Iwatch, il m'a expliqué toutes les galères pour réussir à le porter sur WatchOS (notamment le système de 24 crédits réinitialisé toutes les 24h qui t'empêche de pouvoir faire plus de 24 réactualisations push afin d'économiser la batterie, donc si tu fais une application GPS avec plus de 24 waypoints, tu l'as dans le baba.. et c'est qu'un exemple).

Bien sûr, c'est le tout début, toutcomme le premier Iphone.. beaucoup de limitation (pour ceux qui ont oublié, la fonction du copier coller n'est arrivé que bien plus tard :) ).
Pour Apple, c'est le début et cela va évoluer, la iWatch ira en s'améliorant avec les nouvelles techno et batteries... mais pour les programmeurs, c'est vtai que c'est une pléthore de difficultés qui mérite de poser cette question dans l'article: si le jeu en vaut la chandelle économiquement. La passion fait avancer, c'est vrai, mais la réalité économique finit toujours par rattraper.

Apple va devoir investir plus sérieusement dans le développement d'une plateforme commune de développement pour les professionnels au risque de perdre la vague de lancée de ses produits. Le "ship first and fix later" a ses limites et peut coûter très cher ( Microsoft en sait quelque chose).. Apple a une image de marque qui commence a se térnir auprès des professionnels ( j'aborde même pas la partie serveurs, macpro sous équipés en puissance qui pousse a devoir faire des hackintosh, etc..)
Il y a une vrai problématique posée dans cet article et j'espère de tout coeur qu'Apple va écouter le end-user professionnel.

avatar marc_os | 

Sketch, cette application basée sur un sample code d'Apple s'appelant... Sketch ?
https://developer.apple.com/library/mac/samplecode/Sketch/Introduction/Intro.html

Pour le port vers iOS, le monsieur doit attendre qu'Apple lui donne le code qui va bien pour iOS...

avatar Kol | 

Au contraire pour moi l'apparition de nouvelles plateformes comme l'Apple Watch ou l'Apple TV permet de nouvelles possibilités en développement. Après celui qui veut faire uniquement du dev iOS ou OS X n'est pas obligé de développer une application Watch OS.

Apple offre des possibilités en développement comme un nouveau langage (Swift) mais ne l'impose pas. Si un dévelopeur veut continuer de programmer en Objectif-C il le peut sans problème.

avatar Sostène Cambrut | 

Je veux bien croire que le développement soit une discipline compliquée (quelque soit la plateforme) mais j'ai un peu de mal à comprendre le procès qu'on fait ici à Apple. Ça fait des années maintenant qu'elle construit un écosystème pour les développeurs. Quand on a une app Mac disponible sur iOS généralement on l'achète aussi - chez moi c'est OmniFocus et Reeder par exemple - et ça fait des revenus en plus sans avoir besoin de faire de la communication supplémentaire. Apple porte tous ses efforts actuellement pour faciliter le portage des apps iOS vers OSX. C'est peut-être pas encore parfait mais ça va indéniablement dans le bon sens.

Maintenant, qu'il n'y ait pas encore de continuité avec ses autres plateformes (tvOS, WatchOS) je vois pas vraiment le problème. On va pas utiliser la version complète de Sketch sur une Apple Watch si ? Mais ça reste du Swift, donc quoi qu'il en soit le langage est connu.

Donc j'ai vraiment du mal à comprendre le fondement de cet article. C'est pas la première fois qu'il est servi d'ailleurs (il a peut-être été un peu rebrandé mais le fond reste le même)

NB: Sketch peut bien laisser l'iPad Pro de côté, il y aura du monde pour prendre sa place.

avatar iPal | 

@Sostène Cambrut :
Connaître le langage, Swift ou autre, c'est 10% du job. Un bon codeur assimile un langage en un week-end. Là, on parle de frameworks.

avatar Sostène Cambrut | 

@iPal

"Connaître le langage, Swift ou autre, c'est 10% du job"

J'en doute pas une seconde ! Mais c'est déjà ça de pris.

Après l'Apple Watch c'est une nouvelle plateforme avec son propre paradigme, donc ça me parait assez normal que les API de l'Apple Watch soient pas les mêmes que les API d'iOS, un peu comme Cocoa Touch à son époque apportait les API spécifiques à l'interface d'iPhone OS.

avatar iPal | 

@Sostène Cambrut :
Évidemment. Il est logique qu'une nouvelle plateforme apporte des méthodes supplémentaires. Maintenant, est-il logique que des méthodes communes soient différentes d'une plateforme à l'autre ? De ce côté, Microsoft a une longueur d'avance (et bien d'autres problèmes).

Quand au langage utilisé, le "ça de pris", c'est trivial.

avatar anotherbitethedust | 

"Apple porte tous ses efforts actuellement pour faciliter le portage des apps iOS vers OSX"

C'est peut-être la demande grand public, mais c'est peut-être pas ce que demande le end-user professionnel..

Apple est-il a l'écoutes des users professionels ? Le professionnel a besoin de mettre des apps OSX sur IpadPro. D'ailleurs, avant sa sortie, on avait l'espoir que ce serait OSX qui tournerait dessus.
Le segment économique des professionnels serait plus à vouloir leurs applications Mac portées sur l'Ipad Pro. Voici quelques exemples qu me sont personnels :
- application de la table de mixage numérique multitouch à multiple points simultanés, ainsi que les applications d'enregistrement multipistes couplés avec un RM16 presonus. Jusqu'à present, faut soit un macbook pro OSX avec souris (pas génial), soit une tablette Microsoft Lenovo Win 8 pour le multitouch :( . Or l'application pour Ipad existe pour la table de mixage mais pas le reste.. :(.
- gestion depuis l'Ipad pro d'une application plateforme pour gérer des groupes d'écrans Numeriques voire TV afin d' afficher des stats temps réels comme dans les centres de contact.. L'éditeur Panic a bien collé un Ipad mini derrière un 42 pouces, mais devait utiliser Chrome pour réceptionner les stats.. pas top.. alors qu'une application OSX aurait été plus utile..etc...

J'ai des tas d'autres exemples..sutout concernant Icloud.. le monde pro qui aime bien apple souffre quand même de ne pas être écouté :)

avatar Un Type Vrai | 

Sans port USB-C ... Bref, l'iPad Pro est un IPAD = un objet consommateur de contenu.

Les développeurs ont raisons de s'en tenir à l'écart tant que iOS n'apporte pas les briques qui manquent pour travailler dessus (ouvrir le même fichier dans divers apps, par exemple).

avatar albert-a-l-ouet | 

Apple n'est pas assez reconnaissant avec les développeurs, il ne faudrait pas qu'ils oublient qu'une partie du succès dépende de leurs contenus !

avatar Un Type Vrai | 

Les développeurs profitent aussi de la part de marché d'Apple...

Donc bon, c'est un cercle vertueux.

avatar byte_order | 

Part de marché qui n'en serait pas là sans les applications.
On dirait l'histoire de l'oeuf ou de la poule, quoi.

Sauf qu'en fait, non.
Une plateforme ne sert à rien sans des applications s'appuyant dessus.
Et les applications n'apparaissent que si la plateforme permet d'en developper facilement et si y'a un marché soit important soit en demande.

C'est pas tant un cercle verteux - ce qui sous-entendrait que cela ne peut aller que de mieux en mieux une fois initié - mais une question de masse critique de chaque coté : assez d'applications coté plateforme, assez d'interet à développer pour cette plateforme de l'autre.

Selon l'évolution de la plateforme, tant du point de vu quantitatif (part de marché) que qualitatif, la masse critique peut très bien changer.

Pages

CONNEXION UTILISATEUR