Automatiser vos captures d’écran avec fastlane snapshot et frameit

fastlane automatise les captures d’écran pour les stores en trois étapes. snapshot (iOS) et screengrab (Android) exécutent vos tests d’interface sur des simulateurs ou des émulateurs, dans chaque langue que vous listez, et enregistrent une capture à chaque endroit que vous marquez. frameit les entoure d’un cadre d’appareil, d’un fond et d’un titre. deliver et supply envoient le résultat sur App Store Connect et Google Play. Une fois tout en place, régénérer toutes les captures ne demande qu’une commande.

Cette dernière phrase résume tout l’intérêt, et la configuration résume tout le coût. Ce guide passe en revue chaque brique avec une config qui fonctionne, puis donne un avis honnête sur les cas où ça vaut le coup.

Comment fonctionne fastlane snapshot

fastlane snapshot s’appuie sur les tests d’interface de Xcode. Vous écrivez un test d’interface qui parcourt votre app ; à chaque écran qui mérite d’être montré, il appelle snapshot("01Home"). snapshot exécute ce test une fois par combinaison d’appareil et de langue, et rassemble les images dans fastlane/screenshots/<language>/.

Installation

1. Ajoutez une cible UI Test à votre projet Xcode si vous n’en avez pas.
2. Lancez fastlane snapshot init dans le dossier du projet. La commande crée un Snapfile et un SnapshotHelper.swift.
3. Ajoutez SnapshotHelper.swift à la cible UI Test.

Le test d’interface

import XCTest

final class ScreenshotTests: XCTestCase {
    override func setUp() {
        continueAfterFailure = false
        let app = XCUIApplication()
        setupSnapshot(app)
        app.launchArguments += ["-demoData"]
        app.launch()
    }

    func testStoreScreenshots() {
        let app = XCUIApplication()

        snapshot("01Home")

        app.tabBars.buttons["Budget"].tap()
        snapshot("02Budget")

        app.buttons["Add expense"].tap()
        snapshot("03AddExpense")
    }
}

setupSnapshot(app) transmet la langue et la région en cours à l’app, et c’est comme ça qu’un seul test produit toutes les séries localisées. L’argument -demoData est une convention à nous : l’app le détecte dans les builds de debug et charge du contenu d’exemple, pour qu’aucune capture ne montre un écran vide. Préfixer les noms par des numéros garde les fichiers dans l’ordre d’envoi.

Le Snapfile

# fastlane/Snapfile
devices([
  "iPhone 17 Pro Max",
  "iPad Pro 13-inch (M5)"
])

languages([
  "en-US",
  "de-DE",
  "ja"
])

scheme("MyAppUITests")
output_directory("./fastlane/screenshots")
clear_previous_screenshots(true)

override_status_bar(true)   # 9:41, full battery, full reception
dark_mode(false)
launch_arguments(["-demoData"])

Les noms d’appareils doivent correspondre aux simulateurs installés dans votre Xcode ; xcrun simctl list devicetypes les affiche. Un simulateur iPhone 17 Pro Max capture en 1320 × 2868, l’une des tailles qu’App Store Connect accepte pour son plus grand emplacement iPhone. Lancez ensuite :

fastlane snapshot

D’autres options de snapshot à connaître : localize_simulator règle aussi la langue système du simulateur, erase_simulator repart d’un appareil vierge à chaque exécution, reinstall_app désinstalle l’app au préalable, et override_status_bar_arguments accepte vos propres options simctl status_bar. Si vous voulez savoir ce que font ces options, notre guide des captures propres sur simulateur et émulateur les détaille, ainsi que les commandes manuelles que snapshot automatise.

screengrab : l’équivalent Android

screengrab fait le même travail avec les tests d’instrumentation Android. Ajoutez la bibliothèque à vos dépendances de test :

// app/build.gradle
androidTestImplementation 'tools.fastlane:screengrab:x.x.x'

Vérifiez que src/debug/AndroidManifest.xml inclut les autorisations listées dans la doc (comme DISABLE_KEYGUARD), puis écrivez le test :

@RunWith(AndroidJUnit4.class)
public class ScreenshotTest {
    @ClassRule
    public static final LocaleTestRule localeTestRule = new LocaleTestRule();

    @BeforeClass
    public static void beforeAll() {
        CleanStatusBar.enableWithDefaults();
    }

    @AfterClass
    public static void afterAll() {
        CleanStatusBar.disable();
    }

    @Rule
    public ActivityScenarioRule<MainActivity> rule =
        new ActivityScenarioRule<>(MainActivity.class);

    @Test
    public void storeScreenshots() {
        Screengrab.screenshot("01_home");
        onView(withId(R.id.nav_budget)).perform(click());
        Screengrab.screenshot("02_budget");
    }
}

LocaleTestRule change de langue à chaque exécution, et CleanStatusBar est une surcouche du mode démo de l’interface système d’Android ; la doc précise qu’il faut l’API 23 ou plus. Compilez les APK, générez un Screengrabfile, puis lancez-le :

./gradlew assembleDebug assembleAndroidTest
fastlane screengrab init     # creates the Screengrabfile
fastlane screengrab

# fastlane/Screengrabfile
app_package_name("com.example.app")
app_apk_path("app/build/outputs/apk/debug/app-debug.apk")
tests_apk_path("app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk")
locales(["en-US", "de-DE", "ja-JP"])
clear_previous_screenshots(true)

Par défaut, les captures vont dans fastlane/metadata/android/<locale>/images/phoneScreenshots, c’est-à-dire exactement là où supply va les chercher. Un point à vérifier sur Android : Google Play refuse les captures dont le grand côté dépasse le double du petit, donc choisissez un profil d’émulateur qui ne soit pas plus allongé que 2:1.

frameit : cadres d’appareil et titres

frameit prend les captures brutes et les place dans des cadres d’appareil. Il a besoin d’ImageMagick (brew install imagemagick). Les cadres se téléchargent automatiquement au premier lancement.

fastlane frameit            # iOS and Mac screenshots
fastlane frameit android    # Android screenshots
fastlane frameit silver     # silver frame variants

Un cadre d’appareil seul ne rend pas automatiquement l’image prête pour l’App Store : l’image encadrée peut ne correspondre à aucune taille acceptée par App Store Connect. La doc de fastlane indique que pour l’App Store, il vous faut un Framefile.json avec titres et fond, qui produit à la place une image marketing complète.

Framefile.json

Placez-le dans le dossier screenshots :

{
  "device_frame_version": "latest",
  "default": {
    "title": {
      "font": "./fonts/Inter-Bold.ttf",
      "font_size": 110,
      "color": "#0F172A"
    },
    "keyword": {
      "font": "./fonts/Inter-Bold.ttf",
      "color": "#F97316"
    },
    "background": "./background.jpg",
    "padding": 50,
    "show_complete_frame": false,
    "title_below_image": false
  },
  "data": [
    { "filter": "01Home" },
    { "filter": "02Budget", "keyword": { "color": "#3B82F6" } },
    { "filter": "03AddExpense" }
  ]
}

Chaque entrée de data s’applique aux captures dont le nom de fichier contient son filter, et peut remplacer les valeurs par défaut. Le texte lui-même se trouve dans des fichiers par langue, title.strings et éventuellement keyword.strings, dans chaque dossier de langue :

"01Home" = "See every euro, every month";
"02Budget" = "Budgets that adjust themselves";
"03AddExpense" = "Log a purchase in two taps";

Cette ligne vide au début est volontaire : la doc indique que le fichier doit commencer par une ligne vide, et être encodé en UTF-8 ou en UTF-16 BE avec BOM. Elle précise aussi qu’il faut fournir un fond si vous voulez des titres. Si les titres n’apparaissent pas, vérifiez d’abord ces trois points.

Les cadres d’appareil de frameit sont en retard sur le matériel

Les cadres de frameit proviennent du dépôt séparé frameit-frames, et ils sont ajoutés après la sortie des appareils. Quand nous avons regardé en octobre 2026 :

En pratique, si vous capturez sur le simulateur le plus récent, il n’existe peut-être aucun cadre pour lui. Vos options : capturer sur un appareil qui a un cadre (en acceptant que la taille de son écran ne corresponde pas forcément à l’emplacement du store que vous visez), forcer un type d’appareil avec force_device_type, ou vous passer de cadres et utiliser une mise en page plein cadre.

Envoyer avec deliver et supply

# iOS: upload only screenshots, replacing what's there
fastlane deliver --skip_binary_upload --skip_metadata --overwrite_screenshots

# Android: upload only images and screenshots
fastlane supply --skip_upload_apk --skip_upload_aab \
  --skip_upload_metadata --skip_upload_changelogs

deliver lit fastlane/screenshots, avec un sous-dossier par langue, et déduit le type d’appareil de la résolution de chaque image : chaque fichier doit donc avoir une taille acceptée avant l’envoi. supply lit fastlane/metadata/android/<locale>/images/, avec les dossiers phoneScreenshots, sevenInchScreenshots et tenInchScreenshots. Enchaînés dans une lane, la capture et l’envoi tiennent en une seule commande :

lane :screenshots do
  snapshot
  frameit(white: true)
  deliver(skip_binary_upload: true, skip_metadata: true,
          overwrite_screenshots: true)
end

Si vous n’utilisez pas fastlane mais voulez quand même éviter l’envoi manuel, nous avons écrit sur l’envoi direct sur les stores depuis un outil de design.

Les accrocs à prévoir

Aucun de ces points n’est une raison de renoncer à fastlane, mais chacun vous coûtera du temps la première semaine si vous ne vous y attendez pas.

Les tests de captures sont lents, gardez-les à part

Une exécution, c’est à peu près chaque écran, multiplié par chaque appareil, multiplié par chaque langue. Trois appareils et dix langues, ce sont trente passages dans votre test. Gardez les tests de captures dans leur propre scheme ou test plan pour qu’ils ne tournent pas avec chaque test unitaire, et déclenchez-les sur les branches de release ou à la main plutôt qu’à chaque commit.

Attendez le contenu, pas une durée

Une cause fréquente de capture ratée, c’est de capturer un instant trop tôt : un indicateur de chargement, une image à moitié chargée, une liste encore en pleine animation. Dans les tests d’interface, attendez qu’un élément précis existe (waitForExistence(timeout:) sur iOS, une idling resource Espresso ou une attente UI Automator sur Android) avant d’appeler snapshot. Les pauses fixes marchent sur votre machine et échouent sur un runner de CI plus lent.

Rendez les données de démo déterministes

Si la capture affiche des dates, « il y a 3 jours » change tous les jours et les totaux dérivent quand les fixtures changent. Figez l’horloge dans votre mode données de démo, utilisez des fixtures fixes, et les captures ne changeront que quand l’interface changera. Ça rend aussi le résultat comparable en revue de code, ce qui est l’un des vrais avantages de garder ses captures sous contrôle de version.

Une interface traduite n’est que la moitié d’une capture localisée

snapshot vous donne gratuitement l’interface de l’app dans chaque langue. Les titres de title.strings restent à écrire pour chaque langue, et la traduction littérale d’un titre anglais percutant l’est rarement autant. Notre guide sur la localisation des captures d’écran App Store explique ce qu’il faut adapter au-delà des mots.

La CI a besoin d’un Mac avec les bons simulateurs

snapshot tourne sur macOS avec Xcode, donc la CI implique un runner macOS sur lequel sont installés les runtimes de simulateur que votre Snapfile mentionne. Les noms d’appareils du Snapfile doivent correspondre à des simulateurs présents sur ce runner : figez la version de Xcode utilisée par votre CI et mettez à jour le Snapfile quand vous passez à une nouvelle.

Quand l’automatisation est rentable, et quand elle ne l’est pas

Nous développons un outil de design, alors gardez ça en tête en nous lisant. Mais fastlane est vraiment la bonne réponse pour certaines équipes.

L’automatisation est généralement rentable quand :

• Vous publiez toutes les quelques semaines et l’interface visible sur vos captures change d’une version à l’autre.
• Vous publiez dans de nombreuses langues, où chaque capture se multiplie par le nombre de langues.
• Vous avez déjà des tests d’interface, ou vous en voulez de toute façon.
• Quelqu’un dans l’équipe est à l’aise pour gérer une chaîne d’outils Ruby et ImageMagick dans la CI.

Elle l’est rarement quand :

• Vous publiez en une ou deux langues et mettez à jour vos captures quelques fois par an.
• Vos captures relèvent du design : mises en page sur mesure, illustrations, série panoramique.
• Vos écrans demandent un état difficile à atteindre depuis un test d’interface (paiements, données en direct, autres utilisateurs).

Beaucoup d’équipes coupent la poire en deux : snapshot pour des captures propres et localisées, et un outil de design pour la couche marketing par-dessus. Notre comparatif Launch Shots vs fastlane frameit détaille cette approche, et si vous hésitez sur un outil de design, notre guide pour créer des captures d’écran App Store dans Figma présente l’alternative manuelle. Launch Shots se range dans le second camp : vous apportez vos captures (y compris celles de snapshot), et il s’occupe de la mise en page, de la traduction et de l’envoi.

En bref

• iOS : cible UI Test, fastlane snapshot init, setupSnapshot(app), snapshot("01Home"), un Snapfile avec appareils, langues et override_status_bar(true).
• Android : tools.fastlane:screengrab, LocaleTestRule, CleanStatusBar, Screengrab.screenshot(), un Screengrabfile.
• frameit : ImageMagick, un Framefile.json avec un fond, un title.strings par langue qui commence par une ligne vide.
• Vérifiez que le dépôt de cadres contient votre appareil de capture avant d’en dépendre.
• deliver et supply se chargent de l’envoi ; vérifiez d’abord que chaque fichier a une taille acceptée. Notre référence des tailles de captures et la checklist ASO de lancement vous aident pour le reste de la fiche.