Développeur mobile iOS

Maîtriser le langage de la stack choisie : types, optionnels ou valeurs nulles, structures et classes, protocoles ou interfaces, collections, gestion des erreurs, et savoir écrire une logique métier testée sans interface.

L'office de tourisme d'une vallée des Alpes publie ses itinéraires de randonnée dans un fichier tableur que personne ne lit sur le terrain. Il veut une application iPhone, qui sera votre fil rouge jusqu'au sprint 7. Vous commencez par le cœur de l'application, sans aucun écran : itinéraires, étapes, points d'intérêt, niveau de difficulté, saisons d'ouverture. À partir d'un fichier de traces fourni, votre code calcule la distance, le dénivelé positif et une durée estimée selon le profil du marcheur, puis filtre les itinéraires selon plusieurs critères. Les données incomplètes ou incohérentes du fichier doivent être signalées sans faire planter le programme. Vous accompagnez ce module de tests unitaires. Le mentor regardera la clarté de vos types, votre traitement des valeurs absentes et la lisibilité de vos fonctions.

Construire des écrans avec le modèle déclaratif de la stack : composition de vues, gestion de l'état, listes performantes, prise en charge de la taille de texte dynamique, du mode sombre et de VoiceOver.

L'office de tourisme a fait dessiner les principaux écrans : liste des itinéraires avec filtres, fiche détaillée avec profil de dénivelé, carte des points d'intérêt et écran des favoris. Vous construisez ces écrans avec l'interface déclarative de votre stack, en les reliant au module du sprint 1. Vous créez des composants réutilisables (carte d'itinéraire, pastille de difficulté, profil de dénivelé simplifié) et vous gérez l'état d'affichage proprement. L'application doit respecter les conventions d'iOS, rester lisible avec une grande taille de texte, s'adapter au mode sombre et être utilisable avec VoiceOver, car l'office reçoit de nombreux visiteurs âgés. En soutenance, vous faites la démonstration avec VoiceOver activé et une taille de texte maximale.

Structurer une application à plusieurs écrans : piles de navigation, onglets, feuilles modales, liens profonds, et formulaires validés qui tirent parti des claviers, des sélecteurs et des permissions d'iOS.

Les agents de l'office passent beaucoup de temps à vérifier l'état des chemins. L'office veut que les randonneurs puissent signaler eux-mêmes un arbre tombé, un balisage effacé ou une passerelle fragile. Vous organisez la navigation de l'application : onglets, passage de la liste à la fiche puis à une étape, feuille modale pour les filtres, ouverture directe d'une fiche par un lien partagé. Vous développez ensuite le formulaire de signalement : type de problème, description, photo prise avec l'appareil, position actuelle avec demande d'autorisation expliquée, coordonnées facultatives. Le formulaire est validé au fil de la saisie et reste utilisable d'une main. Le mentor vérifiera le comportement de l'application quand l'utilisateur refuse l'accès à l'appareil photo ou à la position.

Connecter l'application à des services distants : appels REST asynchrones, décodage JSON, authentification, envoi de fichiers, gestion des erreurs et des réseaux instables, organisation du code en couches testables.

Les itinéraires changent selon les saisons et les signalements doivent parvenir à l'office. Deux API vous sont fournies : celle de l'office (itinéraires, signalements, compte du randonneur) et un service de prévisions météo par position. Vous remplacez le fichier local par l'API de l'office et vous ajoutez la météo des trois prochains jours sur chaque fiche. Les signalements sont envoyés au serveur avec leur photo compressée. Vous organisez le code en couches (client réseau, dépôts, modèles de vue) et vous gérez l'authentification du randonneur, les délais d'attente, les erreurs du serveur et les états de chargement visibles. Une alerte s'affiche si la météo annonce un orage sur l'itinéraire choisi. En soutenance, le mentor dégradera la connexion pour vérifier que l'application reste claire et ne perd aucun signalement.

Rendre l'application fiable en montagne : stockage local structuré, téléchargement d'itinéraires pour un usage hors ligne, file d'envoi différé, préférences utilisateur et stockage sécurisé dans le trousseau.

Sur la plupart des sentiers de la vallée, il n'y a aucun réseau. Un randonneur doit pouvoir préparer sa sortie chez lui, puis tout consulter sur place. Vous ajoutez un stockage local structuré qui conserve les itinéraires consultés et les favoris. Un bouton permet de télécharger un itinéraire complet (fiche, étapes, photos, fond de carte simplifié) avec un indicateur de l'espace occupé et la possibilité de le supprimer. Les signalements créés hors ligne sont mis en attente et envoyés automatiquement au retour du réseau. Les préférences (profil de marche, unités) sont conservées, et le jeton de session est rangé dans le trousseau. Vous documentez la stratégie de mise à jour des données téléchargées : quand l'application les rafraîchit et comment elle signale un itinéraire modifié depuis le téléchargement.

Garantir la qualité de l'application : tests unitaires des couches métier et données, tests d'interface des parcours clés, débogage avec les outils de la stack, profilage de la mémoire, de l'énergie et du temps de démarrage.

Une version de test a été confiée à vingt guides de montagne. Leurs retours sont précis : la batterie se vide vite pendant une sortie, l'application met plusieurs secondes à démarrer et un plantage survient parfois en ouvrant une fiche téléchargée. Vous reproduisez ces trois problèmes, vous en trouvez la cause avec les outils de débogage et de profilage de votre stack, puis vous les corrigez. Pour chacun, vous écrivez un test qui empêche sa réapparition. Vous complétez ensuite la stratégie de tests : tests unitaires des calculs et des dépôts de données, tests d'interface des parcours principaux (recherche, téléchargement, signalement hors ligne). Votre rapport présente pour chaque problème les mesures avant et après correction.

Industrialiser la livraison : identifiants et profils de signature, configurations par environnement, pipeline d'intégration continue, distribution TestFlight, fiche App Store et respect des règles de confidentialité d'Apple.

L'office veut présenter l'application lors de l'ouverture de la saison, et chaque correction doit pouvoir être livrée aux guides sans manipulation manuelle. Vous configurez les environnements de l'application (développement, recette, production) avec leurs adresses d'API, puis la signature, en gardant certificats et clés hors du dépôt. Vous mettez en place un pipeline qui lance les tests et construit l'application à chaque pull request, et qui envoie une version sur TestFlight à chaque fusion. Vous préparez la fiche de l'App Store : textes, captures aux bonnes dimensions, étiquette de confidentialité qui décrit honnêtement les données collectées, justification des autorisations demandées. En soutenance, vous livrez une modification en direct et le mentor l'installe depuis TestFlight.

Réaliser une application iOS à partir d'un besoin client réel issu d'une mission Formuloo, la livrer jusqu'à TestFlight et la défendre devant un jury avec l'ensemble de son portfolio.

Ce dernier sprint vous confie un besoin client réel issu d'une mission Formuloo : une application iPhone à créer ou une application existante à faire évoluer, par exemple pour une enseigne de commerce, une association ou un service de santé. Vous recevez au début du sprint les maquettes, l'API ou sa documentation et les contraintes du client, anonymisées si nécessaire. Vous menez le projet comme en entreprise : reformulation du besoin, découpage en tickets, développement dans la stack choisie, accessibilité, tests et distribution par TestFlight. Le mentor tient le rôle de référent technique et un membre de l'équipe Formuloo celui du client, avec un point d'étape à mi-sprint. La soutenance finale se déroule devant un jury : démonstration sur un appareil réel, présentation du portfolio des huit sprints et questions sur vos choix, vos compromis et ce que vous amélioreriez ensuite.