Le recrutement dépend du code à livrer et à maintenir
Vous devez livrer sur iOS et Android, mais une base de code commune ne suffit pas à définir le poste à ouvrir. La documentation de Meta / React Native précise que certaines propriétés de composants fonctionnent uniquement sur une plateforme. Nous proposons donc un choix conditionnel : recruter des compétences multiplateformes si le travail commun est confirmé et si la maintenance du code propre à chaque plateforme est prise en charge, des compétences natives si les travaux propres à iOS ou Android les exigent, ou un complément natif si vous conservez une base multiplateforme.
Si vous ignorez encore quels travaux nécessitent ces compétences, faites réaliser une vérification technique avant de figer le poste. Dans une situation hypothétique où personne ne sait corriger une intégration iOS, renforcer uniquement le développement commun laisserait ce travail sans responsable. Le risque serait alors d’engager un recrutement qui ne résout pas le problème identifié.
La distinction utile porte sur les travaux à prendre en charge. Un intitulé de poste ne permet pas, à lui seul, d’établir les compétences d’une personne ni le nombre de recrutements nécessaires.
Le code partageable se vérifie sur votre application
Demandez à votre équipe technique une description des fonctions communes aux deux applications et des comportements qui doivent différer. Pour chaque différence, faites préciser où le code correspondant se trouverait et qui pourrait le modifier. Ce document doit vous permettre de distinguer le travail commun des adaptations attendues.
Meta / React Native décrit deux mécanismes distincts : le module Platform pour les petites différences au sein d’un composant, et des fichiers portant les extensions .ios. et .android. lorsque le code spécifique devient plus complexe. Ces fichiers peuvent être des variantes JavaScript. Leur séparation ne signifie donc pas, à elle seule, qu’une intervention en langage natif est nécessaire.
Vous pouvez utiliser cette distinction pour préciser le recrutement envisagé : la personne devra-t-elle surtout faire évoluer le code commun, gérer ses variantes ou intervenir dans le code natif ? Les possibilités documentées par l’outil donnent un cadre à l’examen. Seule l’analyse de votre application permet de déterminer ce qui peut effectivement être partagé.
Les fonctions propres aux plateformes précisent le besoin natif
Une différence visible entre iOS et Android ne suffit pas à justifier un recrutement natif. Dans la documentation TextInput de Meta / React Native, clearButtonMode règle l’apparition du bouton d’effacement sur iOS et ne concerne que les champs de saisie sur une ligne. Il s’agit d’une propriété du composant, pas de la preuve qu’il faut écrire un module natif.
Une autre situation appelle un examen différent : une fonction requise par votre produit n’est accessible ni directement dans React Native ni par les bibliothèques disponibles. Meta / React Native documente alors la possibilité de relier le code JavaScript à du code natif, notamment en Swift ou Kotlin. Cette possibilité technique ne prouve pas qu’une telle intégration soit nécessaire dans votre projet.
Faites donc examiner les fonctions pour lesquelles le mode d’implémentation reste incertain. Demandez une conclusion explicite : adaptation dans React Native, recours à une bibliothèque compatible ou intervention dans le code natif. La documentation Using Libraries recommande de vérifier la compatibilité des bibliothèques avec les plateformes ciblées. Si ce point reste indéterminé, une vérification ciblée sur la fonction concernée doit précéder la définition du poste.
Vous pourrez ensuite nommer les compétences à vérifier pour ce travail précis. Pour réaliser une intégration identifiée, vous pouvez prévoir un complément de compétences natives tout en conservant le développement commun. La présence de différences entre plateformes ne permet pas de conclure automatiquement à la nécessité de deux recrutements natifs.
Les compétences de maintenance doivent être identifiées
Le travail à confier ne s’arrête pas à la première version livrée. Dans sa documentation de mise à jour, Meta / React Native explique qu’un projet typique comprend des projets Android, iOS et JavaScript, ce qui peut compliquer les changements de version. Il faut donc examiner qui pourra intervenir sur les parties réellement présentes dans votre application.
Pour évaluer les compétences disponibles, demandez une réalisation vérifiable proche des travaux identifiés : une anomalie corrigée, une intégration maintenue ou une mise à jour menée sur les applications concernées. Faites expliquer le diagnostic, les modifications effectuées et la manière dont leur résultat a été vérifié. L’observation d’une application qui fonctionne ne suffit pas à attribuer ces capacités à la personne qui la présente.
La validation mérite un examen distinct. Meta / React Native précise que les tests de composants JavaScript ne prennent pas en compte le code iOS ou Android sous-jacent. La même documentation décrit les tests de bout en bout comme une vérification de l’application sur un appareil ou un simulateur, du point de vue de l’utilisateur. Demandez donc ce que les tests présentés vérifient réellement, puis comment les comportements propres aux plateformes sont contrôlés.
Reliez les lacunes constatées au poste envisagé. Si les compétences disponibles pour réaliser le travail commun sont insuffisantes alors que les interventions spécifiques sont couvertes, le recrutement peut renforcer les compétences en développement multiplateforme. Si une partie native reste sans prise en charge, précisez les travaux correspondants et les moyens dont disposera la personne pour les réaliser. Une expérience déclarée sur un outil ne remplace pas cet examen.
Vous pouvez définir le poste quand chaque partie a un responsable
Avant d’ouvrir le poste, faites valider la répartition des travaux et les compétences sur lesquelles elle repose. Un besoin commun confirmé oriente vers un recrutement multiplateforme si la maintenance du code propre à chaque plateforme est prise en charge. Des travaux propres aux plateformes qui exigent des compétences absentes orientent vers un recrutement natif, ou vers un complément natif si une base multiplateforme est conservée.
Lorsque la capacité à réaliser ou à maintenir une partie reste inconnue, ne figez pas encore le poste et faites vérifier qui peut réaliser ou maintenir cette partie. Nous proposons cette démarche pour relier le recrutement au travail attendu. Les documentations techniques ne permettent toutefois d’établir ni la part partageable de votre application ni les compétences effectivement disponibles dans votre équipe.
Sources
Meta / React Native : Platform-Specific Code
Meta / React Native : TextInput
Meta / React Native : Native Platform
Meta / React Native : Using Libraries
