Sen:te, des développeurs Mac en Suisse, à Lausanne

Pouvez-vous tout d'abord nous présenter votre société, Sen:te ?

Sen:te est une société de développement informatique basée à Lausanne, Suisse.

A nos débuts en 1994 nous étions spécialisés dans les cours sur la conception "orienté-objet", le développement évolutif de logiciel, la programmation sur NeXT, et le web qui en était à ses débuts. Aujourd'hui, l'iPhone a remplacé NeXT et notre expertise s'est étendue à d'autres environnements et à des domaines variés. Nous employons 10 ingénieurs.

Vous revendiquez plus de 10 ans d'expérience cocoa...

Certains d'entre nous utilisent Objective C et Interface Builder depuis 20 ans!

On clame un peu partout le grand retour du Mac en entreprise. Comment observez-vous l'évolution du marché des logiciels en l'Objective C ces dernières années ? La demande est-elle réellement croissante sur le terrain ? Particulièrement en Suisse ?

Les parts de marché du Macintosh dans le grand public sont importantes et augmentent un peu partout dans le monde et notamment en Suisse et en France. Cela crée une masse critique qui pousse par exemple les opérateurs de télécommunication ou les fabriquants de matériel à supporter Mac OS X et, effectivement, la demande de développement Mac est à la hausse.

Quels logiciels avez-vous déjà développé pour l'iPhone ?

Pour des raisons contractuelles nous ne pouvons nommer les clients et les applications, publiées sur l'App Store ou non. Nous avons réalisé des applications dans des domaines divers dont la finance, la télésurveillance, le commerce électronique, la télévision, et le jeu. Nous mettons à disposition des développeurs iPhone quelques utilitaires, libres et gratuits. Nous donnons aussi depuis presque une année un cours de programation en français très apprécié. Enfin nous avons une longue liste d'idées que nous espérons transformer en
produits.

Comment avez-vous pris le virage de l'embarqué ? Cela impose-t-il de revoir sa façon de développer ?

Il y a des contraintes techniques différentes et intéressantes: peu de mémoire, processeurs moins rapides, systèmes d'exploitation plus rustiques, mais les bonnes pratiques restent les mêmes.

Toutefois, le développpement pour iPhone n'est en rien comparable à l'embarqué traditionnel tel que nous le pratiquons par ailleurs sur d'autres systèmes. Apple a adroitement abstrait l'aspect embarqué de l'iPhone, de sorte que l'environnement de développement (Xcode, Objective-C, Cocoa Touch) est pratiquement identique à celui du Mac.

Simplement, sur iPhone, la sanction en cas de mauvaise gestion de la mémoire, est plus immédiate, puisque l'application quitte très rapidement, quand elle n'est pas refusée sur l'App Store. Le développement iPhone demande de porter une attention particulière à une bonne utilisation de la mémoire et du temps processeur.

Avez-vous pu comparer avec les SDK de la concurrence ? (GPhone, Blackberry...)

Le GPhone a plusieurs inconvénients, il arrive un peu tard par rapport à l'iPhone, les applications ne pouvaient jusqu'à récemment n'être écrites qu'en Java. Android doit aussi supporter des appareils produits par différents fabriquants, ce qui rend potentiellement plus compliquées certaines évolutions. Un avantage d'Android est qu'il est ouvert.

Quant au Blackberry, nous n'avons pas de connaissances sur son SDK. On sait par contre que l'iPhone reste encore un challenger de RIM sur le marché des grandes entreprises.

Un autre concurrent innovant est le Palm Pre, qui propose de développer des applications natives à l'aide de technologies web, avec un écran multi-touch, un clavier physique, et avec la possibilité d'utiliser plusieurs applications simultanément. Palm a d'ailleurs engagé plusieurs anciens ingénieurs d'Apple, dont Jon Rubinstein, le père du premier iMac et du premier iPod. Mais il arrive un peu tard à notre avis.

Tant mieux si la concurrence encourage l'innovation.

Avoir choisi l'ObjectiveC constitue une certaine logique pour Apple. Mais cela nuit fortement à la portabilité des applications sur d'autres plate-formes. Le choix du Java ou du C++ n'aurait-il pas été plus pratique pour les développeurs ?

Par rapport à Java et C++, Objective C est élégant, simple et puissant. Il a été choisi par NeXT à ses débuts, une époque ou Java n'existait pas et C++ à peine. Que ce langage ait résisté aux modes depuis cette époque prouve sa qualité. Interface Builder n'aurait pas été possible dans des langages aussi rigide que C++ ou Java et est d'ailleurs toujours inégalé 20 ans après.

En ce qui concerne C++, on peut tout à fait compiler et exécuter du code C ou C++ sur iPhone.

Plus que le langage lui même, ce qui diminue la portabilité des applications iPhone est l'utilisation des frameworks très aboutis qui font partie du SDK et n'ont pas d'équivalents ailleurs.

Beaucoup qualifient le SDK de l'iPhone comme étant "très mature" et particulièrement riche, malgré son jeune âge. Mais de nombreux développeurs pestent contre quelques limitations ou contre un manque de stabilité, d'une mauvaise gestion de la mémoire de l'appareil... Quel est votre point de vue là-dessus ? Avez-vous rencontré de vraies impasses/limitations techniques ?

Nous n'avons pas constaté les problèmes que vous mentionnez, à notre avis ces critiques proviennent surtout d'un manque d'expérience avec l'environnement. [NDLR : le SDK de l'iPhone attire en effet de nombreux "nouveaux" développeurs sur la plateforme Apple.]

En gros, le SDK est un sous-ensemble de celui du Mac, adapté à l'iPhone et il n'est donc pas si jeune mais le résultat de 20 ans d'évolution depuis NeXTSTEP. Il a bien entendu des limites, ce qui n'est pas forcément négatif. Pour un bon ingénieur, les contraintes sont un facteur de créativité et de progrès.

Les contraintes les plus lourdes sont plutôt administratives : celles liées à la signature du code, à la publication sur l'App Store, et l'impossibilité pour l'utilisateur normal d'installer des applications sans passer par l'App Store ou payer une license développeur, ce qui empêche l'utilisation de code sous license GPL par exemple.

Les outils de debugging d'Apple sont-il à la hauteur de ce qui se fait sur le marché ? (notamment pour monitorer l'appareil, le simulateur...)Qu'est-ce qui vous a manqué le plus ?

Les outils de debugging sont non seulement à la hauteur mais ont des années d'avance sur la concurrence. Xcode permet de cross-compiler et de déboguer pas à pas une application sur l'iPhone. Instruments permet de surveiller, d'analyser et d'optimiser différents aspects tels que le l'utilisation du processeurs, de la mémoire vive, l'accès au disque (en l'occurrence à la mémoire flash) ou au réseau.

Ce qui nous manque le plus: pouvoir voir sur le Mac, l'écran de l'iPhone et pouvoir installer du code sur l'iPhone par le réseau sans fil, sans connexion physique.

D'un point de vue purement matériel, l'appareil vous parait-il correctement dimensionné ? Est-ce que les compromis et les choix techniques sont importants pour ne pas perdre en vitesse/réactivité ?

Le processeur de l'iPhone 3G tourne à 400 MHz avec 128 MB de RAM, il est donc plus puissant que les premiers iMac. Le 3 GS est encore plus rapide. Cela est tout à fait suffisant, pour autant que l'on prenne le soin de traiter les données correctement. Certaines mauvaises pratiques peuvent passer inaperçues sur Mac OS X, et se révèlent sur l'iPhone par des lenteurs, voir des plantages.

Est-ce que l'iPhone reste encore majoritairement cantonné à des applications "légères" ou avez-vous déjà des demandes plus abouties en terme de développement ?

Dans le cadre d'une application qui se contente d'afficher des données distantes et de faire des opérations simples, une application web suffit. Toutefois, même dans le cas d'une application légère, certains clients préfèrent une application native pour pouvoir être présents sur l'App Store.

Nous avons d'autres demandes qui nécessitent d'accéder à des informations contenues dans l'iPhone, de pouvoir interagir avec l'écran multitouch, de communiquer dans le réseau local avec Bonjour, d'utiliser la géolocalisation, du streaming video, etc.

Comment trouvez-vous l'attitude d'Apple, qui n'autorise pas (pour le moment) les applications à facturer directement aux clients ? Est-ce que c'est bloquant pour certains développement ?

Il est possible de déployer une application sans passer par l'AppStore. Un déploiement dit "ad-hoc" coûte 100$ pour 100 iPhones ou 300$ pour 500 iPhones.

Beaucoup "jailbreak"(ent) leur iPhone, afin d'obtenir des logiciels non distribués par Apple (comme de la VoiP en 3G, le mode modem...). De ce fait, l'appareil se comporte différemment, et manque de stabilité. Comment prenez-vous cela en compte dans le développement ? Effectuez-vous des tests sur les appareils craqués ? Les ignorez-vous totalement ?

Certains clients nous demandent de réaliser des prototypes internes, des "proofs of concept", qui ne sont pas destinés à être distribués sur l'App Store, mais à démontrer une technologie particulière. Cela peut être par exemple l'accès aux fichiers musicaux de iTunes, impossible sans jailbreaker son iPhone jusqu'à présent.

Pour le reste, il est impossible de savoir à l'avance ce qui se trouve sur un iPhone jailbreaké, donc on teste les applications sur des iPhones non jailbreakés.

Quel conseil donneriez-vous aux jeunes développeurs pour iPhone ? Quels sont les pièges à ne pas commettre ?

Ne pas négliger la bonne gestion de la mémoire, ne pas mettre toute l'interface dans un même fichier, utiliser Instruments pour optimiser le code. Se remettre en question avant de penser qu'Objective C ou Interface Builder sont mauvais.

Suivre notre cours intensif de trois jours sur le développement
iPhone ! iPhone-class.com

Et penser à tester l'application en mode avion avant de l'envoyer à Apple.

Allez, un petit pronostique... Comment imaginez-vous le prochain iPhone ? [NDLR : le 3GS n'était pas encore annoncé quand nous avons soumis nos questions... ]

Facile, vu que ces réponses sont faites après sa sortie : plus rapide, meilleur appareil-photo. La boussole, c'est génial mais nous ne pensions pas en trouver une.

Par les nouvelles APIs qu'elles mettent à disposition (Bluetooth, MapKit, CoreData, possibilité de vendre des services dans une application, etc), on peut s'attendre à de nouveaux types de logiciels et à de nouveaux usages encore insoupçonnés.

Nous remercions chaleureusement Sen:te pour avoir répondu à nos questions!