LaunchLint Academy
La réponse courte
- FlutterFlow peut envoyer des builds sans prendre en charge comportement, packages, confidentialité ou fiche.
- Traitez code généré, actions, APIs, environnements et accès comme une release normale avec preuves.
- 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. Choisir la production
Package name, endpoints, Firebase et flags appartiennent à l'environnement public.
Ne traitez pas choisir la production 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 choisir la production 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. Créer l'identité
Bundle ID, App ID et package Play concordent dans tous les comptes.
Ne traitez pas créer l'identité 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 créer l'identité 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. Protéger l'accès
Keys, issuer ID, service accounts et keystore ont droits minimaux et rotation.
Ne traitez pas protéger l'accès 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 protéger l'accès 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. Inventorier le custom code
Actions, widgets et packages peuvent ajouter permissions, secrets ou données.
Ne traitez pas inventorier le custom code 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 inventorier le custom code 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. Permissions et manifest
Caméra, localisation, fichiers et APIs exigent une configuration précise.
Ne traitez pas permissions et manifest 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 et manifest 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. Expliquer le backend
Firebase, Supabase, APIs, analytics et uploads concordent avec la confidentialité.
Ne traitez pas expliquer le backend 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 expliquer le backend 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. Tester le vrai build
Preview ne remplace pas un build signé avec redirects, push et achats.
Ne traitez pas tester le vrai 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 vrai 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
8. Terminer la soumission
Le deployment envoie le build ; fiche, notes, contenu et release restent séparés.
Ne traitez pas terminer la soumission 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 terminer la soumission 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
FlutterFlow termine-t-il l'envoi ?
Non. Fiche et review restent sous votre responsabilité.
Faut-il vérifier le custom code ?
Oui, il peut modifier permissions, secrets et données.
Peut-on réutiliser le package name ?
Les environnements séparés exigent des identités contrôlées.
LaunchLint exécute-t-il l'export ?
Non. Il l'analyse statiquement.