Mettre à jour les métadonnées App Store sans fastlane deliver en 2026

Read in English →

fastlane deliver est la façon classique de pousser les métadonnées App Store depuis un dépôt : des fichiers texte par langue, des captures dans des dossiers, une commande. Ça marche. Ça apporte aussi Ruby, une arborescence à garder alignée avec App Store Connect, et des lanes à réparer quand Apple change quelque chose.

Voici ce que fait vraiment deliver, ce qu'il y a dessous, et les autres façons d'obtenir le même résultat.

Ce que fait deliver

D'après la documentation de fastlane : deliver envoie captures, vidéos d'aperçu, métadonnées et binaires vers App Store Connect, et peut soumettre l'app à la review.

fastlane deliver init                  # récupère la fiche actuelle dans ./fastlane/metadata
fastlane deliver download_screenshots  # récupère les captures actuelles
fastlane deliver                       # pousse métadonnées, captures, aperçus

Chaque langue a son dossier avec un fichier par champ : name.txt, subtitle.txt, description.txt, keywords.txt, release_notes.txt, promotional_text.txt, support_url.txt, marketing_url.txt, privacy_url.txt. Un dossier default remplit les langues non surchargées.

Les options que vous croiserez : skip_binary_upload, skip_screenshots, skip_metadata, overwrite_screenshots (désactivée par défaut, donc les nouvelles captures s'ajoutent au lieu de remplacer), submit_for_review, automatic_release et phased_release. deliver lance aussi precheck avant de soumettre.

Les limites que deliver doit respecter

La troisième colonne piège ceux qui écrivent leurs propres scripts : Apple répartit une fiche sur deux ressources. Le nom, le sous-titre et l'URL de politique de confidentialité vivent sur les infos de l'app, indépendamment des versions. Description, mots-clés, nouveautés, texte promotionnel et URL de support et marketing vivent sur la version App Store. Si vous n'en lisez qu'une, la moitié des champs revient vide.

Les pièges derrière l'API (vécus en production)

Ils viennent de la construction du même circuit d'envoi dans OneStore, pas de la doc :

• Les captures avec un canal alpha sont refusées après coup. La requête de validation répond 200, puis le traitement d'Apple marque la capture en échec avec IMAGE_ALPHA_NOT_ALLOWED, même si chaque pixel est opaque. Aplatissez les PNG avant l'envoi et vérifiez assetDeliveryState après.
• Les nouveautés sont obligatoires sur chaque langue d'une mise à jour. Une langue créée seulement pour les captures ou la description, avec des nouveautés vides, bloque la soumission.
• La version doit exister et être modifiable. Impossible de modifier les métadonnées d'une version en attente de review ou en ligne. Il faut une version dans un état modifiable (en préparation, refusée, métadonnées refusées).
• Le nom et le sous-titre ne changent pas sur une version en ligne sans nouvelle version. Ils dépendent des infos d'app liées à la version que vous préparez.

Quatre autres façons de pousser la fiche

1. App Store Connect, à la main

Très bien pour une app en une ou deux langues. Ça devient du copier-coller dès cinq langues, et rien ne vérifie la version Google Play du même texte.

2. L'API App Store Connect directement

Ce que deliver utilise en dessous : une clé d'API (.p8), un JWT signé, puis des PATCH sur appInfoLocalizations et appStoreVersionLocalizations, et le circuit de réservation des captures (réserver, envoyer les octets, valider, suivre l'état de livraison). Contrôle total, et tous les pièges ci-dessus sont pour vous.

3. EAS Metadata

Si vous utilisez Expo, eas metadata:push envoie la fiche App Store depuis store.config.json. Expo le classe en bêta ; il ne gère pas Google Play et ne peut pas envoyer de captures.

4. Un outil avec une interface

OneStore modifie les fiches App Store et Google Play dans un seul formulaire, toutes langues, avec les limites de chaque store vérifiées pendant la saisie, puis pousse les deux. Il écrit chaque champ sur la bonne ressource Apple, aplatit la transparence des captures avant l'envoi, redimensionne une capture HD à toutes les tailles exigées, et vérifie la version avant la soumission (build, captures, conformité export, classification d'âge, nouveautés dans chaque langue). Ni Ruby, ni dossier de métadonnées.

Quand garder deliver

Si votre fiche vit déjà dans Git, que vos releases sont entièrement scriptées en CI et que quelqu'un maintient le Fastfile, deliver reste un bon outil. Si la fiche est modifiée par des gens qui n'ouvrent pas de terminal, ou si vous publiez aussi sur Google Play et voulez les deux stores côte à côte, une interface commune évite les allers-retours.

À lire aussi : fastlane vs EAS Submit, les erreurs d'envoi App Store Connect et leurs corrections, métadonnées App Store Connect vs Google Play.

Questions fréquentes