DEV Community: Salim

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.