App store optimization for indie developers

Five routes to downloads, the launch window you only get once, and the two that keep working if you ever ship on the web

App store optimization is the strangest channel on the list, because it is the only one that is either irrelevant or decisive. Most software gets a middling result from most channels. The app store gives you nothing at all if your product is a web app, and it is close to your entire distribution if your product is an iPhone app. There is no useful middle. That makes the first question trivial and the follow-on questions unusually high stakes.

This is the follow-on. It assumes you have already answered yes to the install question and you are now trying to work out where a limited number of hours goes. Five routes are realistically open to one person with no budget, and the order below is the order they pay off in, which is not the order most people attempt them.

1. Launch week is a window, not a milestone

A newly released app tends to surface in App Store search autocomplete for a few days after it goes live. The developers who notice this describe the same shape: a burst of installs in the first week that has no obvious source, then a decline to whatever the app's standing search position deserves. Apple does not document the behaviour and has never confirmed it exists, so treat it as a pattern reported consistently by people shipping apps rather than as a rule. The practical consequence holds either way.

The consequence is that your app name is a distribution decision made before you submit, and it is very hard to change later. If the window is real and your name is a bare invented word, the boost points at a term nobody types. The format that catches it puts a searched phrase in front of the brand:

interior design ai - Miya

You have thirty characters for the name and thirty more for the subtitle, so this is a genuine trade rather than a free win. There is also a separate hundred-character keywords field that users never see, and new developers routinely waste it repeating words already in the name. Comma separated, no spaces, no plurals of words you have already used. Apple builds phrases from the pieces.

The reason to get this right at submission is that it is the one lever on this list with a deadline. Everything else you can improve in month four.

2. The metadata is the asset

Store optimization proper is four things: the name, the subtitle, the icon, and the screenshots. It splits cleanly into getting found and getting installed, and most indie developers spend all their effort on the first half.

Getting found is keyword work, and the trap is targeting terms you cannot win. A one-person app is not outranking an incumbent on a two-word head term in its first year. The winnable targets are longer and more specific, which sounds like settling and is not: someone searching a four-word phrase has already described their problem to you, and they convert at a rate the head term never matches.

Getting installed is where the leverage actually sits, because it is a multiplier on every impression you already have. Two changes do most of the work. The icon has to survive being one small square in a list of ten, which means one shape, high contrast, no text, legible at the size a thumbnail actually renders. The first two or three screenshots are the only ones visible without a swipe, so they have to sell the outcome rather than tour the interface. A screenshot captioned “your room, redesigned in twelve seconds” outperforms one captioned “powerful editing tools” every time, because the first is a result and the second is a feature list.

Generating icon concepts with an image model is now the normal way to do this, and it is a reasonable use of the tool. Generate thirty, shrink them all to forty pixels, and throw away the twenty-eight that turn to mush. The test is legibility at thumbnail size, not beauty at full size.

3. Search, which outlives the app

A single page targeting a high-intent phrase is the cheapest durable asset a solo developer can build, and it does something the store cannot: it exists outside Apple's ranking, so it survives an algorithm change, a category reshuffle, or your decision to ship a web version next year.

Two practical notes. Ranking is materially easier when the target phrase is in the domain itself, which is an argument for buying a descriptive domain rather than a clever one. And Google Trends, the usual free starting point, reports relative interest over time rather than volume, so it will tell you a term is rising without telling you whether it is fifty searches a month or fifty thousand. It is enough to compare two candidate phrases against each other and not enough to decide whether either is worth a page.

The genuinely new side effect is that language models increasingly answer “what app should I use for X” by reading pages like this one. A page built to rank also feeds the assistants, which is a second distribution channel arriving free with the first. That is worth knowing and not worth planning around yet.

The cost is time. Search is a compounding asset for a product that intends to exist in two years, and a poor answer to where next month's installs come from.

4. Organic video, and the point where it stops being free

Cross-posted short-form content is the route with the highest ceiling and the worst reported effort curve. The funnel is short, which is what makes it work for consumer apps: views to downloads to purchases, with no landing page and no email sequence in between. A visual before-and-after app can convert on a fifteen second clip.

Two formats are worth your time. Short video does better and costs more, usually a face reaction to hold the first second followed by the app doing the thing. Image slideshows of three to six frames convert worse per view and take a tenth of the effort, which makes them the honest starting point when you are testing whether the format works for your app at all.

The part worth flagging is what happens when it does work. The standard escalation is to run the same content across many accounts to widen the number of chances at the algorithm, and this is where a side channel quietly becomes a job. One developer posting the recent write-up that prompted this page described starting manually and then building his own tool, DistributionMaxx, once he reached sixteen accounts, because the manual version had stopped being viable. That is a fair description of the cost curve rather than an endorsement of any particular tool. Take the general lesson: the free channel is free at one account, a part-time job at five, and infrastructure at fifteen. Budget for that before you scale it, not after.

5. Paid, and only with a number

Apple Search Ads puts you at the top of a search results page for a term you bid on, charged per tap. The targeting is excellent, because someone typing your category into the App Store has stated their intent more clearly than almost any other audience you can buy.

It still goes last, for the same reason paid goes last everywhere. An auction is a multiplier on a conversion rate. If you do not know what share of your product page visitors install, and what share of installs pay, you are not buying customers, you are buying an experiment, and it is the most expensive way to run one. Fix the screenshots first. The same traffic converting two points better makes every future bid cheaper, and it costs nothing per tap.

Once you do have those numbers, paid is the one route on this list that turns money into installs predictably, which is exactly why it is useless before them.

If your product is not on the App Store

Routes one, two and five evaporate. There is no launch autocomplete window, no metadata to optimize, and no store auction to enter. This is worth being blunt about because app marketing advice circulates widely among people building web software, and most of it does not transfer.

Routes three and four transfer completely. Search and organic content care about the problem you solve, not the platform you ship on. So does the channel that App Store content never mentions, because app developers rarely have access to it: going where the conversation about your problem already happens and being useful in it. A forum thread is a public signal that someone has the problem today, and answering it properly is slower than an ad and considerably cheaper than a video operation across sixteen accounts.

Whichever list applies to you, the constraint is the same one. You can run about two of these at a time, paired so one pays this month and one compounds. For an app at launch that pairing is usually store metadata plus organic video, with the search page written in the quiet weeks afterwards. Attempting all five is the reliable way to do none of them well enough to produce a signal.