AppWispr

Find what to build

The Build‑Ready Creative Kit: One Folder Every Founder Must Deliver for Screenshots, Preview Videos & Ads

AW

Written by AppWispr editorial

Return to blog
L
AS
AW

THE BUILD‑READY CREATIVE KIT: ONE FOLDER EVERY FOUNDER MUST DELIVER FOR SCREENSHOTS, PREVIEW VIDEOS & ADS

LaunchApril 24, 20266 min read1,116 words

Ship day stalls almost always trace back to one missing file in a folder: a screenshot at the wrong size, a preview video that fails App Store validation, or ad creative without a safe-zone crop. This post gives founders and indie makers a single, actionable build-ready creative kit they can hand to developers and publishers. You’ll get: an exact asset checklist, recommended filenames and variant rules, developer-friendly export presets for images and video, and a short QA checklist so assets don’t block your next release. Use this as a template inside your repo or release checklist (AppWispr teams use the same structure when prepping launches).

build-ready creative kit folder assets screenshots preview videos ads foundersapp store screenshotsapp preview video specsad asset presetsdeveloper export presets

Section 1

What the build-ready creative kit is — and why a single folder matters

Link section

Treat creative assets like code: one canonical folder, clear filenames, and machine-friendly exports. That prevents last-minute back-and-forths with engineers and avoids re-encoding errors in App Store Connect and Play Console that routinely delay releases.

A good kit contains three families: store screenshots (per device/locale), store preview videos (Apple App Preview + Play promo), and ad-ready variants (feed, tall, and story sizes). Each family should include a poster/frame, captions (text), and layered source files so fixes don’t require a full re-export.

  • One folder = single source of truth for the release pipeline
  • Include source layers (Figma/Ps), exported variants, and an index.json manifest
  • Organize by family → device/placement → locale

Section 2

Exact checklist: files, sizes, and filenames to include

Link section

Below is the minimum deliverable set for a mobile app launch. Keep the manifest at /manifest.json (example fields below) and name files exactly—engineers and automation expect consistent patterns.

Files to include per locale (en-US, fr-FR, etc.): screenshots, preview videos, poster frames, and ad variants. Follow the device dimension requirements for App Store (Apple) and Play Console (Google) when selecting sizes; upload errors are commonly caused by wrong pixel dimensions or codecs.

  • manifest.json — keys: locale, device_set, screenshot_files[], preview_files[], poster_frame, captions.md
  • screenshots/iphone-6.7-1_en-US@3x.jpg (JPEG, sRGB, 72–150 dpi)
  • screenshots/iphone-6.7-2_en-US@3x.jpg … up to 5 per device
  • screenshots/ipad-12.9-1_en-US.png (PNG if UI needs sharp edges)
  • previews/iphone-6.7-preview-01_en-US.mp4 (H.264, 30fps, stereo AAC, 15–30s) — Apple App Preview spec.
  • previews/play-promo-01_en-US.mp4 (MP4, 16:9 or feature-graphic-linked) — Google Play promo video optional but recommended. (See Play Console help.)

Section 3

Developer-friendly export presets (image & video) you should commit

Link section

Commit preset exports so designers and engineers always produce identical outputs. Use these exact encoder settings when exporting JPG/PNG from Figma or Photoshop and MP4 from Premiere/FFmpeg. That removes subtle encoding differences that break App Store uploads.

Save these as named presets in your tooling (Photoshop Export Preset, Figma export guide, or an ffmpeg script). Include sample shell commands in /scripts/export-presets.sh so CI can regenerate assets when needed.

  • Image preset — JPG baseline: sRGB, quality 88, max dimension set to exact pixel size (no scaling in App Store Connect). Filename suffixes: @3x for large-class devices, @2x for smaller ones.
  • PNG preset — export only for graphics with transparency. Use PNG-24, sRGB.
  • Video preset (ffmpeg) — H.264 baseline/main, constant frame rate 30.00 fps, AAC stereo 128–256 kbps, mp4 container. Example: ffmpeg -i source.mov -r 30 -c:v libx264 -profile:v high -preset slow -crf 18 -c:a aac -b:a 192k -ac 2 output.mp4
  • Poster frame — export a 1920×1080 JPEG (or exact device poster dimension if required) named preview-poster_en-US.jpg for upload and fallback display.

Section 4

Ad variants: which aspect ratios to export and how to name them

Link section

Ad platforms (Meta/Facebook, Instagram) display creative in multiple placements; upload flexible variants to let the ad system optimize placement. Create three core crops from your hero screenshot or scene: square (1:1), tall feed (4:5), and vertical (9:16) for stories/reels.

Name ad files with the campaign-friendly pattern so marketers can script uploads: ads/{campaignCode}_hero_1x1_v1.jpg, ads/{campaignCode}_hero_4x5_v1.jpg, ads/{campaignCode}_hero_9x16_v1.mp4. Include a captions.csv with ad primary text and call-to-action so a simple script can create ad sets.

  • 1:1 — 1080×1080 JPG, primary feed and cross-placement
  • 4:5 — 1080×1350 JPG (or PNG for UI-heavy), better vertical real estate in feeds
  • 9:16 — 1080×1920 MP4 for Stories/Reels (keep safe-zone: center 4:5 area for primary text)
  • Include thumbnails: ads/{campaign}_thumb_1x1.jpg for platform uploader fallbacks

Section 5

Quick QA checklist (run these before handing the folder to devs or publishers)

Link section

Run this checklist as part of your release train. It’s short but catches the common blocking issues: wrong pixel sizes, missing stereo audio, incorrect filename casing, and missing locales. Automate as many checks as you can—AppWispr recommends a small preflight script that validates manifest.json and checks file dimension metadata.

If anything fails, regenerate from source layers and re-run export-presets.sh. Don’t re-encode from exported JPEGs; always keep original layered files for fixes.

  • Dimension check: every image matches the pixel dimensions in manifest.json and Apple/Google specs.
  • Filename & casing: exact match to manifest (App Store and CI are case-sensitive on some tooling).
  • Video validation: MP4 container, H.264, 30 fps constant, stereo AAC (not mono), length between 15–30s for Apple app previews.
  • Locale coverage: at least the store default locale; extras only if translated assets exist.
  • Poster & thumbnail present for each preview video.

FAQ

Common follow-up questions

Do I need separate screenshots for every device size?

Apple requires screenshots for the primary display classes you support (for iPhone, a 6.7-inch class screenshot is typically required and Apple will scale where supported). If your UI scales cleanly, provide the largest required size per device class and upload locale-specific sets only when translations change visual copy. Google Play is more forgiving but you should still add phone and tablet screenshots for best coverage. (See Apple and Google docs for exact device classes.)

What’s the single most common reason preview videos are rejected?

For App Store previews, mismatched resolution or frame rate is the top cause—Apple expects exact device-frame dimensions, a constant 30 fps, and a stereo audio track even when the clip is silent. Use the export video preset and validate with ffmpeg or QuickTime before upload.

Should ad creatives include text in the image?

Avoid putting essential copy too close to the edges and keep the primary message inside a center safe area so different aspect crops remain readable. Platforms like Meta are less strict about text overlay quantity than they once were, but keeping key text in the center 80% of the canvas reduces cropping issues across placements.

How do I store the kit in version control without bloating the repo?

Keep layered source files and a small manifest in the repo. Store high-resolution exported binaries in an assets CDN or release bucket and reference them by path in manifest.json. Add an export script so CI can re-create exports from the source files when needed.

Sources

Research used in this article

Each generated article keeps its own linked source list so the underlying reporting is visible and easy to verify.

Next step

Turn the idea into a build-ready plan.

AppWispr takes the research and packages it into a product brief, mockups, screenshots, and launch copy you can use right away.