Swift vs. Objective-C : le comparatif des langages natifs iOS

Pierre Harington

Plusieurs étapes primordiales sont nécessaires à la réussite d’un projet de développement d’application mobile. Parmi elles figure le choix du langage adapté.

Nous allons vous parler dans cet article de deux langages, ceux utilisés pour le développement mobile natif sous iOS : Objective-C et Swift. Voici notre comparatif.

 

Présentation des deux langages natifs iOS

Comment a été créé Objective-C ? 

Objective-C a vu le jour dans les années 80. Le langage développé par l’Américain Brad Cox s’est inspiré d’un autre langage orienté objet des années 70 : Smalltalk. NeXT, la société créée par Steve Jobs, après son départ d’Apple, est la première entreprise à faire confiance à Objective-C dans ses projets. Il racheta le langage huit ans après sa création. C’est d’ailleurs NeXT qui permit à Steve Jobs de se retrouver à nouveau à la tête d’Apple. L’entreprise américaine développa ensuite l’OS de ses Macintosh (Mac OS X) sur la base de NeXTStep, le système d’exploitation de NeXT.

Objective-C c’est du C avec de nombreuses fonctionnalités, dont la programmation orientée objet (POO). Tout comme C++ développé en 1979 par Bjarne Stroustrup. Le langage de Brad Cox hérite donc de la syntaxe de son aîné, C. Étant une stricte surcouche de ce dernier, tout code écrit dans ce même langage peut donc être compilé par le compilateur d’Objective-C. 

 

Comment a été créé Swift ?

Prédestiné à être un concurrent sérieux à Objective-C, Swift a été présenté pour la première fois lors de la conférence d’ouverture de la Apple WWDC 2014 (Worldwide Developers Conference). La « nouvelle chose brillante » de Chris Lattner, son créateur, est le nouveau langage dévolu au développement d’application native sur iOS. Il devait au premier abord, littéralement s’appeler Shiny. Son développement débuta en 2010 après la WWDC. La nouvelle version de Clang, le compilateur d’Apple, venait d’être présentée aux développeurs. Pour se sortir la tête de cette mise à jour usante, Lattner s’était lancé dans ce projet personnel. Il va quatre ans plus tard aboutir à Swift. 

Les langages C, C++ et donc Objective-C ne disposaient pas de protection pour la mémoire. Les développeurs devaient par conséquent se charger de régler cet état de choses au moment de lire ou envoyer des données en écriture. Il n’était donc pas rare de voir une instabilité dans les applications ou une fuite de mémoire en cas d’une erreur dans le code. Des échanges entre Christ Lattner et Bertrand Serlet vont aboutir à la création d’ARC. Cette fonction du compilateur vérifie le bon usage de la mémoire dans le code, mais elle reste toujours à base du langage C. En avril 2011, Apple mit enfin sur pied une équipe pour le développement de son nouveau langage. La supervision du développement est alors confiée à Ted Kremenek. Plusieurs lignes de code et une documentation réalisée au fur et mesure du développement, plus tard pour faire naître Swift. 

  

Objective-C vs. Swift : quel langage choisir pour sa syntaxe ?

Objective-C : adepte de la « prose »

Objective-C a ajouté des concepts et des mots-clefs au langage C. Pour éviter les conflits, il faut les précéder du caractère : "@". C’est par exemple le cas de @interface, @catch, @try ou bien d’autres. Le langage de Lattner utilise par ailleurs deux fichiers. Le premier : ".h" est consacré aux headers pour la déclaration des include, les méthodes ainsi que les propriétés tandis que le second : ".m" réunit les fichiers d’implémentation. Ces tâches répétitives que représentent la création de ces fichiers donnent du travail supplémentaire et distrait à bien des égards les développeurs d’applications natives sous iOS. 

 

Swift : un langage qui va vite à l’essentiel

N’étant pas développé à base de C, Swift n’hérite pas de conventions de ce langage. Vous n’aurez non seulement pas besoin de mettre ces innombrables "@" devant les mots-clés, mais en plus, adieu les parenthèses des expressions conditionnelles dans les "if". Avec Swift, plus besoin des nombreux points-virgules pour marquer la fin des lignes de code. Vous avez donc une syntaxe simplifiée et un code qui utilise les standards de l’industrie pour son écriture. Les développeurs qui utilisent les langages comme Python, C++ ou JavaScript ne seront pas du tout dépaysés.

Le compilateur LLVM de Swift ainsi que Xcode aident en outre à déterminer les dépendances et à faire des constructions incrémentielles de façon automatique. Plus besoin donc de deux fichiers ".h" et ".m" comme c’était le cas avec Objective-C. ils sont combinés dans le seul : ".swift".

 

Objective-C vs. Swift : quel langage est le plus sécurisé ?

Objective-C et la gestion du NOP

En développement avec Objective-C, la gestion de la mémoire avec ARC est prise en charge dans le code orienté objet et l’API Cocoa. Mais lorsque vous utilisez par exemple CoreGraphics, du code C procédural ou les API bas niveau d’iOS, vous devrez gérer vous-même la mémoire. Le risque de fuite de cette dernière reste donc assez élevé. 

Quand vous développez par ailleurs une application native iOS avec Objective-C, une non-opération (NOP) due à un appel de méthode avec une variable de pointeur nul ne plante pas, mais elle peut causer un comportement imprévisible du code. Cet état de choses ne facilite pas la tâche aux développeurs au moment de trouver un crash aléatoire par exemple.

 

Swift et les pointeurs

Dans le langage Swift, ARC fonctionne autant avec un code orienté objet que procédural. Lorsque vous solliciterez des API de niveau inférieur dans votre code, vous n’aurez donc plus besoin de commutateurs de contexte mentaux. La gestion de la mémoire, l’une des causes de la création de Swift, est en effet plus efficace. Le langage Swift n’utilise en plus pas de pointeurs. S’il arrivait donc au développeur d’application mobile iOS d’omettre un pointeur dans son code, cette dernière avait un crash. Une approche qui permet de trouver rapidement les bugs et de les résoudre pendant l’écriture du code. 

 

Objective-C vs. Swift : Support des librairies dynamiques 

Objective-C et ses librairies statiques

Objective-C prend en compte uniquement les bibliothèques statiques. Par ailleurs, les bibliothèques dynamiques sont plus petites. Une copie peut par exemple être stockée dans la mémoire. Les librairies statiques se mettent en plus à jour au moment de la sortie d’une nouvelle grosse mise à jour comme la sortie d’une nouvelle version d’iOS par exemple. Choisir Objective-C pour le développement d’une application native iOS c’est donc se faire à l’idée d’utiliser des bibliothèques statiques.

 

Swift et les bibliothèques dynamiques

Swift supporte les librairies dynamiques contrairement à son ainé créé au début des années 1980. Elles optimisent la performance des applications, car elles se chargent directement dans sa mémoire. La mise à jour des bibliothèques dynamiques se fait indépendamment du système d’exploitation. Une solution pour réduire la taille et améliorer le temps de chargement de votre App iOS. Il faut toutefois noter que c’est l’avènement de Swift et iOS8 qui ont permis à iOS de prendre en charge les bibliothèques dynamiques pour la première fois.

 

Objective-C vs. Swift : Comparaison des communautés

La communauté reste un élément fondamental dans la survie d’un langage. 

 

La communauté d’Objective-C

La maturité du langage Objective-C en fait un langage encore populaire. Ayant été le seul langage de développement d’application native sous l’OS d’Apple, il compte dans ses rangs de nombreux experts qui lui restent encore fidèles. Ces derniers ne trouvent en effet aucun intérêt à apprendre un nouveau langage.

 

La communauté de Swift

La communauté de Swift a augmenté en flèche depuis qu’il est devenu open source. Cela permet à Apple de fixer plusieurs bugs grâce aux contributeurs. Le nouveau langage natif sous iOS a par ailleurs la faveur des nouveaux programmeurs.

 

Objective-C vs. Swift : quel langage choisir ?

Pour un nouveau projet "from-scratch"

Nous vous conseillons d'utiliser Swift. Ce langage nécessitera moins de lignes de code puisqu'il est moins verbeux, cela signifie aussi moins de bugs potentiels. Votre équipe de développement gagnera en productivité par rapport à Objective-C qui sera beaucoup plus chronophage.

Vos développeurs prendront plus de plaisir à travailler sur ce langage qui est plus clair et plus agréable à maintenir. C'est aussi un langage plus facile à apprendre, vous aurez donc plus de facilité à faire grandir votre équipe de développement iOS.

 

Pour un projet déjà existant

Cela dépend :

  • Si le projet est basé en Swift, nous vous conseillons vivement de le maintenir.
  • Si le projet est en Objective-C et que votre application n'a pas nécessairement vocation à évoluer, nous vous conseillons de le maintenir en Objective-C car la cohabitation des deux langages génèrera une complexité additionnelle.
  • Si votre projet est en Objective-C et que vous avez l'ambition de faire évoluer votre application, passer à Swift est une option qui mérite d'être étudiée. Par exemple Apple est en train de passer ses applications en Swift à l'image de Apple Music ou Apple Home.

  

Validation de l'envoi
MERCI, VOTRE DEMANDE À BIEN ÉTÉ ENVOYÉE.
Nous venons de vous envoyer le modèle de cahier des charges par e-mail.
Le formulaire n'a pas pu s'envoyer, veuillez essayer à nouveau

Validation de l'envoi
MERCI, VOTRE DEMANDE À BIEN ÉTÉ ENVOYÉE.
Nous venons de vous envoyer le modèle de cahier des charges par e-mail.
Le formulaire n'a pas pu s'envoyer, veuillez essayer à nouveau

Validation de l'envoi
MERCI, VOTRE DEMANDE À BIEN ÉTÉ ENVOYÉE.
Nous venons de vous envoyer le modèle de cahier des charges par e-mail.
Le formulaire n'a pas pu s'envoyer, veuillez essayer à nouveau
fleche gauche contenu precedentfleche droite contenu suivant

NOS DERNIERS ARTICLES