App Store Screenshots

App Store Screenshots Generator

Overview

Build a Next.js page that renders iOS App Store screenshots as advertisements (not UI showcases) and exports them via html-to-image at Apple's required resolutions. Screenshots are the single most important conversion asset on the App Store.

Core Principle

Screenshots are advertisements, not documentation. Every screenshot sells one idea. If you're showing UI, you're doing it wrong — you're selling a feeling, an outcome, or killing a pain point.

Step 1: Ask the User These Questions

Before writing ANY code, ask the user all of these. Do not proceed until you have answers:

Required

1. App screenshots — "Where are your app screenshots? (PNG files of actual device captures)"
2. App icon — "Where is your app icon PNG?"
3. Brand colors — "What are your brand colors? (accent color, text color, background preference)"
4. Font — "What font does your app use? (or what font do you want for the screenshots?)"
5. Feature list — "List your app's features in priority order. What's the #1 thing your app does?"
6. Number of slides — "How many screenshots do you want? (Apple allows up to 10)"
7. Style direction — "What style do you want? Examples: warm/organic, dark/moody, clean/minimal, bold/colorful, gradient-heavy, flat. Share App Store screenshot references if you have any."

Optional

8. iPad screenshots — "Do you also have iPad screenshots? If so, we'll generate iPad App Store screenshots too (recommended for universal apps)."
9. Component assets — "Do you have any UI element PNGs (cards, widgets, etc.) you want as floating decorations? If not, that's fine — we'll skip them."
10. Localized screenshots — "Do you want screenshots in multiple languages? This helps your listing rank in regional App Stores even if your app is English-only. If yes: which languages? (e.g. en, de, es, pt, ja, ar, he)"
11. Theme preset system — "Do you want one art direction, or reusable visual themes (for example: clean-light, dark-bold, warm-editorial) so you can swap screenshot looks quickly?"
12. Additional instructions — "Any specific requirements, constraints, or preferences?"

Derived from answers (do NOT ask — decide yourself)

Based on the user's style direction, brand colors, and app aesthetic, decide:

• Background style: gradient direction, colors, whether light or dark base
• Decorative elements: blobs, glows, geometric shapes, or none — match the style
• Dark vs light slides: how many of each, which features suit dark treatment
• Typography treatment: weight, tracking, line height — match the brand personality
• Color palette: derive text colors, secondary colors, shadow tints from the brand colors
• Theme preset names: turn vague style requests into reusable theme ids the user can switch between
• RTL behavior: if any locale is RTL (ar, he, fa, ur), mirror layout intentionally instead of just translating the text

IMPORTANT: If the user gives additional instructions at any point during the process, follow them. User instructions always override skill defaults.

Step 2: Set Up the Project

Detect Package Manager

Check what's available, use this priority: bun > pnpm > yarn > npm

# Check in order
which bun && echo "use bun" || which pnpm && echo "use pnpm" || which yarn && echo "use yarn" || echo "use npm"

Scaffold (if no existing Next.js project)

# With bun:
bunx create-next-app@latest . --typescript --tailwind --app --src-dir --no-eslint --import-alias "@/*"
bun add html-to-image

# With pnpm:
pnpx create-next-app@latest . --typescript --tailwind --app --src-dir --no-eslint --import-alias "@/*"
pnpm add html-to-image

# With yarn:
yarn create next-app . --typescript --tailwind --app --src-dir --no-eslint --import-alias "@/*"
yarn add html-to-image

# With npm:
npx create-next-app@latest . --typescript --tailwind --app --src-dir --no-eslint --import-alias "@/*"
npm install html-to-image

Copy the Phone Mockup

The skill includes a pre-measured iPhone mockup at mockup.png (co-located with this SKILL.md). Copy it to the project's public/ directory. The mockup file is in the same directory as this skill file. No iPad mockup is needed — the iPad frame is CSS-only.

File Structure

project/
├── public/
│   ├── mockup.png              # iPhone frame (included with skill)
│   ├── app-icon.png            # User's app icon
│   ├── screenshots/            # iPhone app screenshots
│   │   ├── home.png
│   │   ├── feature-1.png
│   │   └── ...
│   └── screenshots-ipad/       # iPad app screenshots (optional)
│       ├── home.png
│       ├── feature-1.png
│       └── ...
├── src/app/
│   ├── layout.tsx              # Font setup
│   └── page.tsx                # The screenshot generator (single file)
└── package.json

Note: No iPad mockup PNG is needed — the iPad frame is rendered with CSS (see iPad Mockup Component below).

Multi-language: nest screenshots under a locale folder per language. The generator switches the base path; all slide image srcs stay identical.

└── screenshots/
    ├── en/
    │   ├── home.png
    │   ├── feature-1.png
    │   └── ...
    ├── de/
    │   └── ...
    └── {locale}/

If iPad screenshots are localized too, mirror the same locale structure:

└── screenshots-ipad/
    ├── en/
    ├── de/
    └── {locale}/

The entire generator is a single page.tsx file. No routing, no extra layouts, no API routes.

Multi-language: Locale Tabs

Add a LOCALES array and locale tabs to the toolbar. Every slide src uses base — no hardcoded paths:

const LOCALES = ["en", "de", "es"] as const; // use whatever langs were defined
type Locale = typeof LOCALES[number];

// In ScreenshotsPage:
const [locale, setLocale] = useState<Locale>("en");
const base = `/screenshots/${locale}`;

// Toolbar tabs:
{LOCALES.map(l => (
  <button key={l} onClick={() => setLocale(l)}
    style={{ fontWeight: locale === l ? 700 : 400 }}>
    {l.toUpperCase()}
  </button>
))}

// In every slide — unchanged between single and multi-language:
<Phone src={`${base}/home.png`} alt="Home" />

Theme Presets + Locale Metadata

Add a small config layer so the user can switch theme and locale without rewriting slide components:

const LOCALES = ["en", "de", "ar"] as const;
type Locale = typeof LOCALES[number];

const RTL_LOCALES = new Set<Locale>(["ar"]);

const THEMES = {
  "clean-light": {
    bg: "#F6F1EA",
    fg: "#171717",
    accent: "#5B7CFA",
    muted: "#6B7280",
  },
  "dark-bold": {
    bg: "#0B1020",
    fg: "#F8FAFC",
    accent: "#8B5CF6",
    muted: "#94A3B8",
  },
  "warm-editorial": {
    bg: "#F7E8DA",
    fg: "#2B1D17",
    accent: "#D97706",
    muted: "#7C5A47",
  },
} as const;

type ThemeId = keyof typeof THEMES;

const COPY_BY_LOCALE = {
  en: { hero: "Build better habits" },
  de: { hero: "Baue bessere Gewohnheiten auf" },
  ar: { hero: "ابنِ عادات أفضل" },
} satisfies Record<Locale, { hero: string }>;

const [themeId, setThemeId] = useState<ThemeId>("clean-light");
const [locale, setLocale] = useState<Locale>("en");

const theme = THEMES[themeId];
const copy = COPY_BY_LOCALE[locale];
const isRtl = RTL_LOCALES.has(locale);

Use theme tokens everywhere instead of hardcoding colors. For RTL locales, set dir={isRtl ? "rtl" : "ltr"} on the screenshot canvas and mirror asymmetric layouts intentionally.

Support query params for automation:

// ?locale=de&theme=dark-bold&device=ipad

Font Setup

// src/app/layout.tsx
import { YourFont } from "next/font/google"; // Use whatever font the user specified
const font = YourFont({ subsets: ["latin"] });

export default function Layout({ children }: { children: React.ReactNode }) {
  return <html><body className={font.className}>{children}</body></html>;
}

Step 3: Plan the Slides

Screenshot Framework (Narrative Arc)

Adapt this framework to the user's requested slide count. Not all slots are required — pick what fits:

Rules:

• Each slide sells ONE idea. Never two features on one slide.
• Vary layouts across slides — never repeat the same template structure.
• Include 1-2 contrast slides (inverted bg) for visual rhythm.

Step 4: Write Copy FIRST

Get all headlines approved before building layouts. Bad copy ruins good design.

The Iron Rules

1. One idea per headline. Never join two things with "and."
2. Short, common words. 1-2 syllables. No jargon unless it's domain-specific.
3. 3-5 words per line. Must be readable at thumbnail size in the App Store.
4. Line breaks are intentional. Control where lines break with <br />.

Three Approaches (pick one per slide)

What NEVER Works

• Feature lists as headlines: "Log every item with tags, categories, and notes"
• Two ideas joined by "and": "Track X and never miss Y"
• Compound clauses: "Save and customize X for every Y you own"
• Vague aspirational: "Every item, tracked"
• Marketing buzzwords: "AI-powered tips" (unless it's actually AI)

Bad-to-Better Headline Examples

Use these patterns to rewrite weak copy before building any layout:

Copy Process

1. Write 3 options per slide using the three approaches
2. Read each at arm's length — if you can't parse it in 1 second, it's too complex
3. Check: does each line have 3-5 words? If not, adjust line breaks
4. Present options to the user with reasoning for each

Example Prompt Shapes

If the user gives a weak or underspecified request, reshape it internally into something like:

Build App Store screenshots for my habit tracker.
The app helps people stay consistent with simple daily routines.
I want 6 slides, clean/minimal style, warm neutrals, and a calm premium feel.

Generate App Store screenshots for my personal finance app.
The app's main strengths are fast expense capture, clear monthly trends, and shared budgets.
I want a sharp, modern style with high contrast and 7 slides.

Create exportable App Store screenshots for my AI note-taking app.
The core value is turning messy voice notes into clean summaries and action items.
I want bold copy, dark backgrounds, and a polished tech-forward look.

The pattern is:

1. app category + core outcome
2. top features in priority order
3. desired slide count
4. style direction

Localization Rules

• Do not literally translate headlines if the result becomes long or awkward.
• Re-write copy for the target market while keeping the same selling idea.
• Re-check line breaks per locale; German, French, and Portuguese often need shorter claims.
• For RTL languages, also reverse badge alignment, supporting decorations, and phone offsets when the composition depends on left/right weight.

Reference Apps for Copy Style

• Raycast — specific, descriptive, one concrete value per slide
• Turf — ultra-simple action verbs, conversational
• Mela / Notion — warm, minimal, elegant

Step 5: Build the Page

Architecture

page.tsx
├── Constants (IPHONE_W/H, IPAD_W/H, SIZES, design tokens)
├── LOCALES / RTL_LOCALES / THEMES / COPY_BY_LOCALE
├── Phone component (mockup PNG with screen overlay)
├── IPad component (CSS-only frame with screen overlay)
├── Caption component (label + headline, accepts canvasW for scaling)
├── Decorative components (blobs, glows, shapes — based on style direction)
├── iPhoneSlide1..N components (one per slide)
├── iPadSlide1..N components (same designs, adjusted for iPad proportions)
├── IPHONE_SCREENSHOTS / IPAD_SCREENSHOTS arrays (registries)
├── ScreenshotPreview (ResizeObserver scaling + hover export)
└── ScreenshotsPage (grid + locale tabs + theme tabs + device toggle + export logic)

Export Sizes (Apple Required, portrait)

iPhone

const IPHONE_SIZES = [
  { label: '6.9"', w: 1320, h: 2868 },
  { label: '6.5"', w: 1284, h: 2778 },
  { label: '6.3"', w: 1206, h: 2622 },
  { label: '6.1"', w: 1125, h: 2436 },
] as const;

Design at the LARGEST size (1320x2868) and scale down for export.

iPad (Optional)

If the user provides iPad screenshots, also generate iPad App Store screenshots:

const IPAD_SIZES = [
  { label: '13" iPad', w: 2064, h: 2752 },
  { label: '12.9" iPad Pro', w: 2048, h: 2732 },
] as const;

Design iPad slides at 2064x2752 and scale down. iPad screenshots are optional but recommended — they're required for iPad-only apps and improve listing quality for universal apps.