Skip, la revanche des développeurs iOS sur le cross-plateforme ?

Ces dernières années, de nombreuses technologies cross-plateformes ont émergé pour simplifier le développement et la maintenance des applications mobiles. Alors que des solutions populaires comme Flutter et React Native sont bien établies, d’autres alternatives commencent à se faire connaître, telles que Compose Multiplatform* développé par JetBrains et basé sur Kotlin. Si ce dernier fait parler de lui auprès de la communauté de développeurs Android, les développeurs iOS de leur côté ne peuvent être conquis, faute de framework permettant l’équivalence, à savoir passer d’un code Swift à Kotlin. Sans oublier que ce n’est pas dans l’esprit d’Apple de soutenir ce genre de technologie. 

La promesse de Skip, éditeur indépendant fraîchement entré sur le marché, pourrait-elle être la solution pour les adeptes de SwiftUI ? C’est ce que nos développeurs ont voulu vérifier en testant la v1.0 mise à disposition par l'éditeur le 14 août, après plus d'un an de test ! 

Moyennant un abonnement mensuel allant de 30$ à 100$, Skip permet de développer des applications mobiles depuis l’environnement iOS, en Swift avec SwiftUI, puis de convertir ce code en Kotlin, afin d’obtenir des applications natives, légères et performantes ! Avant de dégainer le portefeuille, place à la version gratuite et voyons si ses promesses en matière de gain de temps et d’efficacité justifient le coût de cette jeune solution.

Des promesses compétitives :

Décryptage du fonctionnement de Skip

Les premières étapes consistent à générer une clé qui servira à créer le projet et à lier votre compte Skip au framework de développement. Ce processus est simple, efficace et assez standard. La promesse de Skip repose sur la génération continue de code Kotlin en Jetpack Compose, et il faut reconnaître que cela fonctionne globalement bien. Skip effectue un mappage précis et transpile le code SwiftUI de manière correcte. Étant donné que Jetpack Compose et SwiftUI partagent des principes similaires en termes de réactivité et de conception d’interface utilisateur déclarative, cette approche est cohérente. C’est à partir du 5e argument du tableau comparatif présenté par Skip que les choses se gâtent (Platform-native widgets). Bien que le code généré soit généralement acceptable, lisible et exploitable, il présente beaucoup de lourdeurs, principalement dues à l’absence de certaines bibliothèques habituellement utilisées par les développeurs Android et l'interprétation de SwiftUI. 

Le code Compose généré par Skip, bien qu'utilisant les mécanismes de base de Compose, est fortement couplé à la bibliothèque SkipUI, limitant ainsi son indépendance et sa portabilité. Cette dépendance excessive entraîne un code moins lisible et moins réutilisable dans un projet Compose natif. En effet, Skip tente de reproduire des comportements spécifiques à Swift et SwiftUI, générant ainsi un code plus verbeux que nécessaire.

Sylvain Guéniot, Lead Développeur Android.

Test Hello World**

La première compilation se déroule sans encombre, il est nécessaire d’ouvrir le compilateur Android et aucun problème majeur n’a été rencontré à ce niveau. Un développeur iOS retrouvera rapidement ses repères et pourra développer ses interfaces. Cependant, nous observons rapidement des erreurs de compilation inexplicables, qui disparaissent parfois après un clean du code sans modification (la promesse de native IDE/Debugging n’est pas au rendez-vous). La principale faiblesse de Skip apparaît lorsque les résultats ne correspondent pas aux attentes, notamment avec l’ajout d’une simple liste au Hello World fournit : les résultats diffèrent entre iOS et Android. Des divergences d’affichage même pour quelques lignes de code nuisent considérablement à l’utilité de l’outil.

Nous poursuivons nos tests et continuons de constater certaines lacunes, notamment l’absence de bibliothèques essentielles. Pour remédier à ces manques, nous avons intégré SkipFoundation, une bibliothèque développée par Skip, qui offre des outils iOS convertis pour Android. Cependant, certaines fonctionnalités de base, telles que la gestion des dates et d’autres outils couramment utilisés, n’ont pas encore été implémentées, tout comme les outils de type SwiftData, etc. Ici encore, l’Effortless platform API access avancé par Skip ne convainc pas. Nous devons donc repenser notre approche de développement pour l’adapter à Skip. Bien que le code généré soit natif, les promesses de performance native ne sont pas toujours tenues en raison de l’absence de ces bibliothèques optimisées et développées pour booster iOS. Cette limitation restreint les possibilités et impacte l’efficacité globale du développement. 

Concernant la partie éjectable (dans le tableau comparatif) : Skip affirme qu’elle peut être facilement retirée, ce qui n’est pas tout à fait vrai pour le projet iOS, en raison des bibliothèques Foundation non gérées et de l’obligation d’utiliser les librairies Skip. Quant au code généré pour Android, cela est impossible, car toutes les vues dépendent de la bibliothèque SkipUI. La promesse n’est donc pas respectée.

Test de la Conversion d’un Projet Existant

Les problèmes précédemment évoqués rendent la conversion d’un projet existant difficile, voire impossible. Malgré plusieurs tentatives d’adaptation sur des petits projets entièrement natifs, nous avons rencontré des difficultés pour corriger l’intégralité des erreurs de compilation dont la plupart étaient incompréhensibles (second exemple témoignant des lacunes de Skip quant au  debugging). Nous avons rencontré des problèmes similaires à ceux rencontrés avec le code Hello World, où le code ne compile pas la première fois, puis compile la seconde fois sans modification. Ce problème doit être une priorité, surtout lors de la phase d’apprentissage du framework.

Conclusion

Malheureusement, Skip manque encore de maturité et les promesses faites ne sont pas entièrement tenues. Bien que le code généré soit natif, l’impossibilité d’utiliser certains composants natifs limite les performances, qui ne peuvent donc pas être comparées à celles d’applications développées directement pour chaque plateforme. Les erreurs de débogage demeurent trop récurrentes et le manque de bibliothèques disponibles rallonge considérablement le temps d’adaptation. Si la construction des composants manquants pour iOS et Android doit être réalisée en interne, les délais de développement peuvent exploser. 

Le fait que ce produit soit payant à ce stade réduit l’engagement de la communauté, qui pourrait autrement contribuer à la création d’une banque de bibliothèques. Cependant, le projet est encore jeune et la promesse de transcription de code reste un véritable atout par rapport à ses concurrents. Nous continuerons à suivre de près les prochaines versions pour évaluer les évolutions.

^{*Compose Multiplatform permet d’interfacer Kotlin Multi-platform.
**« Hello world » est le nom couramment utilisé pour désigner les applications ou programmes de démonstration.}