SwiftUI Series 01｜Les limites applicables de SwiftUI

Lorsque je suis entré en contact avec SwiftUI pour la première fois, les questions les plus fréquemment posées étaient :

• Peut-il remplacer UIKit ?
• Tous les nouveaux projets devraient-ils utiliser SwiftUI ?
• L’ancien projet vaut-il la peine d’être déplacé ?

Ces questions sont bien sûr importantes, mais si la discussion se concentre dès le départ sur le « remplacement », le jugement sera souvent porté à l’extrême. Une question plus pratique serait :

Quel type de complexité de page SwiftUI gère-t-il le mieux, et quels types de problèmes ne domine-t-il pas nécessairement ?

Ce n’est que si l’on répond d’abord clairement à cette question que les phrases suivantes « doit-il être utilisé » et « dans quelle mesure » auront-elles une signification pratique.

1. Le véritable pouvoir de SwiftUI est qu’il met en premier lieu « la façon dont les changements d’état sont mappés dans les interfaces »

L’idée par défaut d’UIKit ressemble plus à :

• voir en premier
• Allez mettre à jour à nouveau la vue
• Gérez ensuite la relation de synchronisation entre plusieurs composants de l’interface utilisateur

L’idée par défaut de SwiftUI est plus proche de :

• Statut préexistant
• Décrivez ensuite “à quoi doit ressembler l’interface dans cet état”

Cela signifie qu’il est naturellement plus adapté aux pages où « la principale complexité de l’interface vient de l’expression d’état ». Par exemple :

• Vide / chargement / chargé / erreur passe à la page évidente
• page de formulaire
• Page Paramètres
• Afficher la page de détails
• Une page où plusieurs widgets sont liés entre eux en fonction d’un ensemble de statuts commerciaux

Bien entendu, ces pages peuvent être écrites dans UIKit, mais de nombreuses relations de synchronisation doivent souvent être maintenues manuellement. L’avantage de SwiftUI est précisément qu’il facilite l’expression de telles relations dans leur ensemble.

2. Il est particulièrement adapté aux pages professionnelles où « le statut est plus important que les détails de l’interaction »

La vraie difficulté avec de nombreuses pages professionnelles est :

• Quelle est la situation actuelle ?
• Que faut-il afficher dans différents états
• Quels domaines doivent être modifiés ensemble après une certaine action commerciale ?

Par exemple :

• Centre personnel
• Page Paramètres
• Page de détails de l’article
• Page de résultats de recherche
• Page de détails de la commande

De telles pages nécessitent rarement des niveaux extrêmes de coordination du défilement ou de conception des gestes, mais elles impliquent beaucoup de :

• Changement d’état
• Affichage conditionnel
• Combinaison de composants
• Actualisation partielle

C’est dans ces domaines que SwiftUI s’avère le plus utile.

3. Il est également très adapté aux pages avec « des itérations rapides et des changements fréquents d’interface utilisateur »

C’est très important dans les vraies équipes.

Certaines pages ne comportent pas de changements de produits fréquents :

• Révision rédactionnelle
• Changements structurels
• Changer l’ordre des cartes
• Changer la condition d’affichage d’un certain module

Dans de tels scénarios, l’avantage de SwiftUI n’est souvent pas seulement « moins de code », mais aussi une charge mentale moindre liée à la modification de la structure de l’interface utilisateur. Il est plus facile de traiter la page comme une arborescence de structure pilotée par l’état à modifier, plutôt que d’effectuer des allers-retours entre de nombreuses vues partielles.

Alors si la réalité pour une équipe est que « les pages changent fréquemment », SwiftUI est souvent très attractif.

4. Mais SwiftUI n’est pas naturellement adapté à toutes les « pages complexes »

C’est aussi le point qu’il convient de clarifier le plus.

Une situation courante est que lorsque vous entendez « SwiftUI est plus moderne », vous l’assimilez inconsciemment à « toutes les pages sont plus adaptées ». Mais dans les projets réels, la complexité des pages complexes provient de différentes sources.

Si la difficulté principale d’une page est :

• Contrôle de défilement extrêmement fin
• Beaucoup de coordination gestuelle de bas niveau
• Timing d’animation très personnalisable
• Contrôle extrêmement exigeant sur les détails du rendu et des interactions

Alors SwiftUI n’est peut-être pas naturellement plus simple.

est :

• Certaines capacités doivent être contournées
• Parfois il faut mélanger UIKit
• Certains comportements sous-jacents sont plus coûteux à déboguer

Par conséquent, « la page est complexe » n’est pas un critère en soi, l’essentiel est de savoir où elle est complexe.

5. Un jugement plus pratique : la principale difficulté de la page est-elle « l’expression du statut » ou le « contrôle sous-jacent » ?

C’est ma méthode de jugement la plus courante.

Si la difficulté principale de la page est :

• Comment mapper plusieurs états métier à l’interface
• Comment combiner naturellement les composants à mesure que l’état change
• Comment garder la structure de la page claire

Alors SwiftUI convient souvent.

Si la difficulté principale de la page est :

• Comment contrôler avec précision les interactions sous-jacentes
• Comment coordonner un comportement de défilement complexe
• Comment implémenter des comportements d’animation et de mise en page non standard

Cet UIKit a tendance à être plus stable, ou du moins plus « contrôlable ».

Ce jugement n’est pas absolu, mais il est assez pratique dans des projets réels. Il peut mieux guider la sélection quotidienne que la question « SwiftUI peut-il remplacer UIKit ? »

6. La stratégie la plus réaliste dans les anciens projets est généralement de « mélanger selon les limites »

Si le projet dispose déjà d’une structure UIKit mature, le problème le plus probable est « une imagination de migration trop idéale ».

Dans les projets réels, le chemin le plus courant et le plus stable est généralement :

• Utilisez d’abord SwiftUI pour les nouvelles pages
• Les pages UIKit stables ne peuvent pas être facilement modifiées
• Mélangez-le si nécessaire
• Ne poursuivez pas une migration complète en une seule fois

Parce que les coûts de migration eux-mêmes sont des coûts pour l’entreprise. Si le changement de cadre n’apporte pas d’avantages clairs et vise uniquement à « unifier la pile », il est probable que le gain dépassera la perte.

7. Un malentendu courant : traiter SwiftUI comme “une version améliorée de la syntaxe d’UIKit”

Lorsque j’ai découvert ce morceau de SwiftUI pour la première fois, je me posais encore ces questions dans mon esprit :

• Cette vue est-elle créée une seule fois ?
• Quand dois-je actualiser manuellement ?
• Ce n’est pas comme UIKit où il suffit de le modifier directement.

Ces doutes sont normaux, mais si vous restez longtemps dans cette perspective, il sera difficile de vraiment bien utiliser SwiftUI. Parce que SwiftUI est une manière complètement différente d’organiser l’interface.

Cela nécessite de réfléchir en priorité à :

• Qui est responsable du statut ?
• Comment mapper cet état à l’interface utilisateur
• La mise à jour de l’interface fait-elle partie du flux d’état ?

Une fois que vous utilisez toujours la pensée d’UIKit, SwiftUI peut facilement finir par devenir “apparemment déclaratif, mais en réalité la logique est plus déroutante”.

8. Conclusion : Le fait que SwiftUI soit adapté ou non ne dépend pas du fait qu’il soit nouveau ou non, mais dépend de la source de complexité de la page.

Pour le dire sous une forme plus courte, je dirais :

SwiftUI est particulièrement adapté aux pages dont la complexité principale provient principalement de l’expression de l’état, de la combinaison d’interfaces et de la fréquence d’itération ; et pour les pages dont la complexité provient principalement d’une interaction sous-jacente et d’un contrôle précis, elle peut ne pas être naturellement dominante.

Le véritable jugement pratique est donc :

• Qu’est-ce qu’il y a de si compliqué dans cette page ?
• SwiftUI peut-il atteindre ce genre de complexité ?

Une fois que l’on répond clairement à cette question, la sélection n’est généralement pas trop déroutante.