Questions d'entretien Développeur mobile

Les performances sur mobile ne sont pas négociables car les utilisateurs désinstalleront une application qui semble lente, et contrairement à une application web, vous ne pouvez pas pousser un correctif instantanément. Mon approche commence par la mesure : j'utilise Xcode Instruments pour iOS et Android Profiler pour Android pour identifier les vrais goulots d'étranglement avant d'écrire une seule ligne de code d'optimisation. Les problèmes les plus courants que je trouve sont le blocage du thread principal, les re-rendus excessifs dans React Native et le chargement inefficace des images. Pour le travail sur le thread principal, je déplace tout calcul ou I/O hors du thread principal en utilisant des opérations asynchrones. Pour le chargement des images, j'utilise le chargement paresseux avec une couche de cache, en dimensionnant les images à la résolution d'affichage plutôt que de télécharger des assets haute résolution. Je profile également le temps de démarrage séparément car il affecte de façon disproportionnée la rétention : je cible moins de 2 secondes de démarrage à froid sur un appareil milieu de gamme.

L'offline-first est une décision de conception qui doit être prise au niveau de l'architecture, pas ajoutée après coup. L'idée centrale est que l'appareil local est la source de vérité pour les lectures, et le réseau est utilisé pour synchroniser l'état, pas pour servir chaque requête. J'utilise une base de données locale, SQLite via Room sur Android ou Core Data ou SQLite sur iOS, pour persister toutes les données dont les utilisateurs pourraient avoir besoin hors ligne. Les opérations d'écriture sont mises en file locale avec un indicateur de statut et un mécanisme de nouvelle tentative, et elles sont rejouées contre le serveur quand la connectivité est rétablie. Le problème difficile est la résolution des conflits : quand un utilisateur édite des données sur un appareil hors ligne et que le serveur a une version plus récente, je dois décider laquelle gagne. Ma préférence est une stratégie last-write-wins avec un timestamp serveur, avec une interface de résolution manuelle des conflits pour les cas critiques.

La complexité de la gestion d'état s'accroît rapidement dans les applications mobiles à mesure que le nombre d'écrans et de flux de données augmente. Mon approche dépend de la plateforme : sur iOS j'utilise une combinaison de la gestion d'état intégrée de SwiftUI pour l'état UI local et un pattern de flux de données unidirectionnel de style Redux pour l'état partagé de l'application, en utilisant une bibliothèque comme TCA pour les applications plus importantes. Sur React Native j'utilise Zustand ou Redux Toolkit selon les conventions existantes de l'équipe, et je fais une distinction délibérée entre état serveur et état client, en utilisant React Query pour le premier. L'erreur la plus courante que je vois est de tout mettre dans un seul store global, ce qui rend les tests difficiles et cause des re-rendus inutiles. Je structure l'état en modules qui correspondent aux fonctionnalités, et je garde l'état local au composant local sauf s'il doit vraiment être partagé.

Les soumissions aux stores sont lentes et les rejets sont coûteux, donc j'investis massivement dans le processus de révision avant de soumettre. Ma checklist couvre : l'exécution de la suite de tests complète incluant les tests UI sur de vrais appareils, la vérification des API dépréciées, la vérification que toutes les déclarations du manifeste de confidentialité correspondent aux permissions que l'application utilise réellement, et les tests sur la version OS minimale supportée. J'utilise TestFlight pour iOS et la piste de tests internes sur Google Play pour donner aux parties prenantes une version à réviser avant la publication publique. Pour les déploiements progressifs, j'utilise la fonctionnalité de déploiement graduel de l'App Store et le staged rollout de Google Play, en commençant à 5 % et en surveillant les taux de crash et les avis avant d'étendre.

Je travaillais sur une application React Native où l'écran d'accueil mettait 4,2 secondes à devenir interactif sur un appareil Android milieu de gamme. Les utilisateurs abandonnaient avant l'apparition du contenu. J'ai commencé avec le profileur de performance React Native et j'ai rapidement identifié que nous faisions six appels API séquentiels au montage, chacun attendant la fin du précédent, avant de rendre quelque contenu. Le premier correctif a été de paralléliser les appels API, ce qui a ramené le temps à 2,8 secondes. Le deuxième problème était que nous rendions la liste entière au montage alors que seuls les cinq premiers éléments étaient visibles : passer à une FlatList avec une extraction de clés et une estimation de hauteur d'éléments correctes a ramené le temps à 1,9 seconde. Le troisième problème était le chargement des images : nous téléchargions des images pleine résolution. Après être passé à des images correctement dimensionnées avec mise en cache, le temps d'interaction était de 1,1 seconde.

J'ai travaillé sur une application iOS qui devait prendre en charge iOS 15 à iOS 17, qui a introduit des différences significatives de SwiftUI entre les versions. Le défi était que plusieurs API que nous voulions utiliser n'étaient disponibles qu'à partir d'iOS 16, tandis que 30 % de nos utilisateurs étaient encore sur iOS 15. J'ai utilisé une approche de feature flags combinée à des vérifications de version OS pour fournir deux implémentations pour les fonctionnalités affectées : une implémentation complète pour iOS 16+ et une version de repli pour iOS 15. J'ai également mis en place une matrice d'appareils dans notre pipeline CI couvrant les versions OS minimale et maximale supportées. La décision la plus importante a été de s'entendre avec l'équipe produit sur un calendrier de fin de support d'iOS 15, ce qui nous a permis de planifier la simplification de la base de code plutôt que d'accumuler indéfiniment des chemins legacy.

J'avais un crash qui apparaissait dans Crashlytics affectant environ 0,3 % des sessions, mais uniquement sur des appareils Samsung spécifiques sous Android 11. Le crash était dans notre bibliothèque de mise en cache d'images, mais la trace de pile n'était pas reproductible sur aucun appareil que nous avions au bureau. Mon processus de débogage a commencé par l'isolation des conditions : j'ai commandé un Samsung A32 et reproduit le crash à la troisième tentative. La trace de pile pointait vers un échec d'allocation mémoire lors d'un décodage de bitmap. J'ai examiné l'utilisation de la mémoire et constaté que les appareils affectés disposaient de beaucoup moins de mémoire heap disponible en raison de contraintes de mémoire plus strictes de l'implémentation Android 11 de Samsung. Le correctif consistait à ajouter une vérification de mémoire avant les allocations de grandes bitmaps et à se dégrader gracieusement vers une image de résolution inférieure.

Les tests en mobile nécessitent une stratégie en couches car la pyramide de tests ressemble différemment du développement côté serveur. La couche la plus grande et la plus rapide est les tests unitaires pour la logique métier et la gestion d'état, que j'écris avec XCTest sur iOS ou JUnit sur Android. Ces tests couvrent les fonctions pures, la logique des view models et la transformation des données sans aucun engagement UI. La deuxième couche est les tests d'intégration qui vérifient l'interaction entre modules, particulièrement la base de données locale et la couche réseau. La troisième couche et la plus petite est les tests UI, que je garde au minimum car ils sont lents et fragiles, et je les concentre sur les parcours utilisateurs critiques. Pour React Native j'utilise Jest pour les tests unitaires et Detox pour les tests de bout en bout. La métrique clé n'est pas le pourcentage de couverture mais "peut-on détecter les régressions dans les flux critiques avant qu'elles n'atteignent la production ?"

L'implémentation des notifications push a une complexité différente sur chaque plateforme, et les principaux défis sont la gestion des tokens d'appareil, les états de permission de notification et la gestion des notifications quand l'application est dans différents états (premier plan, arrière-plan, tué). Sur iOS j'utilise APNs via Firebase Cloud Messaging. Les tokens d'appareil changent quand les utilisateurs réinstallent l'application, donc je rafraîchis toujours le token à chaque lancement et le synchronise avec le backend. La gestion des permissions est la complexité la plus visible pour l'utilisateur : iOS nécessite une permission explicite, que je demande à un moment contextuellement approprié plutôt qu'au premier lancement. Sur Android, la permission POST_NOTIFICATIONS est devenue obligatoire depuis Android 13, donc je gère les trois états : accordée, refusée et refusée définitivement. Je gère également les catégories et priorités de notifications correctement pour éviter que les notifications importantes ne soient silencieuses par l'optimisation de batterie.

Les choix d'architecture React Native faits tôt dans le projet sont très coûteux à changer plus tard, donc j'investis du temps pour bien structurer dès le départ. Mon architecture préférée est une structure de dossiers basée sur les fonctionnalités où chaque fonctionnalité contient ses propres composants, écrans, services et état, plutôt qu'une structure basée sur les types. Pour la navigation j'utilise React Navigation avec des routes typées, ce qui détecte les erreurs de navigation à la compilation. Pour l'intégration API, je crée une couche client API typée qui abstrait les appels HTTP, de sorte que les écrans et composants n'appellent jamais fetch directement. J'utilise des variables d'environnement pour les endpoints API et les feature flags, gérées via un module de configuration. Pour les modules natifs, j'écris une interface JavaScript qui enveloppe la fonctionnalité native. Je documente les décisions architecturales sous forme d'ADR dans le dépôt.