Pourquoi il faut tuer les storyboards sur Xcode

Vous êtes installé-e à votre bureau, des étoiles dans les yeux, prêt-e à amorcer votre nouveau projet : une belle app iOS (native of course). Le template apparait, Xcode a déjà créé quelques classes (que j’espère en Swift) et deux fichiers storyboard : l’un pour votre futur splashscreen-de-la-mort-qui-tue, et le deuxième pour votre application.

Votre workflow de navigation en tête, vous vous apprêtez à drag and dropper votre premier view controller… STOP !

Chez Videdressing, ne nous le cachons pas, le storyboarding est partout.

Pour ma part, les storyboards n’offrent qu’un seul avantage : pouvoir mocker facilement et rapidement l’interface d’une petite application. Dès que votre app devient un peu plus complexe et / ou que d’autres développeurs se joignent à votre team, les storyboards ne servent qu’à vous mettre des bâtons dans les roues.

Les onze commandements des storyboards (dont on se serait bien passé)

1. La lenteur incarnée tu seras

Je possède un MacBook Pro 2016 15" (touch bar et tout le tralala), et pourtant, ouvrir un des nombreux storyboards du projet est véritablement pain in the ass. Plusieurs secondes avec parfois quelques crashs (de Xcode ou du Mac, selon mon mojo). Fâcheux.

Même combat lorsque vous choisissez de changer le rendu d’écran (aka iPhone 8 vs iPhone X par exemple), ou pour drag and drop un élément sur une de vos interfaces.

“Que nenni ! Tu as mal découpé tes storyboards et tu as trop d’écrans !”, me direz-vous.

Oui mais non.

Un storyboard doit représenter une logique métier et de navigation. Par exemple, tout ce qui concerne le catalogue (liste de produits / filtre / fiche produit… en tout 10 écrans) doit être groupé. Cette logique ne doit pas reposer sur la capacité d’Xcode d’exécuter ce qu’on lui demande en un temps incroyablement lent.

Sans oublier qu’à chaque modification de l’interface, la compilation du projet prend un temps fou…

2. Les évolutions, difficilement tu exécuteras

Formidable : tous les storyboards sont créés avec tous vos écrans, tout est bien leché, tout part en prod’ et le monde est beau. Vous êtes beau / belle.

Un mois plus tard, votre P.O. crée un ticket. Son titre : [App] Quick Win: Change font size. Le monde s’écroule. Le vôtre surtout.

Il ne vous est pas possible d’appliquer simplement une feuille de style.

Un changement global et c’en est fini de vous. Obligé-e de faire une passe complète sur l’ensemble de vos composants.

3. Les logiques tu sépareras et la rigueur tu oublieras

Avec les XIB / Storyboard, vous devez créer dans vos classes des propriétés dites IBOutlet. Elles seront le lien entre votre interface et votre code.

À partir de là, vous pouvez penser : “Ok, je design le squelette de mon application sur mon storyboard et j’applique le style directement dans mon implémentation de classe”.

C’est une idée qui ne semble pas farfelue, mais qui demande à long-terme une grande rigueur. Admettons-le : sur le papier, tout le monde sera partant pour s’y tenir, mais 2 semaines plus tard, plus personne n’y pensera.

4. La localisation, même pas en rêve, tu y penseras

La traduction des interfaces fait aussi partie intégrante de l’usage des storyboards. Chacun d’entre eux peut générer ses propres feuilles de traduction. Dans un souci de maintenance, séparer vos fichiers n’est pas une bonne idée : mieux vaut avoir un seul fichier par langue plutôt qu’une multitude éparpillés.

De toute façon, vous serez obligé-e de changer vos labels directement dans vos classes, en fonction des contextes applicatifs que votre utilisateur provoquera.

5. Les conflits tu résoudras

Ce qui se cache derrière vos storyboards est simplement un gros XML des familles, tout moche, pas du tout human readable (le contraire de ce qui est fait pour Android), et qui casse dès que vous voulez merger votre branche sur une autre. À chaque fois que vous ouvrez un storyboard, Xcode change des paramètres du XML généré. Sans parler du changement de rendu ou du déplacement de vue …

Si, par malheur, l’un de vos teammates travaille sur un des écrans du même storyboard, vous pouvez déjà vous préparer à une bonne matinée de résolution de conflits à vous rendre dingue.

6. Avec la navigation, perdu-e tu seras

L’ambition des storyboards par rapport aux purs XIB (qui ne sont là que pour prototyper une seule vue) est d’inclure tout le workflow de navigation, et montrer simplement l’enchainement des différents écrans.

C’est tout.

Sexy sur le papier, ce principe est figé sur le storyboard. L’identification de vos écrans passe par un string devant être présent dans votre storyboard et dans votre code. Si cet identifiant change, vous devrez penser à l’updater dans votre code (espérons que vous l’ayez déclaré comme constante quelque part).

Ok mais tu proposes quoi ?

La bonne vieille méthode : coder l’interface soi-même.

Chez Videdressing, nous avons mis en place une politique de changement assez progressive.

1. Le legacy ou le syndrome de Stockholm

Nous avons décidé de pas toucher au legacy. Nous passerions beaucoup trop de temps à tout refactoriser tout en prenant le risque de produire des regressions.

2. Un nouvel espoir

A contrario, dès qu’un nouvel écran est introduit, nous le créons uniquement en code. Les résultats sont éloquents :

• Nos temps de build sont plus rapides
• Les conflits au versioning sont plus facilement résolvables
• Nos logiques de customisation et de navigation ne sont plus éparpillées
• Nous pouvons profiter de la puissance de la généricité en Swift et avoir nos propres constructeurs

• Nous instancions nos éléments d’interface en profitant des lazy properties. Au lieu d’avoir un énorme bloc d’instanciation et de customisation des éléments, ici chaque variable est responsable de sa propre construction.

L’aspect assez lourd de la verbosité d’UIKit pour la construction de contraintes nous a un peu rebuté-e-s. Le code peut vite devenir illisible. Nous avons donc dû choisir une librairie qui allège et simplifie cette construction. Notre choix s’est porté sur SnapKit, assez en vogue en ce moment.

Le mot de la fin

Vous l’aurez compris : chez Videdressing, nous essayons de nous séparer de cette feature introduite en grande pompe par Apple en 2013. Un au revoir, mais pas un adieu. Nous espérons voir la firme de Cupertino écouter les développeurs pour pallier tous ces problèmes.

N’hésitez pas à nous faire part de vos remarques / retours !