Les 21 et 22 septembre 2018 a eu lieu la FrenchKit, la première conférence française des développeurs iOS et macOS. Organisée à Paris par CocoaHeads Paris et Xebia, cette FrenchKit était la 3éme édition mais la première pour nous.
Nos attentes se situaient au niveau du contenu des talks bien sûr, mais pas que. A savoir que niveau événements tech iOS, les rencontres sont principalement sous forme de meet-up de quelques heures où on échange sur un sujet bien précis. Cette conférence sur deux jours uniquement sur iOS/MacOS avec une salle remplie de développeurs spécialisés était une première pour nous. En plus des talks sur les nouveaux framework d’Apple, nous espérions donc découvrir de manière plus globale les tendances et l’état de l’art du développement d’applications iOS. Mais aussi et surtout, nous espérions y rencontrer d’autres passionnés et échanger sur nos pratiques respectives.
Le bilan:
Au programme cette année, plusieurs talks tout aussi riches que variés ont été donnés : des retours d’expériences, de Swift, des bonnes pratiques de développement, de l'architecture et des librairies open-source.
Niveau participants, nous n’avons pas été déçus, de nombreux speakers étaient en effet présents dont certains très reconnus dans la communauté iOS, tels que Chris Eidhof, John Sundell, ou encore Mattt.
Nous vous parlerons ici des sujets qui nous ont marqué, les moments que nous avons apprécié, et ceux qui nous ont rendu quelque peu nostalgiques. Par exemple l’époque où pour concaténer 2 chaînes de caractère basiques, il fallait écrire:
NSString *x = [NSString stringWithFormat:@“%@%@”, a, b]
Alors qu'aujourd'hui, un simple : var x = a + b suffit.
Bref, plein de petits souvenirs qui nous ont fait réaliser à quel point il était devenu simple et intuitif de faire du développement sur iOS/MacOs. “On s’ennuierait presque !” blague le speaker.
Vincent Leroux, co-fondateur de ELDIM, nous raconte son partenariat avec Apple. ELDIM ne vous dit peut-être rien, mais en réalité elle a contribué au plus gros argument de vente de l’iPhone X, le FaceID. En effet cette entreprise française installée en Normandie est le seul fournisseur de composants au coeur de cette technologie. Vincent Leroux nous explique brièvement comment leur reconnaissance faciale fonctionne. Mais aussi comment ELDIM s’est vu projetée à une autre échelle de production. En collaborant avec Apple, elle a dû réadapter sa capacité à produire et à tenir une échéance bien précise. Il nous confie également son enthousiasme lors sa rencontre avec Tim Cook, dont la visite n’a été communiquée que quelques minutes à l’avance.
Un talk qui dégageait beaucoup de fierté, et qui a mis un grand souffle de motivation dans la salle.
Certains retours d’expériences étaient un peu moins techniques. Comme celui de Dave Verwer, auteur de la newsletter iOS Dev Weekly. Il nous explique les bons réflexes à adopter quand on est développeurs indépendants. Assez souvent, quand une idée nous traverse l’esprit nous avons tendance à nous plonger directement dans la réalisation du produit. Selon lui, ce n’est pas la bonne approche.
Dave nous présente un cycle de 4 étapes à itérer pour adapter son idée et par la même occasion son produit :
- Research, discuter avec des personnes et plus particulièrement des inconnus autour d’un sujet bien précis, “The job to be done”. A partir de là, deux catégories de personnes se présenteront à vous. Ceux qui ont déjà résolu leur problème et ceux qui ne l’ont pas encore résolu. C’est sur cette deuxième catégorie de personne qu’il faut se concentrer.
- Build, maintenant que nous avons une idée plus précise du produit à réaliser, nous pouvons commencer la réalisation de notre MVP.
- Feedback, après la mise à disposition de notre MVP, nous récoltons les retours utilisateurs et les métriques afin d’analyser l’adhésion des utilisateurs.
- Market, sans doute la phase la plus négligée. En effet sans faire de communication autour de notre produit, il passerait inaperçu et personne ne l'utiliserait. Dave précise de même que cette étape est toute aussi importante que le Build et demande d’y consacrer donc autant de temps.
Si il y a un sujet qui nous intéresse en tant que développeurs c’est bien l’Open source.
Max Howell le maîtrise parfaitement. Le créateur de Homebrew nous raconte l’histoire de la conception de son gestionnaire de paquets, au travers d’étapes selon lui qui pourrait contribuer à la réussite d’un projet open source, notamment :
Max précise également qu’il est important d’être ferme sur la direction que nous souhaitons prendre. Certains ne manqueront pas de faire des propositions qui pourraient vous écarter de votre direction principale et il faut donc savoir dire non. Enfin la dernière étape et la plus difficile, se détacher de son projet et le déléguer à la communauté. “Je m’en souviendrais toujours !”, dit-il avec un air très nostalgique.
Mais faire de l’open source ne nécessite pas forcément d’en être l’initiateur. Nous pouvons aussi bien devenir contributeur. Swift est un projet open source de choix en tant que développeur MacOS/iOS, et Dimitri Dupuis-Latour nous le fait savoir.
En effet, l’ex-développeur d’Apple qui a grandement contribué à Xcode nous explique un peu le déroulé des choses pour contribuer à Swift. Tout d'abord, nous devons aller sur le repo Github du projet, lire le Readme et cloner le projet. Jusque là rien de sorcier.
Ensuite, nous devons lancer un script spécifique présent dans le projet afin de télécharger les dépendances nécessaires pour compiler le projet. Cela correspond à peu près à 14 autres repos, le tout équivalent à 2 GB de code tout de même. Et ce n’est pas fini ! Ensuite il nous faut lancer un deuxième script qui se chargera de builder l’intégralité pour une durée d’environ 1h afin de produire à peu près 70GB d’artefacts. Mais une fois que nous avons tout d'opérationnel, par où commencer ?
La prochaine version de Swift est écrite 40% en Swift, notamment pour les librairies standard. Dimitri nous conseille de commencer par là. Il nous présente quelques exemples de contributions mineures intégrées à Swift. Par exemple la fonction toggle d’un Bool.
John Sundell, ex-employé chez Spotify fait également partie des personnes qui nous ont inspiré. Il nous fait part dans son talk “The lost art of system design” ce que devrait être le meilleur design pattern pour nos applications mobiles.
Il argumente qu’une architecture dans son sens général devrait être à la fois fonctionnelle, élégante et robuste si nous souhaitons maintenir et “scale up” notre application. L’architecture n’est pas simplement une affaire de design pattern appliqué à la lettre mais plutôt formulé de la manière suivante :
“Design + System Design = Architecture“
Une bonne architecture est découpé en plusieurs composants réutilisable et facile à maintenir.
Elle devrait utiliser des abstractions pour découpler les sous-systèmes et éviter la répétition de code. Il cite aussi des exemples comme l'injection de dépendances.
Yoichi Tagaya, créateur de la librairie Swinject, poursuit en effet que l’architecture ne doit pas être quelque chose de statique mais de dynamique en fonction du nombre d’utilisateurs et du nombre de développeurs travaillant sur l’application.
Elle doit rester modulable, maintenable et facilement testable; et cela par l’injection de dépendances comme évoqué plus tôt.
Qu’est-ce que l’injection de dépendances ? Il s’agit d’une technique où nous déclarons toutes les dépendances d’une classe à l’extérieur de cette dernière et de les lui injecter à travers son constructeur.
Sa librairie propose un pattern pour injecter les dépendances entre les classes.
Sur le papier cela semble simple, beaucoup de développeurs font de l’injection de dépendances à la main, alors pourquoi utiliser une librairie ?
Tout simplement, dans des grosses applications par exemple, nous n’avons aucune gestion du cycle de vie des dépendances et nous nous retrouvons avec beaucoup de singletons.
Son principe réside dans le fait de regrouper les dépendances dans un conteneur (Container) dans lequel nous allons instancier toutes les dépendances et faire l’injection à partir de ce dernier dans la classe cible.
La conférence s’est poursuivie par des présentations de librairies telle que celle de Chris Eidhof. Auteur du site objc.io, qui nous a fait un live coding de sa librairie appelée Layout, pour construire ses layouts programmatiquement. Chose qui n'est pas nouveau mais assez pénible pour certains mais sa librairie nous réconcilie avec cette tâche ! Il a poursuivi sa démo en utilisant cette librairie sur une application de réservation de billet de vol.
Avec l’outil "Accessibility inspector" sur Xcode, nous avions pu voir lorsqu'il modifiait la taille de l’écran que les layouts se réajustaient dynamiquement ainsi que les tailles des caractères et les images qui gravitaient au-dessus ou en-dessous des UITextView. Il faut le dire, nous avons été surpris par la puissance de sa librairie et avons hâte de la tester sur nos projets.
Mais à la fin de son talk il souligne que sa librairie n’est pas encore assez mature pour être utilisée dès à présent mais il prévoit de la rendre public prochainement.
Il a conseillé aux développeurs de continuer d'utiliser AutoLayout.
Virtuo est une application de location de voitures de luxe. Mathieu Hausherr nous explique que le constat des éventuels dégâts du véhicule est l’une des étapes importantes dans leur processus. Actuellement, les usagers prennent en photo les dommages constatés sur le véhicule et précisent manuellement la partie concernée, portes, roues avant etc. Il nous présente, comment à l'aide du machine learning, ils ont pu facilité cette étape.
En utilisant leur base de photos, Il nous explique qu’il est à la portée des développeurs mobile de construire leur modèle de classification. En effet les nouveaux outils tels que CreateML d’Apple sont faciles à prendre en main. Malgré les limites du modèle de classification, le machine learning améliore grandement l'expérience utilisateur en faisant des suggestions de la partie du véhicule concernée lorsqu'une photo est prise.
Enfin il nous rappelle que, dans leur cas, le machine learning est utilisé afin d’aider les utilisateurs dans leur saisie et non d’en faire une liste de choix exclusif. Il est donc important de laisser le choix aux utilisateurs de valider par eux même les propositions : les résultats ne peuvent pas aujourd'hui être considérés comme une vérité absolue.
Pour cette 3eme édition de la FrenchKit, nous avions été agréablement surpris de voir la qualité des speakers venant de loin pour partager leurs savoir-faires, leurs expériences et leur passion. Même si nous aurions aimé avoir plus de talks autour des nouveautés de la WWDC 2018.
Nous pensons qu’il est important de garder à l’esprit que Swift est un langage jeune avec une communauté de plus en plus grandissante qui n’hésite pas à contribuer à ces nouveautés car il est avant tout un projet open-source.
Chose assez nouvelle pour se le dire chez les développeurs iOS, comme nous, habitués à la fermeté d’Apple sur ses outils et API assez restreintes. Mais comme le soulignait Max Howell, “le plus important de l’open source est la communauté car elle fait vivre le produit”.
Apple s'intéresse de très près à ce qui se fait en France et n’hésite pas à collaborer avec des entreprises françaises dans le plus grand secret pour améliorer son produit phare l’iPhone qui est un beau clin d’oeil à la FrenchTech.
Jordhan - Développeur Mobile
Kevin - Développeur Mobile
Réda - Développeur Mobile