Local App Store Asset Pipeline: Compress → Remove BG → Device Mockup

Why stitch compress → cutout → mockup into one pipeline

Indie listing work rarely fails because you "cannot design." It fails because the same PNG is rejected by different rules on different stores: OPPO portrait shots often must stay under 1MB, Play Feature Graphic is locked at 1024×500, and App Store 6.9" assets need exact pixels with no alpha. Add a messy desk background you want to cut out, and you start bouncing originals across five upload sites.

My pipeline does only three jobs, always in this order:

1. Lock size and weight first — wrong pixels make every later cutout or frame wasted work.
2. Remove background only when needed — skip it for clean UI captures; use it for desks and handheld photos.
3. Frame last — the device chrome is presentation, not a volume-fix.

Compression and background removal can stay in the browser without uploading originals; framing and canvas export use the on-site preview tools. What follows is the decision trail I use on real ship weeks—not another generic encyclopedia page.

Specs you can verify (console wins over any article)

Numbers below track the on-site screenshot size lookup (last checked note on that page: 2026-10-15) plus common store rules. Live console validation always wins.

If you already have a file and wonder which store will take it, paste width/height into the lookup reverse search instead of guessing from memory.

Decision notes: why A beats B

Compress: convert first, or mash the quality slider?

• Choose A (default): pixels already match the store → if PNG is clearly over 1MB (classic OPPO) → convert to JPG → then compress until type is sharp at store-thumbnail scale.
• Skip B: recompressing an already-soft JPG. Second-pass JPEG eats caption edges; thumbnails look worse.
• Skip C: shrinking the canvas to 720px wide "so it fits under 1MB." Weight drops, pixel requirements fail—you fixed nothing.

Hands-on feel: a clean 1080×1920 UI shot as sensible-quality JPG usually lands under 1MB; the same art as PNG with gradients and shadows often does not. That is a format problem, not a "weak compressor" problem.

Cutout: solid-color threshold or AI?

The on-site background remover keeps both modes local: originals do not need to upload. Default order: crop to the device outline → solid-color if the backdrop is flat → AI only if residue remains → export transparent PNG and zoom 200% for fringes and continuous corners.

Mockup: when does a device frame help?

• Press kits / marketing site / social: a frame sells "this is a real phone running the app."
• Play Feature Graphic: follow preview-asset guidance and avoid device images—build the 1024×500 separately, unframed.
• App Store stills: frames are a design choice, not a hard requirement; exact pixels and no alpha are the hard gates.
• Wear OS and similar exceptions: when frames are disallowed, ship full-bleed UI.

Step three is therefore "frame per channel," not "stamp every asset with the same iPhone bezel."

Run the three steps

Step 1 — Match pixels, then compress

1. Open the screenshot size lookup, tick the stores you ship this week, and copy target pixels and counts.
2. In preview / mockup export, pick the preset (Android 1080×1920, iPhone 6.9", etc.), sequence 3–5 story frames, export.
3. If a store caps weight (OPPO under 1MB is the usual trap), drop overweight files into image compress. Still over? Convert to JPG, then compress one more notch.
4. Confirm in Finder/Explorer properties: width and height unchanged; only bytes moved.

Step 2 — Cut out only when the backdrop is noise

1. Open remove background and pick a local file.
2. Prefer solid-color when it cleans; run AI only for residue; always inspect edges.
3. Keep transparent PNG for compositing onto brand color or a device frame. Final App Store uploads should not keep an alpha channel—flatten onto an opaque canvas before you ship.

Step 3 — Frame or go full-bleed, then export

1. Return to preview (or the home screenshot workspace), drop the cleaned screen into a device frame—or keep full-bleed.
2. Build Play Feature Graphic alone at 1024×500, no phone chrome.
3. iOS batch: 6.9" plus the required 6.3" set. Android batch: reuse 1080×1920 layout across stores, then branch on weight and format.

One brand mention is enough: this local toolbox ships as AppShot Maker; everywhere else, deep-link the concrete tool paths.

Pre-upload checklist

• Pixels match the target store row (lookup tool or file properties—not "looks about right")
• OPPO-class under-1MB files pass; prefer JPG + gentle compress over shrinking the canvas
• App Store finals have no alpha; Play Feature Graphic is 1024×500 without stale device art
• Cutout edges pass a 200% zoom; continuous corners were not squared into a fake phone
• Filenames carry platform and index (oppo_01.jpg, ios69_01.png) so locales do not overwrite each other
• Copy layer stays separate from UI: swap locale text without rebuilding the frame and backdrop

When to skip a step on purpose

• Simulator UI already on a designed solid: skip cutout; only size + compress if needed.
• Copy refresh, UI unchanged: reuse frame and backdrop; swap the screen layer only.
• Category or form factor bans frames: step three becomes full-bleed—do not "pretty" your way into a policy hit.

Once this pipeline is on your release checklist, a multi-store week collapses to "tick stores → export → weight branch." Keep the toolbelt short: compress, remove-bg, format convert, size lookup, and preview export. Specs live on the lookup table; pixels leave through the preview canvas.