You Only Need to Capture the 6.9-inch iPhone for App Store Screenshots

Capture the 6.9-inch in one command with fastlane snapshot

I automate capture with fastlane's snapshot. It launches a UI test, calls snapshot(...) on the screens you specify, and grabs a simulator screenshot per language.

First, Snapfile narrows the devices and languages. Writing only the 6.9-inch and 13-inch here is the whole point of this article.

# fastlane/Snapfile
devices([
  "iPhone 17 Pro Max",        # 6.9-inch = the required App Store reference device
  "iPad Pro 13-inch (M4)"     # 13-inch iPad
])
 
languages([
  "en-US",
  "ja",
  "de-DE",
  "fr-FR",
  "zh-Hans"
])
 
scheme("MyAppUITests")
output_directory("./fastlane/screenshots")
clear_previous_screenshots(true)  # wipe stale images on every re-run

Next, the UI test. A testID you set in React Native / Expo becomes the accessibility identifier on iOS, so it works directly in XCUITest element queries. Not knowing this is where people get stuck wondering why an element cannot be found.

// ScreenshotUITests.swift
import XCTest
 
final class ScreenshotUITests: XCTestCase {
  override func setUpWithError() throws {
    continueAfterFailure = false
    let app = XCUIApplication()
    setupSnapshot(app)   // fastlane injects language and output path
    app.launch()
  }
 
  func testCaptureStoreScreens() throws {
    let app = XCUIApplication()
 
    // Home right after launch. Wait for load before shooting.
    XCTAssertTrue(app.otherElements["homeScreen"].waitForExistence(timeout: 10))
    snapshot("01_Home")
 
    // testID="browseTab" becomes the iOS accessibility identifier
    app.buttons["browseTab"].tap()
    snapshot("02_Browse")
 
    app.buttons["settingsTab"].tap()
    snapshot("03_Settings")
  }
}

Finally, tie it together in a lane. capture_screenshots reads the Snapfile; frame_screenshots reads the frameit config below.

# fastlane/Fastfile
platform :ios do
  desc "Capture localized store screenshots and composite frames"
  lane :screens do
    capture_screenshots            # shoot device x language from Snapfile
    frame_screenshots(white: true) # composite device frames per Framefile.json
  end
end

Now fastlane screens produces 2 devices x 5 languages x 3 screens = 30 images in one command. Back when I shot each size, the same content meant managing 3 sizes x 5 screens x 16 languages = 240 images by hand. The image count matters, but being freed from manual capture matters more.

Composite device frames and translated captions with frameit

Raw captures look weak if you ship them as-is. frameit places them in a device frame with a translated headline on top, which makes them work as store artwork.

Framefile.json sets one shared style across all languages. Standardizing on a Noto font is the safe move — one font handles Japanese, Chinese, and German umlauts without glyphs falling apart.

{
  "default": {
    "title": { "font": "./fonts/NotoSans-Bold.ttf", "color": "#111827" },
    "keyword": { "font": "./fonts/NotoSans-Bold.ttf", "color": "#2563EB" },
    "background": "./bg/soft-gradient.png",
    "padding": 48,
    "show_complete_frame": false,
    "title_below_image": false
  },
  "data": [
    { "filter": "01_Home", "keyword": { "color": "#7C3AED" } }
  ]
}

For caption text, place title.strings and keyword.strings in the same language folder as the images, and frameit swaps them per language.

# fastlane/screenshots/en-US/title.strings
"01_Home" = "A different view every morning";
"02_Browse" = "Today's pick from 5,000 images";
"03_Settings" = "Quiet, and ad-free";

Preparing copy per language is work, but I would not ship raw machine translation here. A screenshot headline lands differently depending on how it reads in that language. I touched on this in what I learned running App Store localization for wallpaper apps across languages.

How far you can cut the language x device count

Here is where I draw the line between "safe to drop" and "do not drop," as an operational decision.

Across my wallpaper apps, this cut the images per app from 240 to 80 (6.9-inch only, 5 screens, 16 languages) — about a 66% reduction. Running several apps in parallel as an indie developer, stopping that double payment adds up quietly. An app without iPad support drops the entire iPad set on top of that. The easy thing to miss is that language is not droppable: you can leave devices to the downscaler, but trimming listing languages means the fallback (usually English) shows in the unspecified slots, and local readers reliably lose interest.

What changes between Rork Max (SwiftUI) and Rork (Expo)

Even with the same "capture at 6.9-inch," how you attach the UI test differs by generation base.

For Rork (React Native / Expo), run npx expo prebuild to generate the ios/ project, then add a UI test target in Xcode. Element targeting uses the testID-derived accessibility identifier described above. Since preview and production builds can diverge, the angle in fixing preview-vs-device inconsistencies in Rork Max applies directly.

For Rork Max (native SwiftUI), it is an Xcode project from the start, so adding a UI test target is straightforward. Set .accessibilityIdentifier("browseTab") explicitly on SwiftUI views so XCUITest can grab them reliably. Generated views often carry no identifier, so adding them only to the elements you capture is the practical route.

Either way, the exit — the two-size App Store Connect spec — is shared. The convergence point does not change with the tool.

Pitfalls that are easy to hit

Three non-obvious traps I stepped in, with the fix for each. Walk them in order and most generation mishaps are avoided.

1. If you call snapshot(...) before the screen finishes rendering, you capture a loading skeleton or splash. Wrapping waitForExistence(timeout:) around it, as in the code above, is the fix. For image-heavy apps especially, shooting without waiting gives you sad store artwork full of empty grids.

2. Missing per-language font embedding. Leave frameit's font as a Latin-only face and Japanese or Chinese captions render as tofu (□) boxes. Specifying one font with broad coverage like Noto Sans CJK and running every language through it was the reliable workaround.

3. Reusing images captured from a preview build directly in production listings. Fonts and padding can diverge between preview and production, and noticing after the listing is live means rework. Capture on a simulator with the same build configuration you ship.

If you are tired of re-shooting screenshots, start by rewriting your app's Snapfile to the single 6.9-inch iPhone line and running fastlane screens once. You will likely find the range you can leave to the downscaler is wider than you expected.

I have come to see store presentation as something you keep adjusting after release. I am still searching for the best composition myself, but automating away the capture effort let me pour that time back into sharpening the copy instead. Thank you for reading.