LaunchLint Academy
Réponse courte
- EAS Submit envoie le fichier final de l’app, mais ne remplit ni la fiche, ni les informations de confidentialité, ni les captures, ni les indications destinées à l’équipe de validation.
- Avant de créer l’app, vérifiez l’identité, les versions, les extensions et les autorisations. Testez ensuite la version de production sur des appareils réels et rapprochez le parcours d’App Store Connect et de Play Console.
- Intégrez la suppression de compte, l’accès de test, les achats et les pratiques de données des services tiers à chaque publication. Un processus technique réussi ne vaut pas approbation.
1. Ce que fait EAS Submit — et ce qui reste à votre charge
EAS Submit envoie le fichier iOS ou Android vers le store. Pour iOS, il arrive dans App Store Connect ou TestFlight ; pour Android, dans le canal configuré. Cela réduit les manipulations, mais Apple et Google examinent toujours l’app, les informations de la fiche et les indications fournies.
Un EAS Build et un EAS Submit réussis prouvent uniquement que le fichier a pu être créé et transféré. Ils ne prouvent ni la connexion d’un nouvel évaluateur, ni la précision des autorisations, ni l’exactitude des déclarations, ni le fonctionnement des achats et des pages publiques.
Après l’envoi, il faut encore :
- Compléter fiche, catégorie, âge et disponibilité
- Comparer captures et description à la version de production
- Remplir App Privacy et Data Safety
- Fournir contact, compte test et étapes
- Rendre achats et abonnements vérifiables
- Envoyer l’app traitée pour validation
2. Figer identité et versions avant la production
Bundle Identifier et package Android relient binaire, fiche, signature, push et souvent OAuth. Vérifiez-les avant le premier upload : une identité publiée ne se renomme pas comme le nom visible.
Séparez version marketing et numéro technique. Chaque nouveau binaire iOS exige un buildNumber supérieur ; Android utilise versionCode. Avec app.config dynamique, inspectez les valeurs réellement résolues en production.
{
"expo": {
"name": "My Production App",
"slug": "my-production-app",
"version": "1.0.0",
"ios": {
"bundleIdentifier": "com.example.myapp",
"buildNumber": "1"
},
"android": {
"package": "com.example.myapp",
"versionCode": 1
}
}
}- Identifiants et fiches correspondent
- buildNumber et versionCode augmentent
- Domaines API, OAuth et deep links sont ceux de production
- Icône, splash et nom sont définitifs
- Les variables d’environnement sont connues
3. Expliquer les permissions depuis le parcours utilisateur
Les bibliothèques Expo peuvent ajouter des permissions via Config Plugins ou manifests Android intégrés. Inventoriez les dépendances, vérifiez la configuration résultante et retirez les permissions inutiles.
Sur iOS, le Purpose String doit décrire une fonction vérifiable. Un message générique répète le dialogue ; un motif comme le scan du QR d’un billet explique moment et valeur. Une modification Info.plist exige un nouveau binaire et ne passe pas par OTA.
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription":
"Use the camera to scan the QR code on an event ticket."
}
},
"android": {
"blockedPermissions": [
"android.permission.RECORD_AUDIO"
]
}
}
}- Demander au bon moment
- Prévoir un parcours après refus
- Nommer finalité et bénéfice
- Permettre l’activation ultérieure
- Supprimer les permissions inutilisées
4. Aligner fichiers du projet, comportement et déclarations de confidentialité
package.json signale les bibliothèques et services tiers possibles sans produire une déclaration complète. Les services d’analyse, d’erreurs, de connexion, de publicité ou de paiement peuvent transmettre des données ; la configuration et l’utilisation réelle déterminent quoi, quand, pourquoi et vers qui.
| Niveau | Preuves utiles | Suffisant ? |
|---|---|---|
| Fichiers du projet | Services tiers, autorisations, extensions et adresses web | Non : ce sont des signaux |
| App exécutée | Moment, consentement, option et transfert | Non : serveurs et fournisseurs restent à vérifier |
| Console | Données, finalités, partage et suppression déclarés | Non : doit correspondre à l’app |
Google inclut dans Data Safety les données transmises par les services tiers et rend le développeur responsable. Documentez pour chaque service le type, le destinataire, le but, le caractère requis, la conservation et la suppression, puis comparez ces informations à la politique de confidentialité et aux formulaires.
5. Tester l’accès et la suppression comme un évaluateur externe
Si le cœur dépend d’un login, rôle, abonnement ou lieu, fournissez un chemin stable. Apple demande un compte démo actif ou un mode démo complet, sans données personnelles ni codes éphémères.
- Compte dédié et backend disponible
- Étapes courtes vers la fonction
- Détails pour rôles, QR, matériel ou lieu
- État démo pour achats
- Contact disponible
La suppression est un parcours complet. Apple exige de l’initier dans l’app ; Google demande aussi une ressource web. Testez confirmation, réauthentification, données liées, abonnements et conservation expliquée.
6. Comparer captures, promesses et achats à l’app
Les informations de la fiche font partie de la validation. Retirez les fonctions absentes ou internes, utilisez des captures atteignables et ouvrez les pages d’aide et de confidentialité sur mobile sans connexion.
Les produits numériques doivent être visibles et fonctionner pendant la validation. Testez restauration, échec, abonnement actif et réinstallation. La présence d’une bibliothèque de paiement ne prouve pas ces cas.
- Nom et description exacts
- Captures réelles
- Pages HTTPS publiques
- Achats visibles
- Indications courtes pour l’équipe
- Aucun texte provisoire ni message interne
7. Le preflight des 24 heures
Gelez brièvement la release, construisez depuis le commit prévu et testez cet artefact exact. Toute modification native, permission ou SDK impose un nouveau binaire et un contrôle ciblé.
- Noter commit et configuration
- Installer iOS et Android sur appareils réels
- Tester démarrage, login, refus, cœur, achat et suppression
- Rapprocher SDKs et privacy
- Relire images, textes, URLs et notes
- Valider le compte sur un autre appareil
- Uploader, vérifier le traitement, soumettre
Conservez build ID, parcours, résultat attendu, résultat réel et responsable. Après un rejet, cette preuve distingue plus vite défaut binaire, fiche ou communication.
8. Ce qu’apporte une vérification statique des fichiers du projet
L’analyse statique trouve les identifiants, services tiers, extensions, explications d’autorisations et signaux de connexion, d’achat ou de suivi dans des fichiers précis. Elle ne prouve pas tout le serveur, le compte de test ou chaque interaction.
LaunchLint n’exécute jamais le code tiers. La vérification guide le contrôle manuel et relie les preuves aux questions du store sans remplacer la responsabilité ou la décision finale.
Questions fréquentes avant une soumission Expo
Un EAS Build réussi suffit-il ?
Non. Il prouve la création du fichier de l’app, pas l’accès de test, les informations de la fiche, la confidentialité, les achats ou les parcours réels.
Peut-on corriger une permission iOS par OTA ?
Non. Une modification Info.plist exige un nouveau binaire natif.
Le compte démo doit-il contenir de vraies données ?
Non. Utilisez un compte dédié, sans données personnelles ni codes temporaires.
LaunchLint garantit-il l’approbation ?
Non. LaunchLint identifie risques et preuves ; Apple et Google décident.