Pourquoi nous distribuons Swift, et non SwiftUI

Depuis 2019, chaque WWDC a poussé SwiftUI un peu plus loin, et chaque fois que nous lançons une nouvelle application, nous nous réunissons en équipe pour nous poser la même question : Est-ce qu'elle a déjà trouvé sa place dans nos applications ? Jusqu’à présent, la réponse a été « non » pour les aspects qui comptent — et probablement « oui » pour ceux qui n’ont pas d’importance.

Il ne s'agit pas ici d'un jugement sur SwiftUI en général. De nombreuses équipes développent d'excellentes applications grâce à cet outil. Il s'agit simplement de décrire dans quel contexte il nous convient : un petit studio qui gère simultanément plusieurs applications iPhone et iPad, sans pouvoir se permettre la moindre imprévu dans aucune d'entre elles.

Ce qui fonctionne

SwiftUI est vraiment idéal pour les écrans de paramètres statiques, les mises en page de formulaires et tout ce où l'arborescence des vues est réduite et où le flux de données est unidirectionnel. Nous l'utilisons. Nous l'utilisons également pour les aperçus pendant la conception : le cycle d'itération est plus rapide qu'avec UIKit.

Concrètement, cela signifie que l'écran sur lequel vous sélectionnez des éléments ou exportez vos données est souvent réalisé en SwiftUI, intégré à une application dont les écrans principaux sont en UIKit. Les deux coexistent sans trop de problèmes, et leur combinaison nous permet de tirer parti des points forts de chacun, plutôt que de consacrer l'intégralité d'une application à une seule approche.

Ce qui ne fonctionne pas (pour nous)

Dès qu’un écran nécessite des gestes personnalisés, des listes sensibles aux performances, un état de navigation complexe ou un timing d’animation précis, nous revenons à UIKit. Ce n’est pas par effet de mode : c’est à cause des bugs que nous rencontrons lorsque nous ne le faisons pas. SwiftUI s’est considérablement amélioré au fil de ses dernières versions, mais il nous réserve encore des surprises lors de l’exécution, ce qui arrive rarement avec UIKit.

Les exemples concrets sont utiles. Dans un logiciel d’apprentissage de la dactylographie, chaque frappe doit correspondre au bon caractère sans délai visible, et l’écran doit suivre le rythme des doigts de l’utilisateur. Un historique long d’entrées enregistrées dans un outil de suivi doit défiler en douceur sur un téléphone plus ancien. Un agenda avec fonctionnalité de glisser-déposer nécessite des gestes qui ne vont pas à l’encontre de ceux du système lui-même. C’est sur ce type d’interfaces que nous avons trouvé UIKit plus prévisible.

Les compromis

S'en tenir à UIKit a un coût. Cela implique davantage de code pour un même écran, et cela signifie que toute nouvelle recrue doit être à l'aise avec un framework plus ancien que les tutoriels ont de plus en plus tendance à ignorer. Certaines nouvelles fonctionnalités du système apparaissent d'abord dans SwiftUI, et leur adoption depuis UIKit nécessite un travail d'infrastructure supplémentaire. Il faut également reconnaître en toute honnêteté qu’une partie de notre prudence tient à la familiarité : une connaissance approfondie d’un framework a certes de la valeur, mais elle peut aussi devenir une excuse.

Une question reste également en suspens. Nos applications iPhone et iPad fonctionnent déjà sur les Mac équipés d’Apple Silicon, et nous prévoyons de développer des applications Mac natives. Si SwiftUI facilite considérablement le partage du code d’interface entre ces plateformes, la donne pourrait changer.

Nos erreurs

Nous avons déjà utilisé SwiftUI pour un écran qui semblait simple sur le papier, mais qui s'est avéré ne pas l'être : une liste avec des actions de balayage personnalisées et un état qui changeait au fur et à mesure du défilement. Elle fonctionnait bien dans les aperçus, mais de manière étrange sur les appareils réels. La refaire en UIKit nous a pris plus de temps que si nous avions commencé directement avec ce framework. Désormais, nous prenons cette décision au cas par cas, dès le départ, en fonction de ce que l'écran doit réellement faire.

C'est là le seul véritable test : Cela va-t-il nous surprendre lors de la production ? Pour la plupart de nos projets, cela exclut SwiftUI comme technologie principale. Nous y reviendrons l'année prochaine.