Quelles dépendances pour une application ?

Des dépendances, pourquoi faire ?

Aujourd’hui, le développement d’une application nécessite des dépendances (librairies) mise à disposition par Apple et Google.
Cependant, il arrive souvent qu’il manque des fonctionnalités comme le chargement d’image asynchrone ou encore des processus pouvant être amélioré et simplifié comme les appels réseaux.

Afin d’éviter de réinventer la roue, les développeurs se tournent vers des librairies portées par la communauté qui répondent au besoin. Par exemple, nous utilisons Kingfisher qui permet de charger de manière asynchrone des images provenant d’un serveur.

Il peut être tentant d’ajouter une librairie pour tout et n’importe quoi afin d’accélérer le développement.
Cependant, il y a plusieurs points à prendre en compte :

• Est-ce qu’elle répond à 100% à notre besoin ? Le cas échéant, peut elle être modifiée facilement ?
• Est-elle utilisée par beaucoup de développeur ?
• Est-elle mise à jour en tenant compte des bugs remontés et des nouveautés d’Apple et Google ?

A-t-on vraiment besoin de toutes ces dépendances ?

Nos premières applications utilisaient intensivement des dépendances en prenant en compte les points cités plus hauts. Puis, lorsqu’il fallait migrer nos applications vers les nouvelles versions d’OS, nous avions rencontré plusieurs problèmes.

Librairies clonées

Il arrive qu’une librairie ne correspondent pas à 100% de nos besoins. Dans ce cas-là, on clone le repository et nous apportons les modifications pour répondre au besoin. En faisant ainsi, on se retrouve avec un décalage entre la librairie originale et notre version. Il faudrait régulièrement rapatrier le code puis appliquer de nos nouveaux nos modifications et ainsi de suite. Il arrive aussi que les auteurs revoient complètement l’architecture de leurs librairies et le travail de modification devient trop complexe et couteux.
En résumé, il fallait d’abord migrer les librairies avant chaque migration de notre code.

Librairies non mises à jour

Comme évoqué dans l’article précédent, il y a une nouvelle version des outils et du langage chaque année. Cela implique que les développeurs doivent également mettre à jour leurs librairies pour être compatible avec ces nouveautés. Si une librairie n’a pas beaucoup d’utilisateur ou qu’elle n’est pas vraiment maintenue alors c’est un indicateur pour ne pas l’utiliser.
Si toutefois, elle a été intégrée au projet, deux choix sont possibles :

• Cloner la librairie et migrer la librairie nous-même
• Trouver une librairie similaire

En résumé

A chaque début de nouveau projet, on se pose la question de savoir si une librairie est vraiment nécessaire. En supprimant les librairies qu’on avait l’habitude d’utiliser, on gagne sur le temps de développement ainsi que sur le poids des applications.
Évidemment, certaines librairies ne peuvent être remplacées comme par exemple Firebase. D’autres nous font gagner du temps sur développement comme Kingfisher sur iOS. Par contre, les librairies qui font des appels API pourraient être remplacées.

Qu’en est il sur iOS ?

Nous utilisons depuis le début Cocoapods comme gestionnaire de dépendances. Cependant, c’est un outil externe et n’est pas vraiment intégré à Xcode. Apple, de son côté, a sortie Swift Package Manager en 2016 et s’intègre parfaitement dans leur outil. Beaucoup de librairies sont désormais disponibles sur Swift Package Manager. Nous allons essayer de passer de Cocoapods vers SPM.
De plus, les librairies des appels API (Moya, Alamofire, etc.) pourraient être remplacées par les URLSession d’Apple.