App Store Optimization Basics for Developers

Developers tend to treat the store listing as the last chore before release. Fill in the boxes, upload whatever screenshots the simulator produced, hit submit. I’ve done it too.

The problem is that the listing is the only part of your app most people will ever see. If it doesn’t show up in search, or doesn’t convince someone in the few seconds they spend on it, the code quality behind it is irrelevant.

App store optimization (ASO) has a reputation for being a marketing dark art. The basics aren’t. They’re a handful of fields with clear rules, a few assets worth getting right, and some numbers to watch afterward. This is the developer’s version.

Text fields: iOS and Play work differently

The two stores index text differently, and the fields don’t map one to one. Here’s the short version (check each store’s current docs for exact limits, since they occasionally change):

	App Store	Google Play
Name/title	App name, 30 chars, indexed	Title, 30 chars, indexed
Second line	Subtitle, 30 chars, indexed	Short description, 80 chars, indexed
Keywords	Hidden keyword field, 100 chars	No keyword field
Long text	Description, not used for search ranking	Full description, 4,000 chars, indexed

The practical consequences:

On iOS, the keyword field does the heavy lifting. Use commas without spaces, don’t repeat words already in your name or subtitle (they’re indexed anyway), skip plurals of words you’ve already included, and don’t waste characters on your company name or the word “app.” Competitor brand names are against the guidelines and can get your listing rejected.

On Play, the full description matters for search. Write it for humans first, but naturally include the phrases people search for. Repeating a keyword unnaturally many times doesn’t help and can count against you.

The title should say what the app does. “Nightjar” tells nobody anything. “Nightjar: Sleep Sounds & Timer” tells people and search algorithms what they’re looking at. Keep the brand first and the descriptive part after.

The subtitle and short description sell the benefit. They show up close to your icon in search and on the listing. “Track shifts and swap them with your team” beats “The best scheduling solution.”

Screenshots that sell

Most people decide from the first two or three screenshots without scrolling. Treat them as a short slideshow, not a gallery of every screen.

What works:

• One message per screenshot, written as a short caption at the top. Benefit first: “Book in two taps,” not “Booking screen.”
• Lead with the core value. Whatever the app’s one job is, that’s screenshot one.
• Real content, not lorem ipsum. Realistic names, prices and data make the app feel alive.
• Readable at thumbnail size. If the caption is unreadable on a phone in search results, it’s too small.
• Match the device frames to the store’s required sizes and include tablet screenshots if you support tablets. A stretched phone screenshot on an iPad listing looks careless.

I generate raw screenshots from the Flutter app with a test account full of good-looking demo data, then add captions and backgrounds in a design tool. Integration tests can automate capturing screens, which pays off as soon as you have multiple languages.

Preview videos

Both stores support video. On the App Store, app previews autoplay muted in search results and on the product page. On Play, you link a YouTube video that shows at the top of the listing.

A few rules of thumb:

• The first few seconds matter most, because many viewers never watch further. Show the core action immediately, no logo intro.
• Assume sound is off. Use on-screen text.
• Apple expects previews to show actual app footage captured from the app, not a cinematic ad.
• Keep it short. A tight clip of the main flow beats a long tour.

If you don’t have time to make a good video, skip it. A weak video in the first slot pushes your best screenshot out of view.

Ratings prompts with in_app_review

Ratings affect both ranking and conversion, and the biggest lever is when you ask. In Flutter, the in_app_review package wraps the native review dialogs on both platforms.

import 'package:in_app_review/in_app_review.dart';

final _inAppReview = InAppReview.instance;

Future<void> maybeAskForReview() async {
  if (await _inAppReview.isAvailable()) {
    await _inAppReview.requestReview();
  }
}

The important part is the logic around that call:

• Ask after a success moment. A booking confirmed, a workout finished, a document exported. Never on launch, never after an error, never mid-task.
• Wait until the user has some history with the app, like a few sessions or a few completed actions.
• Remember the platforms throttle you. Apple shows the prompt at most three times in a 365-day period per user, and Google applies its own undisclosed quota. Calling requestReview() doesn’t guarantee anything appears, so never tie it to a button that says “Rate us.” For that, use openStoreListing() instead, which sends the user to the store page.
• Don’t gate or bribe. Asking only happy users first (“Do you like the app?” then prompting only on yes) and offering rewards for reviews both break store guidelines.

I store a simple counter and a last-asked date locally, and only call maybeAskForReview() when both conditions pass.

Localize the listing, not just the app

If your app supports multiple languages, translate the store listing too: title, subtitle, keywords, descriptions and screenshot captions. Localized listings often convert noticeably better than English ones in non-English markets, and on iOS each localization gets its own keyword field, which is extra room to rank.

Even if the app itself is English-only, a localized listing in a big market can be worth testing. Just be honest in the description that the app is in English.

If you’re localizing the app anyway, I cover the Flutter side in Flutter localization in practice.

Custom pages and listing experiments

Both stores let you test and target listings without shipping a new build:

• App Store custom product pages let you create alternative versions of your product page with different screenshots, previews and promotional text, each with its own URL. Point ads or campaigns for different audiences at different pages.
• App Store product page optimization lets you A/B test your default page’s icon, screenshots and previews against a share of traffic.
• Play custom store listings target specific countries or audiences.
• Play store listing experiments A/B test graphics and text on your main listing.

Change one thing per experiment, let it run long enough to collect meaningful traffic, and resist calling a winner after two days.

Measure what changed

App Store Connect’s analytics shows impressions, product page views, conversion rate and where users came from (search, browse, referrals). Play Console shows store listing visitors, acquisitions and conversion, broken down by country and source, plus search terms that brought people in.

The metric I watch first is conversion rate from page view to install. If people find you but don’t install, fix the screenshots and text. If they don’t find you at all, work on keywords and title.

Write down the date of every listing change. Without that, you can’t tell whether a jump came from your new screenshots or from something unrelated. A release checklist is a good place to record it.

Takeaways

• iOS and Play index different fields; use the iOS keyword field carefully and write a natural, keyword-aware Play description.
• Make the first two or three screenshots carry the whole pitch, with one readable message each.
• Ask for ratings with in_app_review after success moments, and respect the platform quotas.
• Localize listings, including screenshot captions, for markets you care about.
• Use custom product pages and listing experiments to test one change at a time.
• Track page-view-to-install conversion and log every listing change.

Your listing is the first screen of your app. It deserves the same care as the rest.