Il y a 2 années · 5 minutes · Divers, Events, iOS, Mobile

Conférence DotSwift, nous y étions !

Vendredi 6 Février avait lieu la DotSwift, 1ère conférence d’envergure en Europe entièrement dédiée à Swift, le nouveau langage d’Apple. Ash Furrow, Daniel Steinberg, Marius Rackwitz et bien d’autres étaient les speakers du jour. Une affiche bien alléchante à laquelle l’équipe mobile Xebia n’a pas su résister… L’occasion pour nous de vous faire un petit retour sur cet évènement.

Cette première DotSwift avait lieu au Théâtre des Variétés à Paris, en face du célèbre musée Grévin. Au programme : 8 talks, 4 lightning talks et 2 pauses. Le tout en une seule après-midi. Un planning chargé donc mais rythmé grâce à aux différents sujets tout au long de la conférence, allant de la présentation du langage et de ses spécificités, à la mise en production d’une application iOS 100% Swift.

 

Débuter avec Swift

Pour bien démarrer une conférence Swift quoi de mieux que de présenter Swift et ses paradigmes ? Ceux-là même qui parfois nous effrayent rien qu’à leur évocation, comme les Optionals ! C’est justement ce que Dimitri Dupuis-Latour et Corinne Krych ont fait.

Dimitri tout d’abord nous a montré comment utiliser et comprendre les Optionals à travers différentes comparaisons : « To understand optionals, you first need to understand quantum mechanics« . Car les Optionals c’est un peu comme… le chat de Schrödinger, avec un état à la fois connu et inconnu ! Malin comme un chat ce Dimitri…

Corinne quant à elle nous expliquait comment l’équipe d’Aerogear a utilisé les « super powers » de Swift, ces fameux paradigmes, pour migrer petit à petit leur code pure Objective-C vers Swift au travers de plusieurs exemples tirés de leur code (open source) :

  • La surcharge d’opérateurs pour faire du mapping JSON <-> Objet
  • L’utilisation des Generics à la place d’id
  • Les computed properties, qui leur a permis d’encapsuler/de cacher l’utilisation du Keychain

Enchantée par les possibilités offertes par Swift, elle a conseillé à tout le monde d’y passer doucement et sûrement, notamment en mettant son code en Open Source pour avoir des retours de la part de la communauté.

Functional programming

S’il y a bien un paradigme qui revient souvent dans Swift, bien plus que dans Objective-C, c’est la programmation fonctionnelle. Si le sujet avait été légèrement abordé dans les présentations de Dimitri et Corrine, Kyle Fuller (très gros contributeur à CocoaPods) nous a expliqué de manière plus approfondie ce qu’était la programmation fonctionnelle.

Tout d’abord en répondant à une question vitale : qu’est-ce que la programmation fonctionnelle ? Puis en présentant de nombreux exemples au travers des Array et des méthodes map, sort, reduce, … Si le sujet était très intéressant, ce fut tout de même un peu dommage de ne se limiter qu’au seul cas des Array. La prochaine fois peut-être ? En attendant vous pouvez retrouver ses slides à cette adresse.

D’Objective-C à Swift

Beaucoup de développeurs iOS se posent encore cette question : faut-il passer à Swift ? Le travail demandé est-il titanesque ? Vais-je en faire des cauchemars toute la nuit ? Plusieurs intervenants ont abordé le sujet.

Romain Huet nous a parlé de Crashlytics (solution de crash reporting) et du support de Swift. Si développer en Swift au début de l’été signifiait faire une croix sur les rapports de crash, Romain nous a rassuré en nous expliquant que Crashlytics supporte totalement Swift depuis Septembre.  Pourtant d’après ses dires, ce fut un vrai challenge : ils ont dû faire face à des problématiques nouvelles par rapport à Objective-C pour lesquelles ils n’avaient aucune solution, notamment le demangling des noms. Heureusement Apple a sorti des outils qui les ont grandement aidés et après quelques mois de travail ils ont pu sortir une version de Crashlytics compatible avec Swift. On peut donc dorénavant passer d’Objective-C à Swift sans encombre, du moins du point de vue des rapports de crash.

JP Simard, développeur Cocoa pour Realm, s’est quant à lui attardé sur l’introspection en Swift. Car si cela s’avère très facile en Objective-C, force est de constater que cela s’avère plus compliqué en Swift : le langage ne permet que très peu de choses au runtime. Il nous a tout de même donné 5 manières différentes de tenter l’introspection en Swift, de la moins pire à la plus maléfique :

  1. Caster
  2. Utiliser l’API MirrorType de Swift, API publique mais non officielle
  3. Utiliser Objective-C en héritant de NSObject
  4. Utiliser des fonctions privées qui permettent, en autre, le demangling des noms de classe
  5. Inspecter la mémoire

On l’aura compris, l’introspection en Swift ce n’est pas encore pour maintenant et il faudra ruser pour s’en servir, si jamais cela s’avère vital. Car pour JP Simard, avoir accès au runtime est très important dans un langage et permet de faire des choses impossibles à la compilation.  Pour les slides de la présentation, rendez-vous ici.

Swift en production

Certains utilisent déjà Swift pour leurs applications. D’autres sont même allés jusqu’à sortir une application Production-Ready avec ! C’est Ash Furrow et son équipe de chez Artsy qui ont réussi cet « exploit ». Pourtant d’après Ash ce ne fut pas de tout repos :

  • Développer en Swift leur a pris 50% de temps de plus qu’en Objective-C
  • Ils ont dû se battre avec des outils immatures. C’est bien simple, ils étaient incapables de livrer sur l’AppStore avec Xcode 6.1 car le système de vérification était cassé…
  • Ils étaient à la limite du burn-out

Des points négatifs donc, mais Ash Furrow ne regrette pas cette expérience. Il estime juste qu’il faut être bien informé avant de se lancer dans cette aventure, ce qui n’était pas son cas. Il finit par lister quelques critères à prendre en compte pour décider de la faisabilité d’un projet en Swift :

  • L’immaturité des outils
  • La flexibilité sur la deadline de livraison
  • La motivation de l’équipe à apprendre un nouveau langage, une nouvelle manière de coder

Une petite check-list à garder à portée de main !

Conclusion

C’est tout pour cette dotSwift 2015. La prochaine est prévue dans un an. C’est long, alors en attendant vous pourrez regarder le planning des autres dotConferences prévues tout au long de l’année, la prochaine concernant la scalabilité, Devops, et les systèmes distribués. A bientôt !

 

Jean-Christophe Pastant
Consultant iOS, fervent défenseur du code de qualité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *