En l'espace de quelques mois, Apple a créé un véritable écosystème autour de sa plate-forme mobile. L'App Store recense officiellement plus de 140 000 applications et est utilisé par 75 millions de personnes. Un succès difficilement plausible lorsqu'Apple a présenté son kit de développement il y a près de deux ans. Se rendant compte du potentiel des terminaux mobiles d'Apple, des milliers et de milliers de développeurs (plus de 32.000 éditeurs rien que sur l'App Store américain) se sont équipés de Mac, ont installé Xcode, se sont mis à l'Objective-C et ont commencé à développer des applications pour l'iPhone.
Le succès est tel que la conférence des développeurs (WWDC) affiche complet maintenant chaque année. Le succès de l'App Store a créé des besoins : ces derniers mois, on a vu quantité de livres relatifs à la programmation sur iPhone sortir en librairies. D'autre part, de plus en plus d'organismes proposent des formations au développement sur l'iPhone. C'est le cas notamment de Pythagore F.D. Les cours sont animés par Benoît Widemann, un vieux "routier" du monde Mac, à qui l'on doit de nombreux programmes. Les plus anciens se souviennent de JoliTerm et JoliPhone.
Quel est le profil des développeurs iPhone ? Quelles sont les difficultés que rencontrent les personnes qui se mettent à l'Objective-C ? Quelles sont les erreurs à ne pas faire lorsque l'on développe une application l'iPhone ? L'iPad sera-t-il un succès ? Autant de questions auxquelles Benoît Widemann a bien voulu répondre.
Quels sont les profils des personnes qui assistent aux formations iPhone ? Des développeurs web, des développeurs Mac, des développeurs Windows, des profils plus atypiques ?
La majorité des élèves vient du monde .net ou du php, parfois Java. Il y a peu de développeurs Mac, les tutoriels sont amplement suffisants lorsqu'on maîtrise déjà Cocoa sur Mac. J'ai eu aussi des transfuges de FileMaker ou 4D, un qui n'avait pratiqué que du C pur, novice en programmation objet. Curieusement, les handicaps ne sont pas toujours là où l'on s'y attend.
On a l'impression qu'Apple a réussi avec l'iPhone ce qu'elle n'a jamais réussi totalement avec le Mac : à savoir amener un nombre très important de développeurs à se pencher sur sa plate-forme mobile. Qu'en pensez-vous ?
C'est indiscutable. Le succès de l'iPhone, comme celui qui s'annonce pour l'iPad, y sont évidemment pour beaucoup. On voit les étudiants arriver en masse, mais aussi des développeurs expérimentés se tourner vers la plate-forme. On voit des SSII s'y intéresser et pousser leurs collaborateurs à s'y former. On voit des PME souhaitant porter un produit vers l'iPhone chercher en vain un prestataire qualifié disponible, et décider finalement d'envoyer ses propres développeurs en formation. On voit des "web-agencies" poussées vers l'iPhone par les demandes de leurs clients, alors qu'ils n'ont pas d'autres compétences en interne que PHP et Flash pour développer...
On insiste beaucoup sur le côté grand public de l'iPhone à cause de sa simplicité d'emploi, des nombreux jeux disponibles sur l'App Store. Mais voyez-vous parmi les gens que vous formez des personnes qui ont pour vocation par la suite de mettre au point des outils pour les professionnels, des solutions verticales … ?
Oui, c'est même la majorité. L'explosion actuelle est nettement ciblée sur le développement de solutions verticales, plus encore que vers le grand public. Il ne faut pas oublier qu'il y a déjà 130.000 programmes disponibles, donc la concurrence est rude sur les applications horizontales. A contrario un développeur compétent trouvera du boulot facilement dans des domaines inattendus, la demande étant extrêmement diverse.
Le SDK de l'iPhone est souvent mis à jour. En tant que formateur, est-ce que cela vous pose des problèmes ?
Les mises à jour majeures suivent les évolutions du hardware. Le 3GS a ajouté la boussole, la version 3.0 des améliorations sur Cocoa Touch, des objets enrichis, etc. Je suis en train de préparer un chapitre sur l'iPad que j'ajouterai au cours dès que la confidentialité sera levée. Techniquement il y a peu de différences, en revanche la conception de l'interface utilisateur est sensiblement revue. On profite de l'espace disponible sur l'écran pour sauter des étapes hiérarchiques dans la navigation, comme le fait l'application Mail.
Au niveau de la formation, quel est/sont les points les plus délicats sur lesquels les élèves connaissent le plus de difficulté ?
Tout dépend de leurs compétences au départ. Ceux qui n'ont aucune pratique de la programmation objet tendent à buter sur l'architecture des applications. Ils comprennent les exercices grâce aux explications, mais sortent du cours avec une conscience aiguë de l'expérience qui leur reste à accumuler sur les mois suivants. Ils maîtrisent les bases de l'API Cocoa Touch et sont à même de travailler dans une équipe, à condition d'être "coachés" par un chef de projet pour l'architecture des objets.
Pour ceux qui arrivent au contraire avec un bagage plus élevé, la difficulté est plutôt de parvenir à désapprendre les habitudes inappropriées. En général ça se passe bien... mais certains partent sur le SDK comme des fusées alors qu'ils n'ont même jamais utilisé un iPhone, et n'en ont d'ailleurs pas l'intention. Ceux-là le considèrent comme un gadget indigne de leur talent, ils ne sont vraiment là que parce que leur employeur les y oblige. Il est très, très difficile de réussir la formation dans un tel cas, mais on voit parfois un éclair d'illumination se produire à mi-parcours !
La gestion de la mémoire reste un point noir. Ceux qui viennent de Java ou de PHP sont horrifiés d'avoir même à seulement s'en préoccuper. Les oublis de désallocation constituent les erreurs les plus fréquentes dans les exercices. Les chaînes de caractères aussi perturbent beaucoup certains élèves qui se demandent pourquoi un langage si moderne est en même temps à ce point en retard sur des opérations pourtant basiques.
Est-ce que la conception d'une interface adaptée à ces appareils, la philosophie générale d'iPhone OS, l'intégration de la gestuelle multi-touch, etc ne sont pas finalement des choses aussi importantes que l'apprentissage de la programmation ?
Absolument. Il est impossible de développer une application iPhone acceptable sans être soi-même un utilisateur habitué à l'iPhone, imprégné des guidelines sur l'interface. Il faut passer du temps à jouer avec, télécharger des tombereaux d'applications, se servir réellement du plus grand nombre possible en les poussant dans leurs retranchements. On découvre ainsi les pièges dans lesquels ne pas tomber. On perçoit le haut niveau de qualité auquel la barre s'est stabilisée, même si l'on trouve tout et n'importe quoi sur l'App Store.
Et est-ce qu'il n'y a pas là-aussi un très gros travail pédagogique à faire auprès de ces développeurs ?
Il faut souvent les freiner sur le code et les pousser vers l'analyse des comportements d'utilisateurs. Par exemple, le temps d'activité d'une application iPhone est incroyablement bref : on lance, on regarde un truc et on quitte, parfois en quelques secondes à peine. C'est de ce genre de choses dont il faut s'imprégner quand on développe, car on a facilement tendance à l'oublier quand on est concentré sur la liste des fonctionnalités de son application et tous les merveilleux avantages qu'elle va offrir à l'utilisateur, qui s'en fiche totalement. Le choix de quelques fonctionnalités simples et directes, bien ciblées, n'est pas facile. Il faut apprendre à couper tout ce qui dépasse et se concentrer sur l'usage réel de l'application par ses futurs utilisateurs.
Et est-ce que d'ailleurs le premier conseil n'est pas de leur dire de s'attacher les service de gens (graphistes, designer) spécialisés dans ces domaines ?
C'est encore une compétence rare. La simple préoccupation du design d'interface et de l'ergonomie reste l'exception parmi les développeurs. De leur côté, les graphistes sont rarement intéressés par l'ergonomie, la plupart se contente de râler parce que Flash ne marche pas sur l'iPhone et n'imaginent pas une seconde que l'accessibilité puisse les concerner. Il m'est arrivé d'intervenir dans des écoles de design sur le sujet et clairement, il y a du chemin à faire...
A écouter les développeurs iPhone, on a l'impression que la gestion de la mémoire reste un gros point faible actuellement, par rapport à ce qu'il se fait ailleurs. Qu'en est-il exactement ?
Les avis sont partagés. Personnellement j'aime bien le système du retain/release, c'est simple, efficace et ça se trace bien en debug. La gestion automatique avec le garbage collector est applaudie par certains, moi je suis un peu dubitatif et je suis ravi qu'elle soit restée optionnelle.
Objective-C est une surcouche du langage C avec un runtime dynamique. Si on essaie de le transformer en langage de plus haut niveau qu'il n'est réellement, on s'éloigne de ses fondamentaux et de sa philosophie. J'ai l'impression, en fait, que le garbage collector est surtout une concession ajoutée pour attirer vers Cocoa les développeurs Java. En pratique, je préfère m'en passer et ça ne me manque pas du tout.
Lorsque l'on développe sur l'iPhone, l'effet halo est obligatoire du fait qu'il faut impérativement un Mac, enfin si on veut utiliser les outils d'Apple. Est-ce que cela va créer des vocations sur Mac ?
C'est possible. Toutefois, l'API du Mac est beaucoup plus vaste et complexe que celle de l'iPhone. Le Mac est un vieux système, qu'il faut digérer avec tout son historique pour le maîtriser. Certaines fonctionnalités sont inaccessibles en Cocoa. On trouve encore des reliquats de Mac OS 9 dans les API, on a parfois l'impression de fouiller dans un fond de tiroir pour retrouver une vieille ficelle. À l'inverse, l'iPhone a été débarrassé de toutes ces lourdeurs, il est donc bien plus facile à aborder. Le fait que son API soit moins complète la rend aussi plus digeste. Et à certains égards, elle est plus avancée que celle du Mac.
Par ailleurs, les modèles économiques construits autour de l'iPhone sont clairs et simples. L'iPad arrive avec une nouvelle virginité, des services à inventer, des applications à écrire, des marchés à prendre. La situation du Mac est plus hasardeuse, certainement beaucoup plus encombrée et concurrentielle. Mais on en fait toujours avec plaisir !
On voit de plus en plus de solutions pour concevoir des applications iPhone en Flash, en Java ou en C#. Croyez-vous au potentiel de ces solutions ? Est-ce que cela peut être une menace pour Xcode ?
Sans doute pas une menace : Xcode continue d'évoluer pour répondre aux besoins des développeurs. Il y a cependant quelques produits intéressants. On peut citer par exemple Corona, qui s'appuie sur OpenGL en ressemblant furieusement à ActionScript (voir notre article Apple aurait voulu Flash sur iPhone). Ou encore Cappuccino et le langage Objective-J, lequel est une extension objet de Javascript conçue comme Objective-C, Cappuccino reprenant point par point les fonctionnalités de Cocoa (voir notre article Cappuccino marie Cocoa avec le web). Il y a même un générateur d'interface, Atlas, qui ressemble à Interface Builder (voir Atlas : pour créer des applications web Cappuccino).
Dans ces deux exemples, on a affaire à des produits qui couvrent des besoins distincts de ceux déjà couverts par Xcode. Corona intéressera ceux qui disposent d'une base de code en Flash et souhaitent la porter à moindre frais vers OpenGL. Cappuccino sert à développer des applications web en réutilisant son savoir-faire de développeur Cocoa, mais ne remplace pas celui-ci pour l'iPhone car le différentiel de performances à l'exécution est considérable et le restera encore un bon moment.
À long terme, c'est beaucoup moins certain. Si le "cloud computing" démarre vraiment, ce qui me semble très probable avec l'arrivée de l'iPad, on va voir apparaître des applications web offrant des services en ligne à valeur ajoutée, exploitant les niches les plus improbables, et dont le seul nombre justifiera l'évolution des outils de développement. Rapidement, les performances des machines et du réseau seront suffisantes pour que le gros des développements se contente d'applications web, à la manière des sites de jeux en Flash d'aujourd'hui, mais s'appuyant sur les standards du web (HTML 5, Javascript). Le recours aux langages de plus bas niveau pour développer finira par devenir l'affaire d'un petit nombre de spécialistes, un peu comme l'assembleur aujourd'hui.
On n'a jamais disposé d'une telle panoplie. Les outils sont monstrueusement puissants. Les idées et les concepts circulent bien grâce à l'internet. La qualité du code s'améliore : open source, bonnes pratiques, standards, contrôle de flux, analyse automatique du code source, tests unitaires, outils de debug et d'optimisation... Les développeurs sont vraiment gâtés ! À se demander comment il est possible que certaines applis persistent à ramer autant...
Par rapport à ses API, son environnement de développement… avez-vous une idée vers quelles directions Apple va aller ? Avez-vous des "désirs" à ce niveau ?
Ça rejoint la question précédente : la grande révolution récente sur Mac est le bridge Cocoa, qui permet d'exploiter l'API depuis d'autres langages comme Python, Ruby, AppleScript ou Javascript. On est ici dans un contexte de scripting orienté objet extrêmement moderne, où les langages partagent bien des concepts.
On sent une évolution rapide et une convergence générale. Apple, via le WebKit d'une part, via ses réticences connues sur Flash, pousse très fort le HTML 5 et la modernisation des CSS. Tout ça aura certainement un impact sur l'apparence des applications, tant sur le Mac que sur l'iPhone, sinon sous Windows puisque le WebKit y est présent avec Safari et Chrome. Firefox vire Flash à son tour... les lignes bougent et les standards du web jouent leur rôle à plein.
Les application web fonctionnent déjà sur l'iPhone. On peut mettre en ligne une application sous forme de page web et installer son icône sans passer par l'App Store (et sans jailbreak...). Lorsqu'on mesure ce que ces applications web peuvent faire avec HTML 5, CSS 3 s'appuyant sur Core Animation, et le bridge Javascript-Cocoa pour le code, on imagine facilement qu'à moyen terme, Objective-C sera réservé aux "gros" développements et que la plupart des applis prendront des chemins plus proches du scripting. Ça sera encore plus sensible avec l'iPad, où le WebKit va se déployer sur un écran plus grand.
A titre personnel, que pensez-vous de l'iPad ? La mayonnaise va-t-elle prendre ?
Bien sûr qu'elle va prendre. Ça va être un massacre.
L'iPad va toucher un nombre incroyable de professions et d'activités. C'est du pain béni pour les développeurs, une ouverture pour des nouvelles applications dans tous les domaines, de la niche professionnelle la plus verticale au jeu de plateau le plus grand public. Sa compatibilité avec les applications iPhone va évidemment aider son lancement, mais c'est réellement avec ses propres applications que l'iPad va décoller, celles qui l'exploiteront pour ce qu'il est et non comme un gros iPhone. Vous croyez qu'il y a une application pour tout sur l'iPhone ? Attendez de voir ce qui va se passer avec l'iPad... Les développeurs ne vont pas chômer, c'est sûr.
Un détail intéressant est l'ouverture de la téléphonie IP en 3G, verrouillée jusqu'ici pour ne pas mettre en péril les opérateurs... et discrètement déverrouillée en même temps que l'annonce de l'iPad dépourvu de téléphonie classique ! Les opérateurs devront suivre la demande et proposer des forfaits "data-only" illimités à des prix raisonnables, que l'on espère proches des 15-30$ annoncés aux USA. Le GSM ira doucement rejoindre le Bibop dans les oubliettes, en quelques années à peine.
Un iPad n'est pas un iPhone, ni un Mac, c'est un objet nouveau qui va permettre des usages nouveaux, intéresser d'autres populations d'utilisateurs, bousculer les habitudes, alléger les cartables des enfants, faciliter le suivi des patients à l'hôpital. Ce n'est pas, comme certains l'ont écrit, un simple terminal de "consommation". Bien au contraire, c'est un outil avec lequel on produira des données multiformes (la caméra viendra) et qui appellera le développement d'applications pour les manipuler. C'est l'objet avec lequel le "cloud computing" va massivement décoller et trouver sa justification. Je pense qu'on reparlera bientôt de MobileMe et des prochaines surprises d'Apple sur le sujet. La concurrence avec Google sera rude... La clé USB est aussi morte que la disquette !
Le succès est tel que la conférence des développeurs (WWDC) affiche complet maintenant chaque année. Le succès de l'App Store a créé des besoins : ces derniers mois, on a vu quantité de livres relatifs à la programmation sur iPhone sortir en librairies. D'autre part, de plus en plus d'organismes proposent des formations au développement sur l'iPhone. C'est le cas notamment de Pythagore F.D. Les cours sont animés par Benoît Widemann, un vieux "routier" du monde Mac, à qui l'on doit de nombreux programmes. Les plus anciens se souviennent de JoliTerm et JoliPhone.
Quel est le profil des développeurs iPhone ? Quelles sont les difficultés que rencontrent les personnes qui se mettent à l'Objective-C ? Quelles sont les erreurs à ne pas faire lorsque l'on développe une application l'iPhone ? L'iPad sera-t-il un succès ? Autant de questions auxquelles Benoît Widemann a bien voulu répondre.
Quels sont les profils des personnes qui assistent aux formations iPhone ? Des développeurs web, des développeurs Mac, des développeurs Windows, des profils plus atypiques ?
La majorité des élèves vient du monde .net ou du php, parfois Java. Il y a peu de développeurs Mac, les tutoriels sont amplement suffisants lorsqu'on maîtrise déjà Cocoa sur Mac. J'ai eu aussi des transfuges de FileMaker ou 4D, un qui n'avait pratiqué que du C pur, novice en programmation objet. Curieusement, les handicaps ne sont pas toujours là où l'on s'y attend.
On a l'impression qu'Apple a réussi avec l'iPhone ce qu'elle n'a jamais réussi totalement avec le Mac : à savoir amener un nombre très important de développeurs à se pencher sur sa plate-forme mobile. Qu'en pensez-vous ?
C'est indiscutable. Le succès de l'iPhone, comme celui qui s'annonce pour l'iPad, y sont évidemment pour beaucoup. On voit les étudiants arriver en masse, mais aussi des développeurs expérimentés se tourner vers la plate-forme. On voit des SSII s'y intéresser et pousser leurs collaborateurs à s'y former. On voit des PME souhaitant porter un produit vers l'iPhone chercher en vain un prestataire qualifié disponible, et décider finalement d'envoyer ses propres développeurs en formation. On voit des "web-agencies" poussées vers l'iPhone par les demandes de leurs clients, alors qu'ils n'ont pas d'autres compétences en interne que PHP et Flash pour développer...
On insiste beaucoup sur le côté grand public de l'iPhone à cause de sa simplicité d'emploi, des nombreux jeux disponibles sur l'App Store. Mais voyez-vous parmi les gens que vous formez des personnes qui ont pour vocation par la suite de mettre au point des outils pour les professionnels, des solutions verticales … ?
Oui, c'est même la majorité. L'explosion actuelle est nettement ciblée sur le développement de solutions verticales, plus encore que vers le grand public. Il ne faut pas oublier qu'il y a déjà 130.000 programmes disponibles, donc la concurrence est rude sur les applications horizontales. A contrario un développeur compétent trouvera du boulot facilement dans des domaines inattendus, la demande étant extrêmement diverse.
Le SDK de l'iPhone est souvent mis à jour. En tant que formateur, est-ce que cela vous pose des problèmes ?
Les mises à jour majeures suivent les évolutions du hardware. Le 3GS a ajouté la boussole, la version 3.0 des améliorations sur Cocoa Touch, des objets enrichis, etc. Je suis en train de préparer un chapitre sur l'iPad que j'ajouterai au cours dès que la confidentialité sera levée. Techniquement il y a peu de différences, en revanche la conception de l'interface utilisateur est sensiblement revue. On profite de l'espace disponible sur l'écran pour sauter des étapes hiérarchiques dans la navigation, comme le fait l'application Mail.
Au niveau de la formation, quel est/sont les points les plus délicats sur lesquels les élèves connaissent le plus de difficulté ?
Tout dépend de leurs compétences au départ. Ceux qui n'ont aucune pratique de la programmation objet tendent à buter sur l'architecture des applications. Ils comprennent les exercices grâce aux explications, mais sortent du cours avec une conscience aiguë de l'expérience qui leur reste à accumuler sur les mois suivants. Ils maîtrisent les bases de l'API Cocoa Touch et sont à même de travailler dans une équipe, à condition d'être "coachés" par un chef de projet pour l'architecture des objets.
Pour ceux qui arrivent au contraire avec un bagage plus élevé, la difficulté est plutôt de parvenir à désapprendre les habitudes inappropriées. En général ça se passe bien... mais certains partent sur le SDK comme des fusées alors qu'ils n'ont même jamais utilisé un iPhone, et n'en ont d'ailleurs pas l'intention. Ceux-là le considèrent comme un gadget indigne de leur talent, ils ne sont vraiment là que parce que leur employeur les y oblige. Il est très, très difficile de réussir la formation dans un tel cas, mais on voit parfois un éclair d'illumination se produire à mi-parcours !
La gestion de la mémoire reste un point noir. Ceux qui viennent de Java ou de PHP sont horrifiés d'avoir même à seulement s'en préoccuper. Les oublis de désallocation constituent les erreurs les plus fréquentes dans les exercices. Les chaînes de caractères aussi perturbent beaucoup certains élèves qui se demandent pourquoi un langage si moderne est en même temps à ce point en retard sur des opérations pourtant basiques.
Est-ce que la conception d'une interface adaptée à ces appareils, la philosophie générale d'iPhone OS, l'intégration de la gestuelle multi-touch, etc ne sont pas finalement des choses aussi importantes que l'apprentissage de la programmation ?
Absolument. Il est impossible de développer une application iPhone acceptable sans être soi-même un utilisateur habitué à l'iPhone, imprégné des guidelines sur l'interface. Il faut passer du temps à jouer avec, télécharger des tombereaux d'applications, se servir réellement du plus grand nombre possible en les poussant dans leurs retranchements. On découvre ainsi les pièges dans lesquels ne pas tomber. On perçoit le haut niveau de qualité auquel la barre s'est stabilisée, même si l'on trouve tout et n'importe quoi sur l'App Store.
Et est-ce qu'il n'y a pas là-aussi un très gros travail pédagogique à faire auprès de ces développeurs ?
Il faut souvent les freiner sur le code et les pousser vers l'analyse des comportements d'utilisateurs. Par exemple, le temps d'activité d'une application iPhone est incroyablement bref : on lance, on regarde un truc et on quitte, parfois en quelques secondes à peine. C'est de ce genre de choses dont il faut s'imprégner quand on développe, car on a facilement tendance à l'oublier quand on est concentré sur la liste des fonctionnalités de son application et tous les merveilleux avantages qu'elle va offrir à l'utilisateur, qui s'en fiche totalement. Le choix de quelques fonctionnalités simples et directes, bien ciblées, n'est pas facile. Il faut apprendre à couper tout ce qui dépasse et se concentrer sur l'usage réel de l'application par ses futurs utilisateurs.
Et est-ce que d'ailleurs le premier conseil n'est pas de leur dire de s'attacher les service de gens (graphistes, designer) spécialisés dans ces domaines ?
C'est encore une compétence rare. La simple préoccupation du design d'interface et de l'ergonomie reste l'exception parmi les développeurs. De leur côté, les graphistes sont rarement intéressés par l'ergonomie, la plupart se contente de râler parce que Flash ne marche pas sur l'iPhone et n'imaginent pas une seconde que l'accessibilité puisse les concerner. Il m'est arrivé d'intervenir dans des écoles de design sur le sujet et clairement, il y a du chemin à faire...
A écouter les développeurs iPhone, on a l'impression que la gestion de la mémoire reste un gros point faible actuellement, par rapport à ce qu'il se fait ailleurs. Qu'en est-il exactement ?
Les avis sont partagés. Personnellement j'aime bien le système du retain/release, c'est simple, efficace et ça se trace bien en debug. La gestion automatique avec le garbage collector est applaudie par certains, moi je suis un peu dubitatif et je suis ravi qu'elle soit restée optionnelle.
Objective-C est une surcouche du langage C avec un runtime dynamique. Si on essaie de le transformer en langage de plus haut niveau qu'il n'est réellement, on s'éloigne de ses fondamentaux et de sa philosophie. J'ai l'impression, en fait, que le garbage collector est surtout une concession ajoutée pour attirer vers Cocoa les développeurs Java. En pratique, je préfère m'en passer et ça ne me manque pas du tout.
Lorsque l'on développe sur l'iPhone, l'effet halo est obligatoire du fait qu'il faut impérativement un Mac, enfin si on veut utiliser les outils d'Apple. Est-ce que cela va créer des vocations sur Mac ?
C'est possible. Toutefois, l'API du Mac est beaucoup plus vaste et complexe que celle de l'iPhone. Le Mac est un vieux système, qu'il faut digérer avec tout son historique pour le maîtriser. Certaines fonctionnalités sont inaccessibles en Cocoa. On trouve encore des reliquats de Mac OS 9 dans les API, on a parfois l'impression de fouiller dans un fond de tiroir pour retrouver une vieille ficelle. À l'inverse, l'iPhone a été débarrassé de toutes ces lourdeurs, il est donc bien plus facile à aborder. Le fait que son API soit moins complète la rend aussi plus digeste. Et à certains égards, elle est plus avancée que celle du Mac.
Par ailleurs, les modèles économiques construits autour de l'iPhone sont clairs et simples. L'iPad arrive avec une nouvelle virginité, des services à inventer, des applications à écrire, des marchés à prendre. La situation du Mac est plus hasardeuse, certainement beaucoup plus encombrée et concurrentielle. Mais on en fait toujours avec plaisir !
On voit de plus en plus de solutions pour concevoir des applications iPhone en Flash, en Java ou en C#. Croyez-vous au potentiel de ces solutions ? Est-ce que cela peut être une menace pour Xcode ?
Sans doute pas une menace : Xcode continue d'évoluer pour répondre aux besoins des développeurs. Il y a cependant quelques produits intéressants. On peut citer par exemple Corona, qui s'appuie sur OpenGL en ressemblant furieusement à ActionScript (voir notre article Apple aurait voulu Flash sur iPhone). Ou encore Cappuccino et le langage Objective-J, lequel est une extension objet de Javascript conçue comme Objective-C, Cappuccino reprenant point par point les fonctionnalités de Cocoa (voir notre article Cappuccino marie Cocoa avec le web). Il y a même un générateur d'interface, Atlas, qui ressemble à Interface Builder (voir Atlas : pour créer des applications web Cappuccino).
Dans ces deux exemples, on a affaire à des produits qui couvrent des besoins distincts de ceux déjà couverts par Xcode. Corona intéressera ceux qui disposent d'une base de code en Flash et souhaitent la porter à moindre frais vers OpenGL. Cappuccino sert à développer des applications web en réutilisant son savoir-faire de développeur Cocoa, mais ne remplace pas celui-ci pour l'iPhone car le différentiel de performances à l'exécution est considérable et le restera encore un bon moment.
À long terme, c'est beaucoup moins certain. Si le "cloud computing" démarre vraiment, ce qui me semble très probable avec l'arrivée de l'iPad, on va voir apparaître des applications web offrant des services en ligne à valeur ajoutée, exploitant les niches les plus improbables, et dont le seul nombre justifiera l'évolution des outils de développement. Rapidement, les performances des machines et du réseau seront suffisantes pour que le gros des développements se contente d'applications web, à la manière des sites de jeux en Flash d'aujourd'hui, mais s'appuyant sur les standards du web (HTML 5, Javascript). Le recours aux langages de plus bas niveau pour développer finira par devenir l'affaire d'un petit nombre de spécialistes, un peu comme l'assembleur aujourd'hui.
On n'a jamais disposé d'une telle panoplie. Les outils sont monstrueusement puissants. Les idées et les concepts circulent bien grâce à l'internet. La qualité du code s'améliore : open source, bonnes pratiques, standards, contrôle de flux, analyse automatique du code source, tests unitaires, outils de debug et d'optimisation... Les développeurs sont vraiment gâtés ! À se demander comment il est possible que certaines applis persistent à ramer autant...
Par rapport à ses API, son environnement de développement… avez-vous une idée vers quelles directions Apple va aller ? Avez-vous des "désirs" à ce niveau ?
Ça rejoint la question précédente : la grande révolution récente sur Mac est le bridge Cocoa, qui permet d'exploiter l'API depuis d'autres langages comme Python, Ruby, AppleScript ou Javascript. On est ici dans un contexte de scripting orienté objet extrêmement moderne, où les langages partagent bien des concepts.
On sent une évolution rapide et une convergence générale. Apple, via le WebKit d'une part, via ses réticences connues sur Flash, pousse très fort le HTML 5 et la modernisation des CSS. Tout ça aura certainement un impact sur l'apparence des applications, tant sur le Mac que sur l'iPhone, sinon sous Windows puisque le WebKit y est présent avec Safari et Chrome. Firefox vire Flash à son tour... les lignes bougent et les standards du web jouent leur rôle à plein.
Les application web fonctionnent déjà sur l'iPhone. On peut mettre en ligne une application sous forme de page web et installer son icône sans passer par l'App Store (et sans jailbreak...). Lorsqu'on mesure ce que ces applications web peuvent faire avec HTML 5, CSS 3 s'appuyant sur Core Animation, et le bridge Javascript-Cocoa pour le code, on imagine facilement qu'à moyen terme, Objective-C sera réservé aux "gros" développements et que la plupart des applis prendront des chemins plus proches du scripting. Ça sera encore plus sensible avec l'iPad, où le WebKit va se déployer sur un écran plus grand.
A titre personnel, que pensez-vous de l'iPad ? La mayonnaise va-t-elle prendre ?
Bien sûr qu'elle va prendre. Ça va être un massacre.
L'iPad va toucher un nombre incroyable de professions et d'activités. C'est du pain béni pour les développeurs, une ouverture pour des nouvelles applications dans tous les domaines, de la niche professionnelle la plus verticale au jeu de plateau le plus grand public. Sa compatibilité avec les applications iPhone va évidemment aider son lancement, mais c'est réellement avec ses propres applications que l'iPad va décoller, celles qui l'exploiteront pour ce qu'il est et non comme un gros iPhone. Vous croyez qu'il y a une application pour tout sur l'iPhone ? Attendez de voir ce qui va se passer avec l'iPad... Les développeurs ne vont pas chômer, c'est sûr.
Un détail intéressant est l'ouverture de la téléphonie IP en 3G, verrouillée jusqu'ici pour ne pas mettre en péril les opérateurs... et discrètement déverrouillée en même temps que l'annonce de l'iPad dépourvu de téléphonie classique ! Les opérateurs devront suivre la demande et proposer des forfaits "data-only" illimités à des prix raisonnables, que l'on espère proches des 15-30$ annoncés aux USA. Le GSM ira doucement rejoindre le Bibop dans les oubliettes, en quelques années à peine.
Un iPad n'est pas un iPhone, ni un Mac, c'est un objet nouveau qui va permettre des usages nouveaux, intéresser d'autres populations d'utilisateurs, bousculer les habitudes, alléger les cartables des enfants, faciliter le suivi des patients à l'hôpital. Ce n'est pas, comme certains l'ont écrit, un simple terminal de "consommation". Bien au contraire, c'est un outil avec lequel on produira des données multiformes (la caméra viendra) et qui appellera le développement d'applications pour les manipuler. C'est l'objet avec lequel le "cloud computing" va massivement décoller et trouver sa justification. Je pense qu'on reparlera bientôt de MobileMe et des prochaines surprises d'Apple sur le sujet. La concurrence avec Google sera rude... La clé USB est aussi morte que la disquette !