Je vais créer une application mobile multiplateforme avec React Native pour iOS et Android

Ce que cela couvre

Un code source React Native, deux magasins, un ensemble de bugs à corriger. Navigation, authentification, notifications push, gestion hors ligne et les différences de plateforme qu'un framework multiplateforme ne fait pas disparaître de lui-même.

Comment je l'aborde

L'application est construite sur votre API réelle dès le premier jour, et non sur des données simulées qui se comportent mieux que la production ne le fera jamais. L'authentification utilise un stockage sécurisé sur l'appareil et des jetons d'actualisation gérés en un seul endroit, car les bugs de jetons dispersés sur les écrans sont le moyen le plus courant de faire pourrir les applications mobiles. Les listes sont virtualisées et paginées; les images sont mises en cache et dimensionnées pour l'appareil plutôt que téléchargées en pleine résolution.

Le travail de plateforme est traité comme du travail, pas comme une note de bas de page: iOS a besoin de ses propres chaînes d'autorisation et de son provisionnement, Android a besoin de ses canaux de notification et de son comportement de bouton de retour, et les deux ont besoin de liens profonds qui survivent à un démarrage à froid.

Livrables

• Projet React Native en TypeScript, avec les modules natifs dont vous avez besoin et aucun autre.
• Versions TestFlight et Play en piste interne pour que vous puissiez le tenir en main rapidement.
• Notifications push câblées de bout en bout, y compris le déclencheur backend.
• Versions de publication, texte de la liste du magasin et captures d'écran, et les notes nécessaires pour soumettre.
• Un court guide pour l'exécuter, le construire et le publier vous-même.

Ce dont j'ai besoin

Une API ou une spécification pour une, les trois écrans les plus importants, et des comptes développeur Apple et Google si vous les avez déjà. Si vous ne les avez pas, je vous dirai exactement quoi créer et quand.

Note de portée

Une application, un public. Si le produit nécessite deux expériences très différentes — par exemple une application client et une application chauffeur — ce sont deux versions et je le dirai avant de citer plutôt qu'après.

Délai et communication

Première version TestFlight ou en piste interne généralement dans les deux semaines, de sorte que vous tenez l'application et donnez des commentaires sur la chose elle-même plutôt que sur des captures d'écran. Je garde la liste de contrôle de publication explicite — autorisations, liens profonds, comportement hors ligne, métadonnées du magasin — car ce sont les éléments qui transforment une application fonctionnelle en une soumission rejetée. Chaque version que vous recevez est une version que vous pourriez expédier.