Bonnes pratiques, iOS – Un résumé des bonnes pratiques pour le développement d’application mobile sous iOS

by Posted on

Il est essentiel de thésauriser l’expérience acquise lors d’un développement, de consigner l’expérience des essais-erreurs commises au cours du cycle de création d’une application par exemple. Evidemment, cet impératif est intégré dans la méthode agile sous la forme d’un rituel nommé “Rétrospective d’itération”. Ce dernier a pour fonction d’exprimer un retour sur l’itération qui a eu lieu en pointant toutes les erreurs/difficultés auxquelles l’équipe a pu être confrontée.
Pointer les erreurs est une chose, isoler les solutions en est une autre… Et que dire d’une synthèse digeste rapprochant les deux points de vue. A première vue indispensable mais rarement produite. C’est pourtant l’objet même ce billet : existe-t-il un corpus de bonnes pratiques sur le développement mobile tant sous iOS que sous Android pour les mois présents et à venir ?

Eh, bien disons qu’un tel document existe, c’est une chose assez rare mais pas introuvable. Une recherche rapide sur le web permet de découvrir un certain nombre de documents nous en avons sélectionner deux qui donnent une liste de bonnes pratiques tant pour Android que pour iOS.

En voici les sources en anglais et ces recommandations sont prescrites par une entreprise qui fait disons plutôt autorité en matière de développement : Futurice http://futurice.com/.

Notre petite touche personnel pour iOS comme pour Android

Grosso modo, le seul élément manquant dans la liste des bonnes pratiques est l’utilisation de cette outil indispensable pour la livraison en continu dans les deux environnements : iOS et Android.
L’outil se marrie en effet sans problème avec CocoaPods et Gradle.

Source : https://fastlane.tools/

On se contentera dans un premier temps d’énumérer les bonnes pratiques concernant iOS. Celles concernant Android feront l’objet d’un autre billet.

Les bonnes pratiques sous iOS selon futurice

Le texte est rédigé comme un quasi manifesto, pas de gras juste des injonctions courtes et justifiées sur les meilleures choses à faire pour assurer un peu de pérennité au code d’un application iOS et de sérénité au PO comme au chef de projet ! Je vous invite à lire le tout en détail et à vous en imprégner au point d’en faire un mantra. J’ai sélectionné ici les meilleurs points ne privilégiant les aspects les moins techniques disons-le.

1. Utiliser git et le fichier .gitignore
Pour chaque projet iOS, déposé sur git, qu’il soit Swift ou en Objective-C, le mieux est de placer en racine un fichier .gitignore afin d’éviter d’intégrer des données inutiles ou sensibles (paramètres utilisateurs, fichiers temporaires etc.)

2. La gestion de dépendances
La gestion des libraires tierces peut vite tourner au casse-tête et cela peut potentiellement hypothéquer vos chances de publication sur l’apple store. Il est donc impératif de gérer précautionneusement ces dépendances à l’aide notamment de CocoaPods, facile à intégrer et grandement utile.

3. Structure du Project
Vu le nombre de fichiers qui ne manqueront d’être crées, il est fortement conseillé d’adopter une structure de projets en fonction de votre architecture.

	├─ Models
	├─ Views
	├─ Controllers (or ViewModels, if your architecture is MVVM)
	├─ Stores
	├─ Helpers

4. Localization ou traduction
Lorsque vous concevez une application multilingue, il est impératif de consigner toutes les chaines à traduire dans un fichier de localisation. Il est alors facile de retrouver les chaines si elles doivent être corrigées et de compiler ensuite l’application dans une langue ou dans une autre en passant l’argument de la langue.

-AppleLanguages (Spanish)

Pour des traductions plus complexes notamment la gestion du pluriel, il vaut mieux utiliser le format .stringsdict que le fichier localizable.strings

Source : https://speakerdeck.com/hasseg/localization-practicum

5. Constants ou variables globales
Il est souhaitable de limiter au maximum la portée des variables globales ou Constants de vos applications. Si certaines de ces constantes sont malgré tout utilisées à travers de toute l’application, il est là aussi préférable de les conserver au même endroit dans le code.

6. Version en branche
Bien sûr, on ne dira jamais assez l’importance de gérer des versions de l’application via des branches sur Git afin d’isoler les évolutions dans des branches séparées.

7. Prérequis sur la version minimale de iOS
Il est important de définir préalablement la version minimale sur laquelle votre application doit tourner. C’est un élément essentiel pour estimer la charge de travail nécessaire à la conception de votre application et des fonctionnalités possibles ou non.

Il existe un certain nombre de ressources pour sélectionner la version minimale de iOS souhaitée en fonction des usages que vous allez cibler
Use these resources to gather the data necessary for making this choice:

Une ressource officielle :

Des ressources tierces mais riches d’enseignements :

8. Librairies usuelles

Utiliser une librairie en vue d’ajouter une fonction est à double tranchant. En effet, même si cette librairie résout le problème dans l’immédiat, l’ajout d’une librairie additionnelle peut se révéler problématique en terme de maintenance ou lors du passage à une version supérieure de iOS. Il est aussi tout à fait possible que la fonctionnalité souhaitée, rendue possible par la librairie, deviennent une fonctionnalité du code officiel d’Apple.

Toujours penser à résoudre le problème en utilisant en priorité le framework natif d’Apple.

Voici une liste des librairies dont l’objectif est de réduire le code redondant ou de permettre la résolution de problèmes complexes et récurrents la calcul de la date par exemple. Bien sur plus la maitrise du code natif Apple est grande moins le recours à des librairies additionnelles est sans doute nécessaires.

En tous les cas, voici la liste des librairies les plus usuelles.

8.1. AFNetworking
La gestion du “Multithreading and Queues” voilà ce à quoi sert cette librairie. A n’en pas douter, c’est la base de toutes les applications modernes et “api-centric”.

Source : https://github.com/AFNetworking/AFNetworking

8.2. La librairie DateTools
Pas la peine de réinventer la roue, il existe fort heureusement une librairie qui couvre tous les besoins de choix dans la date.

Source : https://github.com/MatthewYork/DateTools

8.3. Auto Layout Libraries
Si vous souhaitez coder vos vues directement, il y a de fortes probabilités que vous soyez confronter à la syntaxe complexe propre à Apple – le corpus traditionnel du NSLayoutConstraint ou tout ce que comprend le language “Visual Format” qui définit les contraintes, les dimensions et l’espacement standard… etc.
Source : Visual Format Language

Fort heureusement, la version disponible pour iOS 9 donne des spécifications plus concises en matière de contraintes, la class NSLayoutAnchor.
Source : NSLayoutAnchor

Si vous êtes bloqué sur une version d’iOS ancienne, ne disposant que du traditionnel NSLayoutConstraint, voici la librairie Masonry/SnapKit peut-être une solution pour parer aux principaux défauts de NSLayoutConstraint.

Source: Masonry/SnapKit

Pour le Swift, Il existe aussi Cartography, qui fournit un complément puissant au langage natif. Pour les développeurs plus conservateurs, FLKAutoLayout offre un wrapper complémentaire à l’API natif de Apple, sobre et efficace mais pas magique pour autant !

Voici les premiers points essentiels de ce recueil des bonnes pratiques gracieusement fournies par Futurice. On vous invite vivement à prolonger la lecture de ce document sur si vous souhaitez acquérir une expertise de Lead Dev en iOS ! Les points sont nombreux et plutôt précis : Architecture, gestion des Assets, des recommandations de de présentation de code (Coding Style)… bref une vue d’ensemble.

Un dernier point : les Crash Logs


C’est un élément essentiel pour oeuvrer à l’amélioration de votre application, une sorte “feedback loop” automatisée. Le principe en est simple, tous les crash de vos applications qui surviennent sont consignés sur un serveur dans des fichiers de log auxquels vous avez bien évidemment accès. Il est possible d’implémenter manuellement ce type de fonctionnalité en utilisant par exemple PLCrashReporter et de l’interfacer avec votre propre “backend” mais il existe des solutions clés-en-main type Crashlytics ou HockeyApp, payante certes mais bien plus confortables.

Nous y ajoutons un sur la liste nommé KSCrash qui gagne à être connu. Il existe aussi des solutions pour analyser ces logs. A première vue, un outil comme GoAccess https://goaccess.io/ ou comme The Log File Navigator http://lnav.org/features/ pourrait faire l’affaire ou un outil comme le Log Parser 2.2 de microsoft.

Une fois que vous avez sélectionné et implémenté l’outil de crashlog, il y a s’assurer que vous faites une sauvegarde de l’archive Xcode (.xcarchive) de chaque build que vous publiez. L’archive contient le binaire de l’application et le symbole du débogage (dSYM) qui vous sera nécessaire pour avoir les rapports de crash pour chaque version en particulier.

En conclusion : les recommandations c’est bien ! Encore faut-il qu’elles soient partagées par tous, éventuellement discutées mais jamais imposées ! On a délibérément passé sous silence les recommandations en matière d’éditeur ou de coding style, de nomenclature des variables… On espère souvent, parfois à tort, que l’équipe de développement est déjà dépositaire des bonnes pratiques. Sans être chien avec les dévs, c’est souvent là qu’est l’os, rat que je suis !

En savoir plus

Published by Bruno Flaven

Bruno Flaven has been a Project Manager in a wide variety of Internet business applications both in Mobile and in Desktop for 20 years now. You can find more information about his professional life on his personal website (www.flaven.fr) or his linkedin profile: https://fr.linkedin.com/in/brunoflaven. He is currently working In France Media Monde (FMM) mostly on mobile applications (iOS and Android). He is currently P.O for a Backoffice project made with Symfony. He also made few trainings to facilitate the handling of the tools that he helps to make.

Related Posts