LaunchLint Academy
La réponse courte
- Expliquez accès, navigation, prérequis, fonctions non évidentes, achats et corrections après rejet, sans répéter la fiche.
- Fournissez un compte durable, gardez le backend actif et testez le parcours sur appareil neuf avec le build soumis.
- Écrivez court et vérifiable. Ne partagez jamais clés API, accès admin ou données clients réelles.
1. Rôle des indications pour l’équipe de validation
Apple demande des explications sur les fonctions et achats non évidents. Les notes privées complètent contact, compte démo et pièces jointes pour éviter les parcours bloqués.
Ce n’est pas une seconde description. ‘Tout fonctionne’ n’aide pas ; ‘Projects > Demo Project > Export ouvre le PDF sans achat’ est vérifiable.
2. Informations minimales
Gardez nom, téléphone, email et besoin de compte démo à jour et surveillés. Un contact absent ralentit la review.
Commencez par version et build, puis les changements et conditions propres à cet artefact. Supprimez les anciens chemins.
- Version et build
- Changement principal
- Compte ou demo mode
- Chemin court
- Rôle, région, QR ou matériel
- Conditions IAP
- Contact surveillé
3. Un compte démo robuste
Il ne doit pas dépendre de votre téléphone, email temporaire, validation manuelle ou magic link expirant. Gardez backend et médias en ligne.
Utilisez des données fictives montrant les états utiles. Décidez si un compte couvre les rôles et testez hors du réseau interne.
- Pas de compte personnel
- Pas de données clients
- Mot de passe stable
- 2FA documentée
- Données exemple
- Pas de nettoyage automatique
- Monitoring et responsable
4. Décrire les parcours non évidents
Indiquez prérequis, navigation, action et résultat. Ne faites pas deviner feature flag, rôle, QR, localisation, Bluetooth ou contenu approuvé. Joignez un exemple fictif si nécessaire.
Pour permissions, nommez la fonction ; pour suppression, le chemin ; pour UGC, signaler et bloquer ; pour région, celle du compte.
| Vague | Note |
|---|---|
| Login fonctionne | Se connecter ; Projects affiche deux exemples |
| Caméra requise | Project > Scan receipt ouvre la caméra |
| Suppression présente | Settings > Account > Delete |
| Premium testable | Compte démo abonné ; Export dans Demo Project |
5. Achats et abonnements testables
Les IAP doivent être complets, actuels, visibles et fonctionnels. Expliquez paywall conditionnel, produit régional ou rôle requis.
Nommez produit visible et chemin. Testez restore, abonnement actif, échec et réinstallation. Si le compte est premium, expliquez comment voir la paywall.
- Produits prêts
- Accords actifs
- Paywall accessible
- Conditions cohérentes
- Restore
- Sandbox testé
- Exception en une phrase
6. Modèle pratique
Utilisez une structure répétable sans boilerplate ancien. Retirez l’inutile et mettez à jour build, chemins et compte. Un anglais simple est souvent robuste.
BUILD
- Version / build: [1.0.0 / 42]
- Main change: [one factual sentence]
REVIEW ACCESS
- Demo account: [dedicated review account]
- Path: Launch app > Sign in > [feature]
- Required role or setup: [only if applicable]
NON-OBVIOUS FLOWS
- Purchase appears when: [condition]
- Account deletion: Settings > Account > Delete account
- Permission purpose: [feature and user value]
CONTACT
- Name: [responsible person]
- Email / phone: [monitored during review]Gardez le modèle dans le processus release, pas comme secret dans le fichiers du projet. Saisissez les identifiants par un flux contrôlé et vérifiez les anciens numéros.
7. Répondre à un rejet avec preuves
Lisez guideline et parcours, reproduisez dans le build rejeté et décidez entre métadonnées ou nouveau binaire. Vous pouvez répondre et joindre des preuves avant resoumission.
Nommez cause, modification et vérification avec build et chemin. Demandez les étapes exactes si vous ne reproduisez pas.
- Conserver message
- Reproduire
- Finir le fix
- Tester régression
- Mettre à jour notes
- Indiquer build et chemin
- Joindre uniquement le pertinent
- Ne pas garantir
8. Vérification finale des Notes
Demandez à une autre personne de suivre les Notes mot à mot sur un appareil sans session. Elle ne doit avoir besoin ni d’explication orale, ni de VPN interne, ni de droit administrateur. Si elle bloque, corrigez d’abord le produit ou l’accès ; le texte ne doit pas masquer un parcours cassé.
Vérifiez aussi build number, nom visible du produit, menus localisés, identifiants, région et exemples. Ouvrez chaque pièce jointe et URL depuis un réseau externe. Le contact doit connaître la date de soumission et pouvoir répondre pendant la review.
Checklist :
- Build et version corrects
- Identifiants testés avant submit
- Backend et médias disponibles
- Chemin principal minimal
- Rôles et conditions expliqués
- IAP visibles et restore testé
- Suppression localisée
- Permissions liées à une fonction
- Aucun secret ni donnée réelle
- Contact prévenu
- Ancien texte retiré
- Copie conservée avec la release
9. Intégrer les Notes au processus de release
Des Notes rédigées de mémoire juste avant le submit deviennent vite fausses. Créez une tâche de release avec propriétaire, date et build. Le produit confirme les parcours, l’ingénierie vérifie l’artefact et ses dépendances, et le support connaît la période de review. Conservez le texte envoyé avec le changelog afin de reproduire exactement les informations reçues par le reviewer.
Après approbation ou rejet, notez quelle instruction a fonctionné et quel état manquait. Ne transformez pas ces retours en boilerplate permanent : comparez chaque phrase au prochain build. Si un chemin, rôle, IAP ou compte change, corrigez la note et rejouez le parcours. Les Notes deviennent ainsi une preuve opérationnelle et non un texte décoratif.
Handoff minimum :
- Owner et contact assignés
- Texte lié à version et build
- Compte testé par une autre personne
- Pièces jointes archivées
- Réponse du reviewer enregistrée
- Apprentissage appliqué à la release suivante
Questions fréquentes
Anglais ou français ?
Un anglais simple est souvent robuste ; chemins et identifiants exacts comptent davantage.
Puis-je inclure des identifiants ?
Oui pour un compte démo contrôlé, jamais des secrets infrastructure.
Sans login faut-il des notes ?
Seulement pour fonctions, achats ou conditions non évidentes. Évitez le boilerplate.
Une capture évite un nouveau build ?
Non lorsqu’un correctif code ou natif est nécessaire.