LaunchLint Academy
La réponse courte
- Un build Flutter réussi n'est pas encore prêt à soumettre. Identifiants, versions, signature, permissions, confidentialité et fiche doivent décrire la même production.
- Figez une release, testez l'artefact distribué sur de vrais appareils et conservez les preuves de chaque réponse.
- Ne gardez pas cette checklist pour le jour de la soumission. Utilisez-la comme gate de release, reliez chaque point au commit ou au champ du store concerné et rejouez les contrôles touchés après une modification des dépendances, permissions, environnements ou métadonnées. Les preuves ne contiennent ni secrets ni données personnelles de test. Développement, produit et responsable de la console doivent approuver exactement le même artefact. La vérification devient ainsi reproductible et permet d'expliquer la version réellement contrôlée après un rejet ou lors de la mise à jour suivante.
1. Figer la release
Notez commit, version Flutter, flavor, environnement et plateformes avant les archives natives.
Ne traitez pas figer la release comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de figer la release enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
2. Identité et versions
Bundle ID, application ID, version commerciale et numéros techniques doivent rester alignés.
Ne traitez pas identité et versions comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de identité et versions enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
3. Signature et propriété
Certificats Apple, provisioning, upload key et Play App Signing exigent responsables et récupération.
Ne traitez pas signature et propriété comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de signature et propriété enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
4. Permissions natives
Info.plist, AndroidManifest et plugins ne demandent que les accès nécessaires et expliqués.
Ne traitez pas permissions natives comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de permissions natives enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
5. Plugins et confidentialité
Les packages Dart peuvent ajouter SDKs et flux à déclarer dans les deux stores.
Ne traitez pas plugins et confidentialité comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de plugins et confidentialité enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
6. Tester le build
Le mode debug ne prouve pas login, deep links, push, achats et erreurs en production.
Ne traitez pas tester le build comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de tester le build enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
7. Préparer la fiche
Captures, textes, support, accès et achats doivent représenter la release figée.
Ne traitez pas préparer la fiche comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de préparer la fiche enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
8. Upload et rollout
Traitement, TestFlight ou tracks, avertissements et monitoring précèdent la production.
Ne traitez pas upload et rollout comme une case isolée. Reliez-le au build exact, à un responsable nommé et à une preuve vérifiable. Rejouez le parcours sur un appareil propre et documentez tout écart avant de poursuivre la soumission.
Preuves pour valider la release
- Valeur de production de upload et rollout enregistrée
- Fichier ou réglage du store relié
- Résultat attendu comparé au résultat observé
- Différences iOS et Android examinées
- Chaque doute possède responsable et échéance
- La release s'arrête si une contradiction bloque
Questions fréquentes
flutter build suffit-il ?
Non. L'artefact ne complète ni fiche, ni accès, ni déclarations.
Peut-on changer les identifiants ?
Considérez-les comme permanents après le premier upload.
Faut-il vérifier les plugins ?
Oui, ils peuvent ajouter permissions, SDKs et données.
LaunchLint compile-t-il Flutter ?
Non. Il lit les fichiers compatibles sans exécuter de code.