DEV Community: Salim

From Idea to App Store Screenshots Without a Designer

Salim — Wed, 17 Jun 2026 08:03:49 +0000

You built the app. It works. Then you open App Store Connect and it asks for screenshots, and you realize the thing standing between you and "submit" is a design problem you have no idea how to solve.

I've shipped a bunch of apps solo. The store listing visuals used to be the part I dreaded most. Not the code. The marketing screenshots. The ones with the phone frames and the big "Track everything in one place" headline that every successful app has and yours suddenly needs to compete with. This post is the exact workflow I use to make those without hiring anyone, including where an ASO visuals generator saves you when you don't even have clean design files yet.

No fluff. Just the steps, the store sizes, and the caption rules that actually move installs.

First, what these screenshots actually are

The screenshots on your App Store and Play Store listing are not screen recordings of your app. They are marketing creatives. Usually a phone mockup with the app screen inside it, a short headline on top, a background color, and maybe a little annotation pointing at a feature.

People decide whether to install in about three seconds of scrolling. Your first two screenshots do most of the work. This is the core of ASO (App Store Optimization) on the visual side. The store algorithm cares about keywords and ratings. Humans care about whether your screenshots look like an app they trust.

So the job is: make 4 to 6 of these, make them look like one cohesive app, and get them out at the right pixel sizes for both stores.

The workflow

Here's the loop. Four steps.

1. Get the screens

This is where most guides assume you already have polished design files sitting in Figma. A lot of solo devs don't. You built the app in React Native or SwiftUI, it looks fine on a device, but you have no clean mockup-ready frames.

You've got two honest options:

Use your real app screens. Take clean captures on a simulator at the right resolution. Hide any test data, real names, low battery, weird timestamps. This is free and accurate, but your in-app UI is often denser than what looks good on a store listing.
Generate listing-ready screens. If your real UI is messy, or you're pre-launch and want listing visuals before the app is even done, you generate clean screens that match your brand. This is the part I lean on tools for now. Daisy can generate App Store screenshots straight from your app screens so the visuals look like one app even if your actual codebase is held together with tape. Worth it when you're pre-launch and need the listing to look finished.

Either way, by the end of step one you should have 4 to 6 clean screen images, one per feature you want to sell.

2. Frame them in device mockups

Now you drop each screen into a phone frame. There's a whole category of tools that do just this part well, and they're genuinely good at it: AppLaunchpad, AppMockup, AppScreens, and similar. You upload a screenshot, pick an iPhone or Pixel frame, and it sizes everything for you. Most have free tiers.

The thing to understand is the lane. Those tools take screens you already have and frame them. They don't make the screens. So if you walked out of step one with clean images, a framing tool is all you need here. If you didn't have clean screens to begin with, framing an ugly screenshot in a nice phone just gives you an ugly screenshot in a nice phone.

Tips for this step:

Keep the same frame style across all screenshots. Don't mix a flat iPhone on one and a perspective angle on the next.
Leave breathing room. The phone should not touch the edges.
Pick a background that comes from your app's palette, not a random gradient.

3. Add the headlines and captions

Every screenshot gets a short headline. This is the highest-leverage text on your entire listing.

Caption do's:

Lead with the benefit, not the feature. "Hit your goals without the guesswork" beats "Goal tracking screen."
Keep it to 3 to 5 words. People are scrolling. Long headlines don't get read.
Make the first one a hook. Your number one screenshot should answer "what is this and why do I care."
Use a verb. "Plan", "Track", "Save", "Build". Verbs imply the reader doing something.

Caption don'ts:

Don't repeat your app name on every slide. They already see it.
Don't put a paragraph. If it wraps to three lines, cut it.
Don't use hype words like "revolutionary." Nobody believes them.
Don't let the caption cover the important part of the UI.

4. Export at store sizes

This is the boring part that trips people up at submission. Both stores are picky about dimensions.

Apple App Store (the sizes you actually need):

6.9 inch iPhone (the current large size), portrait: 1290 x 2796 px. This is the required one. If you only do one set, do this.
6.5 inch iPhone is still accepted by many setups: 1242 x 2688 px.
iPad 13 inch only if you ship an iPad app: 2064 x 2752 px.

Apple now upscales from the largest iPhone size to fill smaller devices, so a single 6.9 inch set usually covers iPhone. You can upload up to 10 screenshots per device. Use at least 3, ideally 5 to 6.

Google Play:

Phone screenshots: minimum 320 px on the short side, max 3840 px, and the long side can't be more than twice the short side. A safe target is 1080 x 1920 px or 1242 x 2208 px.
You need 2 to 8 phone screenshots.
Play also wants a 1024 x 500 px feature graphic. Don't forget this one, it's the banner at the top of your listing.

Export as PNG or high-quality JPG. Keep file sizes reasonable so your listing loads fast.

Screenshot order matters more than you think

Put them in priority order, because most people only see the first two without scrolling.

A pattern that works:

The hook. Your strongest benefit, cleanest screen.
The core action. The main thing people open the app to do.
A "wow" feature. Whatever makes you different.
Social proof or results. A stats screen, a streak, a before/after.
Onboarding or setup, to show it's easy.

Don't bury your best screen at position five. Nobody gets there.

A note on localization

If you're shipping in more than one country, the stores let you upload a different screenshot set per language. You don't always need to redo all of it. Often just translating the headline captions is enough, since the UI inside the frame reads as "an app" regardless. Start with your top one or two markets. Don't translate into twelve languages before you have a single install.

FAQ

Do I need Figma or Photoshop for this?
No. You can do the whole thing with a browser-based framing tool plus clean screens. The skill that matters is writing good captions and picking the right order, not pushing pixels.

Can I just use raw screen recordings?
You can upload plain screenshots, and for some utility apps it's fine. But framed screenshots with headlines almost always convert better because they tell the buyer what they're getting.

What if my app isn't built yet?
You can still make listing visuals from designed or generated screens. An ASO visuals generator is the move here, since you don't have real captures to frame yet. Useful for pre-launch landing pages and "coming soon" listings too.

How many screenshots should I make?
At least 3, ideally 5 to 6. More than that and the extras rarely get viewed.

The honest takeaway

The hard part of store screenshots was never the design software. It's having clean screens to start from and writing captions that make someone tap install. If you've got real, tidy app screens, a free framing tool finishes the job in an afternoon. If you don't, generate the screens first, then frame and caption them.

Either path gets you a professional listing without a designer on payroll. Pick the one that matches what you actually have today and go submit.

Salim, Founder

From Idea to App Store Screenshots That Convert — Without a Designer

Salim — Sun, 14 Jun 2026 23:19:23 +0000

You finished the app. You wrote the description. Then you hit the part nobody warns you about: the store listing wants screenshots, and not raw phone screenshots either. It wants the polished kind with headlines and framed devices that every successful app seems to have.

I'm a developer. The first time I shipped, I uploaded plain screenshots straight off the simulator and called it done. Installs were bad. Not because the app was bad, because the listing gave people no reason to tap "Get." Here's what I learned about making App Store screenshots that actually convert, and how I make them now without hiring a designer.

Your screenshots are the ad, not the documentation

The mistake I made was treating screenshots like a manual. "Here's the home screen. Here's the settings page. Here's the profile." Nobody cares.

Almost nobody reads your full description. They swipe the first two or three screenshots, decide in a couple of seconds, and move on. So those images aren't documentation. They're the ad. This is the core of app store optimization on the visual side: the listing has to sell the outcome before anyone has used a single feature.

Good ASO visuals answer one question fast: what do I get if I download this? Not "what buttons exist." What changes for me.

The pattern almost every converting listing follows

Once I started actually studying the top apps in categories I cared about, the pattern was obvious. The good ones aren't doing anything magic. They follow a structure:

Screenshot 1 — the hook. One short headline with the single biggest promise, over the most important screen. This one carries most of the weight.
Screenshot 2 — the main thing. The one feature people open the app for. Show it doing its job.
Screenshot 3 — proof or payoff. Results, a chart going the right way, a before/after, or social proof if you have it honestly.
Screenshots 4-5 — supporting features. The rest of the value, in priority order. Drop-off is real here, so front-load.

Each one is a phone in a clean frame, a short caption above it (three to six words), and a background that matches your brand. That's the whole recipe. The headline does the selling. The device shot proves it's real.

If you want a fast way to see this, open the App Store, search your category, and look at the top five listings. Ignore the apps, study the layout. You'll see the same skeleton over and over because it works.

Write the captions before you touch any visuals

This is the part developers skip and it's the part that matters most. The words do more work than the design.

Bad caption: "Track your workouts." That describes a feature.
Better caption: "Never wonder if you're making progress." That describes a feeling the user came in with.

Go feature by feature and rewrite each one as the outcome, not the mechanism. Lead with the verb or the result. Keep it short enough to read while swiping. I write all five captions in a plain text file first, in priority order, before I think about a single pixel. If the captions are weak, no amount of nice gradients saves the listing.

Then the visuals — and where I stopped hiring this out

Now you have five sharp captions and your actual app screens. You need to turn them into framed, branded store images at the exact pixel sizes Apple and Google demand (and those sizes are annoyingly specific per device).

You've basically got three routes:

Do it manually in Figma or Sketch. Total control, and if you already live in Figma this is fine. Templates exist. It's just slow, and re-exporting every device size by hand after a tweak gets old.
Use a dedicated screenshot tool (Screenshots Pro, AppLaunchpad, Previewmaker, and others). These are genuinely good at the framing-and-export job and worth a look — they handle the device frames and store-size exports for you.
Generate them from your screens with AI. This is the route I landed on, because it also handles the brand styling, not just the framing.

I use Daisy for this part. I already design my app screens in it, so when it's time for the listing I generate App Store screenshots from your screens — captions, device frames, brand-matched backgrounds, all the store sizes — instead of rebuilding each one by hand in a design tool I half understand. The thing I care about is that the visuals match the app's actual look instead of feeling like a separate marketing afterthought.

To be fair about the tradeoff: the dedicated screenshot tools above are excellent if all you need is framing and export and your branding is already sorted. The reason AI generation fits me is that I'm not a designer, so I want the styling decided for me too, in the same place I designed the app. Pick the lane that matches what you're missing.

Don't ship the first version — test it

Whatever you use, the first set is a draft, not the answer. Two things I always do before calling it done:

Look at the thumbnail size. Your screenshots show up tiny in search results first. If the headline isn't readable as a thumbnail, it doesn't exist. Zoom out and check. I've killed plenty of "nice" designs because the text vanished at small size.

Change the order and watch. The first screenshot is the highest-leverage thing in your whole listing. If your store supports it, try a different lead image and watch the conversion rate. The store console shows you install conversion — let the real number decide, not your taste. App store optimization is a loop, not a one-time upload.

A simple checklist

Before you publish the listing, run through this:

Captions written as outcomes, not features.
Most important promise is on screenshot one.
Headlines readable at thumbnail size.
Device frames and backgrounds consistent across all images.
Exported at every required size for iOS and Android.
Localized if you're targeting non-English stores (translate the captions, not just the app).

FAQ

How many App Store screenshots should I have?
Apple allows up to 10 per device size; Google Play up to 8. You don't need the max. Make the first three excellent, since that's most of what people see, then add supporting ones in priority order. Quality over filling every slot.

What sizes do I need for App Store screenshots?
Apple requires specific pixel dimensions per device (the 6.7-inch and 6.5-inch iPhone sizes are the important ones, plus iPad if you support it). Google Play is more flexible but has minimum and maximum dimensions. Check the current developer docs, because these change — or use a tool that exports the right sizes for you so you don't have to track them.

Do I really need designed screenshots, or are raw ones fine?
Raw screenshots are legal but they convert worse. The framed, captioned style exists because it tells people the outcome before they install. If installs matter to you, the designed version is worth the effort.

Can I make these without any design skills?
Yes. The hard part is the captions, which is writing, not design. The visual part — frames, sizes, brand styling — is exactly what tooling exists to handle, whether that's a screenshot app or an AI generator. You bring the words and the app; the tool does the pixels.

How often should I update my screenshots?
Whenever you ship a meaningful feature, change your positioning, or see conversion stalling. Treat your top screenshot like a headline you're allowed to test. Small changes there can move installs more than another feature will.

The takeaway

App Store screenshots aren't a design chore you do at the end. They're the ad that decides whether your work gets installed at all. Write the captions as outcomes, follow the structure the winning listings already use, make the first image carry the promise, and let a tool handle the pixels so being a non-designer stops being the blocker.

You built the app. Don't let a weak listing be the reason nobody sees it.

How to Design a Mobile App With AI: The Full Workflow (Start to Finish)

Salim — Sun, 14 Jun 2026 23:09:50 +0000

I can design and build a real mobile app in an afternoon now. Not a toy. Something I'd actually put on the store.

The part that changed was design. I'm a developer, not a designer. Staring at a blank canvas used to kill projects before they started. Now I design a mobile app with AI in minutes, refine it, and hand it to my coding agent. Here's the exact workflow, end to end, no fluff.

Step 1: Don't design the idea. Steal the demand.

Before any tool opens, get the idea right. The biggest mistake is inventing something nobody asked for and then making it pretty.

I hunt for demand that already exists. Two places:

TikTok. Not to vibe out. To hunt. Look for apps random people film themselves using. The "what's it called??" comment threads. When the same small app keeps showing up, that's demand yelling at you.
App intelligence tools (Sensor Tower, App Figures, whatever). Filter for apps pulling roughly $10k to $30k a month. Big enough to prove there's money, small enough that you're not fighting a billion-dollar company.

You're not cloning button for button. You take the core thing people open the app for, then build your version. AI makes the making cheap, so the idea is where you should spend your judgment.

Step 2: Build a "feel" from real references

Now you know what you're building. Next you need to know what it should feel like.

I go to Mobbin. It's a giant library of screens from apps that already made it. I study how the winners do onboarding, the paywall, the empty state, the nav. Then I grab a handful of screens I like for each part of my app.

This matters more than people think when working with AI. AI tools are great at executing a direction and bad at inventing taste. If you walk in with references, you get something coherent. If you walk in with "make it modern and clean," you get generic mush. Garbage in, garbage out applies to design prompts too.

Step 3: Generate the screen set from a prompt

This used to be the part I dreaded. Now it's one prompt.

The key shift is going from "generate one screen" to "generate the whole app at once." A single screen is easy. A cohesive set, where onboarding, home, paywall, and profile all share one design language, is the hard part. That's what makes an app look real instead of like a Dribbble shot.

Here's how I prompt it. One or two sentences, concrete:

"Weight loss app for busy moms. Calm, motivating, data-forward. Soft greens, rounded cards, big friendly numbers."

Tell it the audience, the vibe, and any visual constraints. Drop in your Mobbin references if the tool supports it. A good tool will pick a theme, plan the screens, and lay them all out together. This is where I use Daisy to turn one prompt into a full set of app screens that actually share a design system, instead of stitching one-off generations into something that doesn't match.

A quick note on tools, because people always ask. They're not interchangeable:

Figma is the manual editor. AI gets you a first draft fast; Figma is where you do precise edits. They work together, not against each other.
v0 (Vercel) is excellent for web UI and React code. It's a different output than mobile screen design.
Uizard is solid for broad wireframing when you want low-fidelity fast.
Galileo AI generates general UI from text.

Pick based on the output you actually need. For me that's a cohesive mobile screen set I can edit and then build, so I optimize for that. Use whatever fits your lane.

Step 4: Never ship the first generation

The first version is always about 80% there. The last 20% is what gets people to actually download.

So I sit with it for ten minutes. Not an hour, ten minutes. I:

Pull one color tighter so the palette feels intentional, not random.
Kill any section that feels generic or copy-paste.
Move the most important thing higher on the screen.
Fix the spacing on the one screen that feels cramped.

This is where being a developer who can't "design from scratch" stops mattering. You don't need to create taste from nothing. You just need to recognize what's off and nudge it. That's a much lower bar, and AI handles the heavy lift underneath.

Step 5: Hand it off to your coding agent

Pretty mockups don't make money. A working app does.

This is the step that makes the whole AI design workflow worth it for developers. Get your designs out in a format you can build from:

Editable design files (Figma) if a human or another tool picks it up next.
Code export if you want a head start on the implementation.
Straight into an AI coding agent (Claude Code, Cursor, Codex) if you want it built now.

I drop the designs into Claude Code and have it build the real thing: screens, navigation, the one feature the idea actually promised. I don't walk away while it works. It's fast but it doesn't know what "good enough" means. I do. I test the main flow over and over and keep it tight. Build the one thing, not a pile of features nobody asked for. That's how projects drown before they launch.

Step 6: Ship and watch real behavior

That's the loop. No twelve-month roadmap. No waiting for perfect.

Get it in front of real humans. Watch what they actually do, not what you hoped. Then fix based on that. Real behavior beats your guesses every time.

Quick FAQ

Can AI fully design a mobile app on its own?
No, and you don't want it to. AI gets you 80% in minutes. The last 20% is human judgment: tightening the brand, cutting the generic parts, knowing what matters. Treat AI as the fast draft, not the final call.

Do I need design skills to design a mobile app with AI?
You need taste, not Figma skills. If you can look at a screen and tell what feels off, you can do this. Bringing real reference screens covers most of the gap.

What's the fastest part of the workflow, and what's the slowest?
Generating the screen set is the fastest now, often under a minute. The slowest is still picking the right idea and testing with real users. Spend your time there.

How do I keep all my screens looking consistent?
Generate the whole set together from one prompt instead of one screen at a time, so they share a single theme. Then refine the system once and it carries across every screen.

The takeaway

The AI handles the boring work: the blank canvas, the first draft, the consistent theme across twenty screens. You handle the calls that matter: the idea, the taste, the one feature that counts.

Speed only wins if the thing is actually good. Go find an idea that already works, and build your version.