Le déploiement d'applications sur l'App Store

Si l'accès au SDK (Software Development Kit) d'Apple permettant de développer des applications iOS est gratuit (XCode et autres ressources techniques), publier sur l'App Store nécessite d'avoir un compte développeur payant en cours de validité. L'abonnement coûte 99 € par an. Il devra également être renouvelé chaque année sous peine de voir vos applications disparaitre de l'App Store.

XCode contient un simulateur permettant de tester votre application sans avoir besoin d'un iPhone ou iPad sous la main. Il est cependant utile d'avoir un appareil iOS (iPhone ou iPad) à disposition afin de tester en conditions réelles votre application.

Le simulateur, bien que dans la plupart des cas fidèle au rendu final, peut parfois laisser apparaitre quelques différences de comportement. De plus, l'exécution est généralement plus lente que sur un appareil physique.

D'un point de vue expérience utilisateur, le simulateur ne permet pas totalement de se rendre compte de l'ergonomie de son application. Quelque chose que l'on pense fonctionnel sur le simulateur peut en fait ne pas être agréable à utiliser une fois le téléphone en main.

Enfin, certaines fonctionnalités ne sont pas disponibles sur le simulateur (push notifications, accès à l'appareil photo, etc.). Dans ces cas l'utilisation d'un appareil réel sera nécessaire pour tester ces fonctionnalités.

Apple exerce un contrôle sur le contenu de son store. Certaines catégories d'applications sont interdites, tandis que d'autres sont soumises à des restrictions en termes de fonctionnalités. Toutes sont soumises à des règles plus ou moins contraignantes à respecter.

Afin de minimiser les risques de refus de la part d'Apple, et ainsi éviter de perdre du temps précieux une fois venu le moment crucial de la mise en production de son application, il est important de prendre en compte dès le début de la conception et du développement les directives d'Apple, que ce soit du point de vue technique comme du point de vue graphique et de l'interface utilisateur.

Pour se faire, Apple met à disposition un ensemble de bonnes pratiques appelées « guidelines ».

Les guidelines permettent une homogénéisation des éléments graphiques entre toutes les applications, une cohérence en termes d'expérience utilisateur, ainsi que, dans le cadre de l'App Store, de fiches standardisées dont le contenu sera uniforme.

Le but est d'offrir à l'utilisateur des habitudes de lecture afin de retrouver aisément les informations dont il a besoin. Les applications deviennent donc intuitives grâce à une récurrence visuelle.

Certains thèmes ne sont pas acceptés sur l'App Store, parmi lesquels : drogues, tabac, consommation excessive d'alcool, pornographie, etc.

Le nombre d'applications sur l'App Store excède aujourd'hui les 2 millions, et Apple est de plus en plus sélective pour offrir à ses utilisateurs un contenu de qualité. De ce fait il n'est pas question de copier simplement une application populaire et d'y effectuer a minima quelques changements puis de la publier.

Par exemple, ayant connu un certain succès aux débuts de l'App Store, les applications de type « fart box » ne sont plus acceptées car trop nombreuses et offrant toutes la même chose (article 4.1 « Copycat » des guidelines d'Apple).

Il n'est pas non plus question d'intégrer des fonctionnalités masquées, dormantes ou non documentées dans votre application. Les fonctionnalités de votre application doivent être claires pour les utilisateurs finaux ainsi que pour les équipes chargées de la vérification des applications. Toutes les nouvelles fonctionnalités et modifications du produit doivent être décrites précisément à chaque mise à jour de l'application.

L'utilisation des éléments graphiques standards d'iOS est recommandée (tableView, navigation bar, tab bar, etc.). Apple les utilise à outrance dans ses propres applications et les utiliser dans les vôtres apporte une cohérence qui va mettre l'utilisateur en confiance. De plus, les ingénieurs d'Apple sont connus pour passer énormément de temps sur les moindres détails et vouloir « réinventer la roue » s'avèrerait à coup sûr une perte de temps, en plus de concourir à augmenter le risque de refus de la part d'Apple.

Depuis iOS 13, Apple fourni également une grande quantité d'images vectorielles (SF symbols) au style iOS permettant de trouver facilement une image adaptée à la plupart des situations et des thèmes que vous rencontrerez. Inutile donc de passer du temps à rechercher des éléments d'interfaces sur le web.

Enfin, votre application doit fonctionner sur l'ensemble des tailles d'écrans disponibles grâce à AutoLayout. Il faut donc constamment garder en tête que tous vos éléments d'interface doivent être visibles et accessibles peu importe l'appareil de l'utilisateur. Certains éléments de votre application ne doivent pas être masqués ou tronqués sur les plus petits écrans, ou au contraire laisser trop d'espaces vides sur les plus grands écrans.

Une application doit offrir un minimum de fonctionnalités pour se voir acceptée sur l'App Store. Ainsi une application affichant un seul bouton se verra systématiquement refusée.

Il est vivement encouragé de choisir dès le départ une application dite universelle, c'est-à-dire qui fonctionnera de façon similaire sur iPhone et sur iPad avec le même binaire. En utilisant correctement les fonctionnalités AutoLayout de UIKit et Interface Builder, il sera aisé d'offrir une expérience de qualité aussi bien sur iPhone que sur iPad. Cela apportera une plus-value à votre application et permettra d'élargir votre base d'utilisateurs potentiels.

Les performances de votre application doivent être optimisées. L'application ne doit pas solliciter en permanence le processeur, faire des quantités d'appels réseaux, ou encore subir des saccades de l'image. Là encore, ces défauts peuvent constituer un motif de refus.

Si votre application utilise des données liées à la confidentialité de l'utilisateur telles que la localisation, l'accès à son appareil photo, ses contacts, etc., il faudra expliquer dans le fichier info.plist de façon précise pourquoi l'application a besoin d'accéder à ces données.

Lors de la soumission sur l'App Store, que nous abordons en partie « Configuration sous Xcode et gestion des builds », il faudra attester que ces données sont utilisées uniquement pour les motifs que vous évoquez et il sera également nécessaire de mettre en place une page web liée à la confidentialité de votre application. Cela doit se prévoir en amont afin de ne pas mettre en péril au dernier moment la date de mise en production prévue pour votre application.