Interview : les défis du développement sur iPhone
par Christophe Laporte le 16.02.2010 à 18:20
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.
| |
2
1
Vos réactions (29 réactions)
Nesus
[16/02/2010 18:50]
superbe article et fine analyse^^
superbe article et fine analyse^^
Le_T
[16/02/2010 18:53]
Article très pertinent !
Je trouve que c'est une bonne idée de demander lavis Dun pro du dev de nous donner sont avis sur les techno logicielles develloper et utiliser par iPhoneOS.
Merci,
Article très pertinent !
Je trouve que c'est une bonne idée de demander lavis Dun pro du dev de nous donner sont avis sur les techno logicielles develloper et utiliser par iPhoneOS.
Merci,
Dr_cube
[16/02/2010 19:01]
Même si je n'ai pas l'expérience de Benoît Widemann, je suis développeur iPhone depuis plus d'un an et demi et j'ai enseigné le développement mobile (iPhone/Android) à des étudiants cette année. J'ai le même avis que lui sur quasiment tous les points évoqués.
En tant que spécialiste des IHM pour mobiles, je tiens à ajouter que la qualité des IHM est le point le plus important pour faire un logiciel sur iPhone ou iPad. Je ne sais pas exactement quel est le public de B. Widemann dans ses formations, mais les ingénieurs formés aujoud'hui sont généralement très largement sensibilisés à l'ingénierie des IHM. Durant mes études j'ai longtemps étudié le problème des IHM pour mobiles, alors même que l'iPhone n'était pas encore sorti. Le problème se pose depuis longtemps, et il est maintenant traité dans les formations des ingénieurs. Au niveau de la recherche, c'est encore "work in progress". Il reste beaucoup de problèmes à étudier, notamment en ce qui concerne la mobilité, et c'est assez excitant.
En outre, je suis persuadé que Google gagnerait à mettre plus de soins sur ses IHM mobiles. Android est une catastrophe sur ce point, et c'est le plus gros point faible de Google.
Faire des IHM, ce n'est pas seulement faire de jolies dégradées et de jolies transparence. Il s'agit d'un travail d'ingénieur à part entière. Apple a parfaitement intégré ce principe depuis le Mac des années 80. Je suis toujours étonné de voir que Google ou Microsoft ne présentent sur mobile quasiment que des IHM issues d'un joint fumé par un designer, sans aucune étude ou aucune science derrière.
Même si je n'ai pas l'expérience de Benoît Widemann, je suis développeur iPhone depuis plus d'un an et demi et j'ai enseigné le développement mobile (iPhone/Android) à des étudiants cette année. J'ai le même avis que lui sur quasiment tous les points évoqués.
En tant que spécialiste des IHM pour mobiles, je tiens à ajouter que la qualité des IHM est le point le plus important pour faire un logiciel sur iPhone ou iPad. Je ne sais pas exactement quel est le public de B. Widemann dans ses formations, mais les ingénieurs formés aujoud'hui sont généralement très largement sensibilisés à l'ingénierie des IHM. Durant mes études j'ai longtemps étudié le problème des IHM pour mobiles, alors même que l'iPhone n'était pas encore sorti. Le problème se pose depuis longtemps, et il est maintenant traité dans les formations des ingénieurs. Au niveau de la recherche, c'est encore "work in progress". Il reste beaucoup de problèmes à étudier, notamment en ce qui concerne la mobilité, et c'est assez excitant.
En outre, je suis persuadé que Google gagnerait à mettre plus de soins sur ses IHM mobiles. Android est une catastrophe sur ce point, et c'est le plus gros point faible de Google.
Faire des IHM, ce n'est pas seulement faire de jolies dégradées et de jolies transparence. Il s'agit d'un travail d'ingénieur à part entière. Apple a parfaitement intégré ce principe depuis le Mac des années 80. Je suis toujours étonné de voir que Google ou Microsoft ne présentent sur mobile quasiment que des IHM issues d'un joint fumé par un designer, sans aucune étude ou aucune science derrière.
manu
[16/02/2010 19:10]
Je suis extrêmement réjoui de voir un pro du développement confirmer et surtout apporter plus de précisions sur les pensées que j'ai longtemps développées sur les forums de l'iPad et ce avant même son lancement. pour moi c'est simple. c'est le PC/Mac le plus approprié pour le Cloud.
Je suis même sûr que ce sont les développeurs qui vont l'emmener dans l'Entreprise. A commencer par IBM lui même qui mise sur l'iPad pour en faire un outil de choix pour accéder à ses service Lotus et autres.
La caméra pour moi est une seconde étape. Apple fait toujours bien de proposer des technos qu'il faut au bon moment et non tout en même temps. il faut laisser aux développeurs le soin d'aborder calmement ce nouvel outil qui implique de nouveaux usages.
Je suis extrêmement réjoui de voir un pro du développement confirmer et surtout apporter plus de précisions sur les pensées que j'ai longtemps développées sur les forums de l'iPad et ce avant même son lancement. pour moi c'est simple. c'est le PC/Mac le plus approprié pour le Cloud.
Je suis même sûr que ce sont les développeurs qui vont l'emmener dans l'Entreprise. A commencer par IBM lui même qui mise sur l'iPad pour en faire un outil de choix pour accéder à ses service Lotus et autres.
La caméra pour moi est une seconde étape. Apple fait toujours bien de proposer des technos qu'il faut au bon moment et non tout en même temps. il faut laisser aux développeurs le soin d'aborder calmement ce nouvel outil qui implique de nouveaux usages.
Macinlove
[16/02/2010 19:23]
Je n'ai aucune compétences en développement, mais je me sens nettement plus éclairé après avoir lu cette excellente interview.
Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...
Je n'ai aucune compétences en développement, mais je me sens nettement plus éclairé après avoir lu cette excellente interview.
Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...
Yohmi
[16/02/2010 19:25]
Article particulièrement intéressant, et accessible surtout, ce qui est assez rare sur ce sujet (car ce n’est vraiment pas évident).
Merci beaucoup :)
Quant au ressenti de ce cher Monsieur sur l’iPad, je partage effectivement ses opinions, à un détail près : je n’aurai jamais les poches assez grandes pour un 9’’, donc je pense que le GSM n’est pas encore à enterrer. ^^
Article particulièrement intéressant, et accessible surtout, ce qui est assez rare sur ce sujet (car ce n’est vraiment pas évident).
Merci beaucoup :)
Quant au ressenti de ce cher Monsieur sur l’iPad, je partage effectivement ses opinions, à un détail près : je n’aurai jamais les poches assez grandes pour un 9’’, donc je pense que le GSM n’est pas encore à enterrer. ^^
flette
[16/02/2010 19:33]
Superbe interview. J'ai le projet de faire développer une appli iPhone pour la PME dans laquelle je bosse et, malgré que je sois pas développeur, l'interview est compréhensible et tout en posant les problématiques techniques. Bravo & merci MacG
Superbe interview. J'ai le projet de faire développer une appli iPhone pour la PME dans laquelle je bosse et, malgré que je sois pas développeur, l'interview est compréhensible et tout en posant les problématiques techniques. Bravo & merci MacG
Showmehowtolive
[16/02/2010 19:39]
via MacG Mobile
@d' cube : Android la cata niveau IHM ??? Au contraire, c'est souvent plus clair que sur iPhone grace au bouton menu par ex. La page d'accueil est aussi bien plus ergonomique.
@d' cube : Android la cata niveau IHM ??? Au contraire, c'est souvent plus clair que sur iPhone grace au bouton menu par ex. La page d'accueil est aussi bien plus ergonomique.
oomu
[16/02/2010 19:52]
tiens, je me demande bien ce qu'on peut reprocher à NSString ou le construct @ . Justement je viens d'un monde "php" / "java".
concernant, la mémoire, l'iphone/ipad n'embarque pas le "ramasse-miette" qu'a maintenant Mac os X.
-
>Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme
>moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...
ben, effectivement, un glossaire dés la page de garde serait utile. Sinon WIKIPEDIA EST LE SAUVEUR DU MONDE.
Cocoa : c'est le "cadre de développement" (framework) : c'est en gros à la fois les fonctionnalités fournies par le système pour construire une application, les bonnes pratiques à respecter, le modèle dans lequel votre application va s'inscrire (un logiciel cocoa est en gros découpé en modèles qui décrivent les données, contrôleur qui manipule les données, et vues qui permettent à l'utilisateur de dire aux contrôleurs quoi faire. ) . Cocoa repose totalement sur des facilités du langage Objective C. Il serait difficile de porter Cocoa à un autre langage sans devoir porter des aspects entiers de Objective C. (principale difficulté de feu cocoa-java)
Java : autre grand langage/cadre de développement de l'industrie. Créé par feu-Sun (maintenant oracle) et maintenu par toute la clique d'industriels (opensource tel apache, ou directement ibm par exemple). Java c'est aussi bien un langage (une grammaire), qu'un cadre de développement (Java Enterprise) qui fournit toutes les briques imaginables pour concevoir un logiciel professionnel.
Objective-C , le langage au coeur de cocoa. Objective-C est une extension du langage C pour lui apporter le modèle de programmation dit "objet", très inspiré de Smalltalk. Ses 2 principales caractéristiques (selon moi) sont d'être basé "message" et d'intégrer un moteur d'exécution (runtime) pour que les applications objective-C soient dynamiques (changer leur comportement à chaud pendant l'exécution)
tiens, je me demande bien ce qu'on peut reprocher à NSString ou le construct @ . Justement je viens d'un monde "php" / "java".
concernant, la mémoire, l'iphone/ipad n'embarque pas le "ramasse-miette" qu'a maintenant Mac os X.
-
>Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme
>moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...
ben, effectivement, un glossaire dés la page de garde serait utile. Sinon WIKIPEDIA EST LE SAUVEUR DU MONDE.
Cocoa : c'est le "cadre de développement" (framework) : c'est en gros à la fois les fonctionnalités fournies par le système pour construire une application, les bonnes pratiques à respecter, le modèle dans lequel votre application va s'inscrire (un logiciel cocoa est en gros découpé en modèles qui décrivent les données, contrôleur qui manipule les données, et vues qui permettent à l'utilisateur de dire aux contrôleurs quoi faire. ) . Cocoa repose totalement sur des facilités du langage Objective C. Il serait difficile de porter Cocoa à un autre langage sans devoir porter des aspects entiers de Objective C. (principale difficulté de feu cocoa-java)
Java : autre grand langage/cadre de développement de l'industrie. Créé par feu-Sun (maintenant oracle) et maintenu par toute la clique d'industriels (opensource tel apache, ou directement ibm par exemple). Java c'est aussi bien un langage (une grammaire), qu'un cadre de développement (Java Enterprise) qui fournit toutes les briques imaginables pour concevoir un logiciel professionnel.
Objective-C , le langage au coeur de cocoa. Objective-C est une extension du langage C pour lui apporter le modèle de programmation dit "objet", très inspiré de Smalltalk. Ses 2 principales caractéristiques (selon moi) sont d'être basé "message" et d'intégrer un moteur d'exécution (runtime) pour que les applications objective-C soient dynamiques (changer leur comportement à chaud pendant l'exécution)
oomu
[16/02/2010 19:58]
le "runtime" est un sous-programme, presque indépendant, qui va être intégré dans le logiciel proprement dit. Le runtime gère toutes sortes de tâches nécessaires au bon fonctionnement du programme. Grâce à lui, le développeur n'a pas eu besoin d'écrire le fonctionnement exacte de tout le programme : la plupart des tâches routinières sont déjà écrites.
Ainsi tous logiciel Mac Cocoa ont tous ce fameux runtime en leur sein. Il est donc naturel qu'un logiciel objective-C (cocoa) exige + de ressource qu'un simple programme C, mais le confort gagné est incommensurable et profite dans une myriade d'aspects à l'interface du Mac/iphone.
le Runtime peut être aussi externe : il est démarré puis charge le logiciel pour lui donner vie. On préféra ici dire Machine virtuelle, comme Java ou C#/.NET. mais dans le fond, ca rend un service similaire.
-
j'oubliais, mais C#/.NET est un langage/cadre de développement de Microsoft. C# est le langage, comme Objective-C est le langage, .NET est l'ensemble des briques prêtes à l'emploi, comme Cocoa. Dans son fonctionnement, .NET est plus proche de Java.
le "runtime" est un sous-programme, presque indépendant, qui va être intégré dans le logiciel proprement dit. Le runtime gère toutes sortes de tâches nécessaires au bon fonctionnement du programme. Grâce à lui, le développeur n'a pas eu besoin d'écrire le fonctionnement exacte de tout le programme : la plupart des tâches routinières sont déjà écrites.
Ainsi tous logiciel Mac Cocoa ont tous ce fameux runtime en leur sein. Il est donc naturel qu'un logiciel objective-C (cocoa) exige + de ressource qu'un simple programme C, mais le confort gagné est incommensurable et profite dans une myriade d'aspects à l'interface du Mac/iphone.
le Runtime peut être aussi externe : il est démarré puis charge le logiciel pour lui donner vie. On préféra ici dire Machine virtuelle, comme Java ou C#/.NET. mais dans le fond, ca rend un service similaire.
-
j'oubliais, mais C#/.NET est un langage/cadre de développement de Microsoft. C# est le langage, comme Objective-C est le langage, .NET est l'ensemble des briques prêtes à l'emploi, comme Cocoa. Dans son fonctionnement, .NET est plus proche de Java.
Macinlove
[16/02/2010 20:00]
@ oomu : merci pour tes définitions (même si Wiki t'a donné un coup de main ;-)
@ oomu : merci pour tes définitions (même si Wiki t'a donné un coup de main ;-)
Thierry61
[16/02/2010 21:13]
ITV très intéressant, c'est sur. Faut que le relise.
Je ne suis pas développeur, mais je rapproche l'état d'esprit de cet échange de certains propos que j'ai entendu de la part de gens qui, par le passé, n'auraient jamais parlé d'apple (hein ? le mac ? c'est quoi ce truc ?) mais évoquent aujourd'hui le phénomène iPhone et sa plate-forme de développement / commercialisation de logiciels en des termes que personne n'aurait utilisés du temps de l'Apple-fabricant-de-Mac-uniquement.
ITV très intéressant, c'est sur. Faut que le relise.
Je ne suis pas développeur, mais je rapproche l'état d'esprit de cet échange de certains propos que j'ai entendu de la part de gens qui, par le passé, n'auraient jamais parlé d'apple (hein ? le mac ? c'est quoi ce truc ?) mais évoquent aujourd'hui le phénomène iPhone et sa plate-forme de développement / commercialisation de logiciels en des termes que personne n'aurait utilisés du temps de l'Apple-fabricant-de-Mac-uniquement.
fabriceg
[16/02/2010 21:17]
via MacG Mobile
@ yohmi
Je pense que par disparition du GSM il a voulu parler de la norme GSM, pas de la téléphonie. La voix sera sur IP exclusivement, mais pas besoin de poches de 9" pour ça ;)
@ yohmi
Je pense que par disparition du GSM il a voulu parler de la norme GSM, pas de la téléphonie. La voix sera sur IP exclusivement, mais pas besoin de poches de 9" pour ça ;)
ispeed
[16/02/2010 21:49]
L'iPhone et l'iPad on s'en fou
L'iPhone et l'iPad on s'en fou
kubernan
[16/02/2010 22:08]
- L'une des approches intéressantes et parfois nouvelle pour beaucoup de développeurs qui se mettent au monde Mac est de penser les choses en termes de solutions et non en termes de fonctions.
C'est d'autant plus vrai pour le développement sur iPhone.
- Quand un développeur cri au loup concernant la gestion mémoire, il faut alors s'en méfier car :
1- La gestion mémoire version Objective-C est d'une simplicité enfantine (La règle doit tenir en quelques lignes);
2- Il y a toutes les chances que le dit développeur en question n'a jamais fait de C (en passant directement à Java par exemple), ce qui est à mon avis souvent pénalisant pour sa flexibilité intellectuelle en terme de programmation.
- Je ne vois pas trop où est le problème avec les chaînes de caractères dans Objective-C mais bon.
Bon article en tout cas.
- L'une des approches intéressantes et parfois nouvelle pour beaucoup de développeurs qui se mettent au monde Mac est de penser les choses en termes de solutions et non en termes de fonctions.
C'est d'autant plus vrai pour le développement sur iPhone.
- Quand un développeur cri au loup concernant la gestion mémoire, il faut alors s'en méfier car :
1- La gestion mémoire version Objective-C est d'une simplicité enfantine (La règle doit tenir en quelques lignes);
2- Il y a toutes les chances que le dit développeur en question n'a jamais fait de C (en passant directement à Java par exemple), ce qui est à mon avis souvent pénalisant pour sa flexibilité intellectuelle en terme de programmation.
- Je ne vois pas trop où est le problème avec les chaînes de caractères dans Objective-C mais bon.
Bon article en tout cas.
2
1
Réagir
Cinq consignes avant de réagir :
- Rester dans le cadre de la dépêche. Pour des discussions plus générales, vous pouvez utiliser nos forums.
- Développer son argumentation. Les messages dont le seul but est de mettre de l'huile sur le feu seront modifiés ou effacés sans préavis par la rédaction.
- Respecter les acteurs de l'informatique et les autres lecteurs. Les messages agressifs, vulgaires, haineux, etc. seront modifiés ou effacés sans préavis par la rédaction.
- Pour toute remarque concernant le contenu de l'article, pour nous signaler une erreur, une faute d'orthographe, une omission, merci de nous contacter exclusivement par e-mail.
- Relisez-vous, et pour les utilisateurs de Safari profitez de l'aide du navigateur : activez le menu édition > Orthographe > Vérifier l'orthographe lors de la frappe.





Mai 2012
