LaunchLint Academy
La réponse courte
- Les captures App Store sont à la fois un livrable technique et la principale vitrine visuelle de l’app. Elles doivent respecter des dimensions précises, refléter la version soumise et faire comprendre la valeur du produit dès les premières images.
- Ce guide structure les formats, les appareils, le récit, la localisation et la validation afin qu’une équipe Expo ou React Native dispose d’un processus reproductible à chaque sortie.
Ce qu’Apple exige réellement
Apple autorise actuellement entre une et dix captures pour chaque taille d’appareil prise en charge. Les fichiers doivent être en JPEG, JPG ou PNG, sans transparence. Les aperçus vidéo sont facultatifs, mais les captures des classes demandées font partie de la fiche produit.
La spécification distingue les classes iPhone et iPad. Si l’app fonctionne sur iPad, des visuels iPad adaptés sont nécessaires. Un seul export de téléphone ne couvre pas automatiquement tous les emplacements et ne raconte pas forcément bien le produit sur grand écran.
Base technique
- Une à dix captures par taille requise
- JPEG, JPG ou PNG sans canal alpha
- Dimensions exactes acceptées par App Store Connect
- Visuels iPad lorsque l’app le prend en charge
- Contrôle des erreurs après le téléversement
Planifier les dimensions et appareils
Pour les grands iPhone actuels, Apple accepte notamment 1260 × 2736, 1290 × 2796 et 1320 × 2868 pixels. Pour l’iPad 13 pouces, 2064 × 2752 et 2048 × 2732 figurent parmi les formats portrait. La table officielle reste la référence à consulter.
Construisez les modèles autour d’une résolution vérifiée plutôt que du nom commercial d’un appareil. Les exports et la validation restent ainsi stables quand le matériel change ou qu’App Store Connect réorganise ses classes d’écran.
Matrice des formats
- Lister les plateformes prises en charge par le build
- Noter les dimensions et la date de vérification
- Créer un master par rapport d’image
- Valider largeur et hauteur automatiquement
- Relire la spécification avant chaque sortie
Montrer l’app livrée, pas une maquette
Chaque capture doit représenter un usage réel. Un fond, un titre court ou un cadre d’appareil peut renforcer le message, mais ne doit pas annoncer une fonction absente ou différente dans le build examiné.
Les produits créés avec l’IA accumulent facilement prototypes, anciens paywalls et parcours abandonnés. Reliez chaque visuel à une route et à un état reproductibles de la version candidate afin que la promesse corresponde au produit.
Preuves par visuel
- Associer chaque image à une fonction réelle
- Ne pas présenter une fonction future comme disponible
- Employer des données de démonstration plausibles
- Ne pas fabriquer de dialogue système trompeur
- Conserver le numéro de build et la date
Transformer la galerie en récit court
Les trois premiers visuels portent l’essentiel du message. Commencez par le résultat principal, poursuivez avec le parcours central et montrez ensuite une preuve concrète. Un récit centré sur le problème est plus clair qu’une visite de tous les menus.
Une carte doit transmettre une seule idée. Des titres courts sont plus rapides à comprendre qu’un inventaire de fonctions. Si le lecteur doit déchiffrer de petits textes pour distinguer deux images, la hiérarchie reste insuffisante.
Séquence conseillée
- Visuel 1 : résultat ou bénéfice principal
- Visuel 2 : parcours central
- Visuel 3 : preuve ou résultat obtenu
- Puis : différences, intégrations et confiance
- Fin : conclusion utile sans répétition
Localiser sans casser la composition
App Store Connect permet de localiser les captures. Le résultat n’est crédible que si le titre et l’interface visible utilisent la même langue. Les dates, monnaies, nombres et données doivent aussi correspondre au marché.
Prévoyez dès le départ des zones capables d’accueillir des traductions longues. Il vaut mieux adapter la rédaction avec des limites de lignes que réduire la police jusqu’à la rendre illisible.
QA de localisation
- Même langue dans le titre et l’interface
- Formats régionaux cohérents
- Aucun mot coupé ni contrôle masqué
- Aucun ancien export d’une autre langue
- Aperçu séparé de chaque locale
Mettre en place une capture reproductible
Définissez comptes de test, données, réglages et états exacts avant la prise. Une heure, une barre d’état, un thème et un contenu cohérents donnent l’impression d’une campagne unique. Les informations personnelles n’ont jamais leur place dans les sources.
L’automatisation peut capturer et contrôler les dimensions, mais elle ne choisit pas seule le meilleur récit. Conservez séparément la source brute, le master éditable et l’export final pour modifier le texte sans reconstruire l’état de l’app.
Processus de production
- Liste de prises avec route, état et message
- Compte dédié et données déterministes
- Sources sans informations personnelles
- Master centralisé et versionné
- Nom d’export avec langue, classe et version
Valider le visuel et la technique
Examinez toute la séquence au format miniature de la boutique. Contraste, taille des caractères et rythme doivent survivre à cette réduction. Des écrans répétés ou des cadres incohérents affaiblissent une app pourtant solide.
Un contrôle automatique valide dimensions, format, canal alpha, orientation et intégrité. Une personne compare ensuite chaque image au build final. Ces deux niveaux sont indispensables, car un fichier valide peut encore présenter une promesse fausse.
Validation finale
- Chaque fichier possède une dimension acceptée
- Aucune transparence ni mauvaise orientation
- Titres lisibles en miniature
- Récit compréhensible sans contexte
- Fonctions présentes dans le build soumis
Téléverser tôt et maintenir les visuels
Téléversez avant la dernière fenêtre de soumission afin de détecter les erreurs de traitement. Vérifiez chaque langue et classe d’appareil sur la fiche complète : un fichier accepté n’est pas encore une validation éditoriale.
Après une évolution importante de l’interface, la revue des captures doit faire partie de la définition de terminé. Une matrice avec visuel, route, langue, dimension, build et date révèle rapidement les ressources obsolètes.
Porte de sortie
- Toutes les langues et classes sont complètes
- Aperçus App Store Connect validés
- Aucun avertissement ignoré
- Matrice liée au build actuel
- Responsable de maintenance désigné
Questions fréquentes
Combien de captures Apple autorise-t-il ?
Apple permet actuellement d’envoyer entre une et dix captures par taille d’appareil prise en charge.
Faut-il chaque modèle d’iPhone ?
Non. Il faut couvrir les classes demandées par App Store Connect avec une dimension exacte acceptée.
Les captures iPad sont-elles obligatoires ?
Si l’app soumise fonctionne sur iPad, fournissez les visuels correspondant à la classe iPad requise.
Peut-on ajouter du texte et un cadre ?
Oui, si la composition reste fidèle à l’app et ne suggère aucune fonction indisponible.
Le même jeu convient-il à toutes les langues ?
C’est parfois possible techniquement, mais une localisation crédible harmonise titre, interface visible et formats régionaux.