Que fait new-app-info ?
Transformez la demande « Nous avons besoin d'informations supplémentaires » d'Apple en un seul fichier. L'utilisateur répond via App Store Connect et colle également le contenu dans le champ Notes d'App Review Information, afin que les futures soumissions en disposent. L'enregistrement est la seule partie que l'utilisateur doit réaliser lui-même.
Les six éléments demandés par Apple
Chaque dossier répond aux six éléments, numérotés de 1 à 6 dans cet ordre, même si le message d'Apple est manquant ou formulé différemment. Si le message d'Apple ajoute ou modifie un élément, suivez la version d'Apple et notez ce qui était différent.
| # | Apple demande | Répondu par |
|---|---|---|
| 1 | Un enregistrement d'écran capturé sur un appareil physique exécutant la dernière version du système d'exploitation. Il doit commencer par le lancement de l'application et montrer le parcours utilisateur typique, incluant, le cas échéant : inscription au compte, connexion et suppression de compte ; contenu généré par l'utilisateur avec signalement et blocage ; accès au contenu ou fonctionnalités payants | Partie 1 (la liste de prises de vue) + réponse §1 |
| 2 | L'objectif et le public cible de l'application : le problème qu'elle résout et la valeur qu'elle apporte | Réponse §2 |
| 3 | Instructions pour configurer et accéder aux fonctionnalités principales, y compris les identifiants de connexion ou fichiers d'exemple requis | Réponse §3 |
| 4 | Les services externes, outils ou plateformes utilisés pour les fonctionnalités principales (fournisseurs de données, authentification, processeurs de paiement, services d'IA) | Réponse §4 |
| 5 | Toute différence régionale dans les fonctionnalités ou le contenu, ou confirmation que l'application fonctionne de la même manière dans toutes les régions | Réponse §5 |
| 6 | Pour une industrie hautement réglementée ou des contenus tiers protégés : documentation ou justificatifs montrant l'autorisation | Réponse §6 |
Règles strictes
- L'enregistrement doit être effectué sur un appareil physique, avec la dernière version du système d'exploitation, en une seule prise non éditée à vitesse normale, en commençant par appuyer sur l'icône de l'application. Ne proposez jamais un enregistrement de simulateur ou une version accélérée pour la soumission. Vous ne pouvez pas piloter le téléphone de l'utilisateur, donc l'enregistrement lui incombe ; votre rôle est la liste de prises de vue.
- Ne mentionnez que ce qui est dans le build. Chaque fonctionnalité, service et langue doit provenir du code, et non de plans ou de notes.
- « Non applicable » est quand même une réponse. Donnez-la en une phrase avec la raison (par exemple, « L'application n'a pas d'inscription ou de connexion »).
- Comptes : si les utilisateurs peuvent créer des comptes, la suppression de compte est obligatoire et doit figurer dans l'enregistrement ; si elle est absente, signalez-le comme un blocage. S'il y a une connexion, l'élément 3 nécessite des identifiants de démonstration (un ensemble par type de compte) : dites à l'utilisateur de les saisir dans App Store Connect. N'écrivez jamais de vrais mots de passe dans le fichier.
- N'envoyez, ne soumettez et ne modifiez jamais quoi que ce soit dans App Store Connect. L'utilisateur colle la réponse et joint la vidéo.
- Remplissez chaque paramètre que vous pouvez depuis le dépôt ou l'appareil. Listez ceux qui restent et ce qui permet de les remplir.
Étape 1 : Lire le message d'Apple
Si l'utilisateur en a collé un, vérifiez ses éléments numérotés par rapport au tableau ci-dessus et notez les conditions d'enregistrement (comptes, contenu généré par l'utilisateur, contenu payant) qui s'appliquent à cette application.
Étape 2 : Se baser sur le code
Lisez le code au commit soumis, pas la copie de travail (épinglez-le d'abord, comme à l'Étape 6 → Le build de revue, étape 0). La copie de travail est souvent une branche de fonctionnalité avec des fonctionnalités non livrées, et les décrire à Apple revient à faire une déclaration sur un build qu'ils n'ont pas. Utilisez git grep <motif> <commit> -- <chemins> et git show <commit>:<chemin>.
Excluez build, Pods, .dart_tool, node_modules et .git dans chaque recherche.
| Élément | Où chercher |
|---|---|
| 1, 3 : parcours principal depuis le lancement | Routeur et écrans ; onboarding ; la boucle principale |
| 1, 3 : comptes, connexion, suppression | firebase_auth, sign_in_with_apple, supabase, Auth, login, signUp, deleteAccount, delete.*data |
| 1 : contenu généré par l'utilisateur | Publication, commentaires, chat, uploads ; report, block, flag |
| 1, 3 : contenu payant | purchases_flutter, revenuecat, StoreKit, product_id, écrans de blocage d'achat. Trouvez quelles fonctionnalités sont verrouillées, les éventuels essais gratuits, quand le blocage d'achat peut apparaître et où se trouve Restaurer les achats |
| 1 : blocage de capture d'écran | no_screenshot, astuces isSecureTextEntry, UIScreen.capturedDidChange, FLAG_SECURE. Un écran bloqué apparaît vide dans l'enregistrement, donc la réponse doit expliquer pourquoi |
| 2 : objectif et public | Texte de la fiche App Store, documentation de marque ou de ton, README, checklist de lancement, texte d'onboarding (.arb, .strings, strings.xml) |
| 3 : fichiers d'exemple | Importations de fichiers, sélecteurs de documents, scan de QR/code-barres, matériel nécessaire à l'application |
| 4 : services externes | Dépendances (pubspec.yaml, Podfile, package.json, Gradle) et définitions de build (--dart-define, fichiers de clés, scripts de release). Pour chacun : ce qu'il fait et quelles données il reçoit. Ne listez que les SDK que le build de release active réellement |
| 5 : régions | Langues livrées ; vérifications régionales (locale, countryCode, region) ; prix, fonctionnalités ou contenus spécifiques à une région |
| 6 : réglementé ou protégé | Contenu santé, médical, financier, jeux d'argent, juridique ou pour enfants et revendications associées ; contenu sous licence, musique, images, polices et leurs licences |
| Contact | Emails d'assistance dans les réglages, documents de confidentialité et fichiers du site web |
| Plateforme | IPHONEOS_DEPLOYMENT_TARGET, TARGETED_DEVICE_FAMILY (iPhone uniquement ou iPad aussi) |
Vérifiez que le libellé analytique de l'élément 4 correspond à la politique de confidentialité dans le dépôt. Signalez-le si ce n'est pas le cas, ou si vous ne pouvez pas confirmer les réponses de confidentialité de l'application dans App Store Connect.
Étape 3 : L'appareil et le système d'exploitation (élément 1)
xcrun devicectl list devicesmontre les appareils appairés. Prenez l'iPhone de l'utilisateur qui est disponible.xcrun devicectl device info details --device <id> | grep -i osVersionmontre sa version iOS.- Recherchez sur le web la dernière version iOS publiée. Si le téléphone est en retard, dites-le : l'utilisateur le met à jour dans Réglages → Général → Mise à jour logicielle avant l'enregistrement, puis vous relisez la version. La mise à jour du système du téléphone est de la responsabilité de l'utilisateur.
- Si aucun téléphone n'est appairé, laissez
[version iOS]et indiquez à l'utilisateur où la trouver (Réglages → Général → Informations).
Étape 4 : Prévenir les problèmes courants
Vérifiez chacun des problèmes courants d'Apple et intégrez le résultat dans le rapport à l'utilisateur. Ce sont des vérifications pour l'utilisateur, elles ne font pas partie de la réponse.
| Ligne directrice | Vérification |
|---|---|
| 2.1 Bugs et plantages | L'enregistrement utilise le build TestFlight de la version soumise, sur un appareil réel. Plateformes supportées par TARGETED_DEVICE_FAMILY : si iPad est supporté, dites à l'utilisateur de tester aussi sur un iPad |
| 2.1 Accès à l'application | Connexion → les identifiants de démonstration sont saisis dans App Store Connect, un ensemble par type de compte, et fonctionnent toujours |
| 2.3.3 Captures d'écran | Listez les captures d'écran du store (par exemple app-store-assets/*screenshots*). Signalez celles qui ressemblent à un simple logo, un écran de démarrage ou un écran de connexion |
| 3.1.1 Achat intégré | Chaque identifiant de produit dans le code est configuré dans App Store Connect et attaché à cette soumission. Listez les identifiants pour que l'utilisateur les vérifie |
| 3.2 Autres modèles économiques | Si l'application est destinée à une seule entreprise, organisation ou ses employés, signalez qu'elle nécessite une option de distribution différente (applications personnalisées ou distribution non listée) |
Étape 5 : Écrire le fichier
Écrivez app-store-assets/new-app-info.md si ce dossier existe, sinon ./new-app-info.md. Gardez cette structure (un exemple complet se trouve dans examples/seven-minute-math/new-app-info.md) :
# Informations pour l'examen de l'App Store — <Nom de l'app>
Répondez dans App Store Connect avec la Partie 2 et joignez l'enregistrement. Collez ensuite la Partie 2 dans
App Review Information → Notes, afin que les futures soumissions en disposent.
<Paramètres restant à remplir, le cas échéant.>
## Partie 1 — l'enregistrement d'écran (élément 1 ; enregistrez-le vous-même)
Pourquoi : un appareil physique, la dernière version du système d'exploitation, une seule prise, vitesse normale, en commençant par appuyer sur l'icône.
Configuration (par défaut : un build release installé depuis le Mac ; voir « Le build de revue » ci-dessous) :
créez un testeur sandbox (App Store Connect → Utilisateurs et accès → Sandbox → Comptes de test) ;
supprimez l'application du téléphone ; vous compilez et installez le build de revue ; Enregistrement d'écran dans
le Centre de contrôle avec le micro désactivé ; Ne pas déranger activé ; connectez-vous à la feuille d'achat d'Apple avec
le testeur sandbox (la feuille affichant « Sandbox » est normale).
Liste de prises de vue, numérotée : appuyez sur l'icône → onboarding → le parcours type de bout en bout → résultats →
chaque condition d'enregistrement qui s'applique (inscription, connexion, suppression du compte ; publication, signalement,
blocage ; paywall, achat sandbox, fonctionnalité déverrouillée, Restaurer les achats) → comment les utilisateurs
suppriment leurs données → arrêt.
Tout écran qui sera vide (blocage de capture) et pourquoi.
## Partie 2 — la réponse (collez ceci)
Salutation, plus l'appareil et la version iOS sur lesquels l'enregistrement a été effectué.
**1. Enregistrement d'écran** … **6. Industrie réglementée / Contenu tiers** : une section en gras pour chacun.
Ligne de clôture avec l'email d'assistance.
Rédaction :
- §1 : ce que montre l'enregistrement, les conditions d'enregistrement qui ne s'appliquent pas et pourquoi, et les écrans vides le cas échéant.
- §2 : à qui il s'adresse, le problème, comment l'application le résout, la valeur. Trois ou quatre phrases.
- §3 : ce qui est nécessaire pour démarrer (les identifiants vont dans App Store Connect, jamais dans le fichier), puis les fonctionnalités principales dans une courte liste, avec gratuit vs payant et quand le blocage d'achat apparaît.
- §4 : une puce par service avec ce qu'il fait. Puis une ligne indiquant ce que l'application n'utilise pas (IA, fournisseurs de données, authentification), le cas échéant.
- §5 : les langues et les éventuelles différences régionales, ou « fonctionne de la même manière dans toutes les régions ».
- §6 : documentation, ou « Non applicable » avec la raison.
- Factuel, simple et poli. Pas de langage marketing.
Étape 6 : La vidéo de bout en bout (élément 1)
Le build de revue
Enregistrez un build release de la version exacte en cours d'examen, installée sur le téléphone directement depuis le Mac. Vous le compilez et l'installez ; l'utilisateur enregistre.
- Épinglez la version soumise. Demandez à l'utilisateur le numéro de version et de build affiché dans App Store Connect pour la soumission en cours d'examen (par exemple 1.0.0 (1)), sauf s'il l'a déjà fourni. Trouvez le commit qui l'a produit : un tag de release, la branche release ou main, un message de commit tel que « livré sur l'App Store », ou le commit où
pubspec.yaml/Info.plistdéfinissent cette version et ce build. Si deux commits pourraient correspondre, demandez lequel. Ne compilez jamais à partir de la copie de travail : elle se trouve souvent sur une branche de fonctionnalité avec des modifications non commitées qu'Apple n'a pas vues. Compilez plutôt dans un worktree isolé (git worktree add --detach <scratch>/review-build <commit>). Copiez les fichiers de clés ignorés par git (par exemplekeys.json) dans ce worktree aveccp, sans les lire. Dites à l'utilisateur quel commit vous compilez et ce qui se trouve sur les branches plus récentes qui ne sera pas dans la vidéo. - Trouvez la procédure normale de build pour l'appareil du projet (scripts de run,
tool/*.sh, Makefile, Fastlane). Supprimez tous les indicateurs qui simulent des achats, commeDUMMY_PURCHASES,MOCK,FAKE,USE_TEST_STORE, une clé RevenueCattest_ou un fichier de configuration StoreKit. Un achat simulé n'affiche jamais la feuille d'Apple, et un évaluateur voyant des fonctionnalités payantes se déverrouiller sans cela peut considérer qu'il s'agit d'un contournement des achats intégrés (3.1.1). Vérifiez que la clé d'achat est la clé du store en production par son seul préfixe (par exemplegrep -q '"REVENUECAT_IOS_KEY": "appl_') ; n'imprimez jamais les valeurs des clés. - Compilez en mode release, jamais en debug : les builds debug Flutter et React Native ne peuvent pas être ouverts depuis l'icône de l'écran d'accueil, et Apple veut que l'enregistrement commence là. Flutter :
flutter build ios --releaseavec les définitions habituelles du projet moins les indicateurs simulés. - Vérifiez que l'application compilée correspond à la soumission :
/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" -c "Print CFBundleVersion" build/ios/iphoneos/Runner.app/Info.plistdoit afficher la version et le build soumis. Si ce n'est pas le cas, arrêtez et prévenez l'utilisateur. - Demandez à l'utilisateur de supprimer d'abord l'application du téléphone (cela efface ses données sur le téléphone, donc c'est son choix), puis installez :
xcrun devicectl device install app --device <id> build/ios/iphoneos/Runner.app. - Les builds installés depuis le Mac achètent via le sandbox d'Apple, donc l'utilisateur a besoin d'un testeur sandbox pour se connecter à la feuille d'achat. Une installation TestFlight du même numéro de build fonctionne aussi (les achats sont gratuits avec leur propre identifiant Apple), et elle garantit le binaire exact qu'Apple a. Utilisez-la si l'utilisateur le préfère.
Enregistrement et vérification
Le dossier n'est pas terminé tant que l'enregistrement n'existe pas et n'a pas été vérifié. L'utilisateur l'enregistre ; vous le guidez pas à pas. Dans le chat, donnez-lui la configuration de la Partie 1 (y compris le testeur sandbox) et la liste numérotée des prises de vue. Demandez-lui de vous AirDrop le fichier dans app-store-assets/review-recording/ et de vous dire quand il est là. Ensuite :
ffprobe -v error -show_entries format=duration:stream=width,height,codec_name -of default=nw=1 <fichier>. Vérifiez que la résolution correspond à un écran d'iPhone réel (pas une fenêtre de simulateur ou une édition recadrée) et que la durée couvre l'ensemble du parcours.- Réalisez une planche contact avec une image toutes les 10 secondes :
ffmpeg -i <fichier> -vf "fps=1/10,scale=240:-1,tile=8x8" -frames:v 1 <dossier>/contact.png. Enregistrez également la première image seule. Lisez les deux. - Vérifiez, dans l'ordre : la première image montre l'écran d'accueil ou l'icône de l'application en train d'être tapée ; chaque étape de la liste de prises de vue
… [tronqué pour traduction]