The first 100 downloads: a small milestone, a useful beginning

First, what does “100 downloads” count?

Choose a metric you can explain and use it consistently. First-time downloads, total downloads, installations and active users are not interchangeable labels. If you reached 100 first-time downloads, record that exact label and the period it covers.

Apple’s guide to units and proceeds explains that new app units do not count later updates and redownloads as new acquisitions. That is a useful distinction when you are trying to understand an early audience.

Keep beta participation separate as well. People testing a build and people obtaining the released App Store version are different groups. If two screens disagree, check their definitions and filters before deciding that your milestone has disappeared. Our download-number troubleshooting guide walks through those checks.

The point is not to spoil a celebration with terminology. It is to give the number a meaning you can keep using.

Is 100 downloads good?

There is no useful universal deadline for reaching it. A narrow paid utility, a free game and an app shared with an existing audience start from different positions. A download count without the app’s purpose, price, reach and time on the store leaves too much out.

Compare the result with what you actually tried. Did you publish quietly? Show the app to a relevant community? Send it to a few people with the problem it solves? The outcome can help you plan the next attempt, even if it does not produce an impressive headline.

Downloads also do not tell you whether someone found the app useful. For an app meant to support a recurring task, returning use may be an important next question. For an occasional utility, usefulness may look different. Start with the behaviour your app is intended to support.

Write down the story while you can still remember it

Make a small launch log. Record release dates, product-page changes, posts, outreach and any customer conversations you are allowed to retain. A few factual notes are more useful later than a memory that the app “did well around Tuesday”.

Use cautious language for causation. “Downloads increased after the post” records a sequence. “The post produced every extra download” needs evidence you may not have.

Find out what the first experience feels like

Ask a few willing people to try the main task. Give them a realistic goal and watch where they hesitate, without coaching them through every tap. Let them tell you what they expected the app to do.

Useful questions are concrete: “What did you think this button would do?”, “Where would you look for your saved item?” and “What would stop you using this again?” A broad request for feedback often produces a polite answer instead of a specific observation.

Look for repeated friction. If several people cannot find the same control, that is a clear thing to investigate. A single feature request is still worth understanding, but it does not automatically become the next item on the roadmap.

Keep public reviews in the picture too. Respond where you can help, and use the negative-review guide if your first difficult comment arrives before you feel ready for it.

Do not ask a tiny sample to predict the business

Small counts move sharply. In a hypothetical week with five downloads, one extra download is a 20% increase. In a week with six, losing one is a fall of about 17%. Neither movement alone establishes a durable trend.

Show counts alongside percentages and compare complete periods. Resist dividing a handful of people into so many segments that every conclusion depends on one person. A descriptive observation can be useful without becoming a forecast.

Apple also applies data-availability conditions to some analytics. Its Analytics help explains that some usage and quality measures depend on sufficient data and user sharing choices. An empty panel may mean that a measure is unavailable, rather than that nobody did anything.

When the data cannot answer the question yet, say so. Work from the stronger evidence you do have: a reproducible bug, a confusing screen or a clearly described customer need.

Choose one product improvement and one distribution experiment

A manageable next cycle has two parts. Improve a known piece of the experience, then give a relevant audience a clear chance to discover the app.

• Product: fix a confusing first screen, resolve a reported bug or make the core task easier to complete.
• Distribution: show a concrete use case to a community where sharing is welcome, improve an unclear screenshot or explain the problem the app solves in a short demonstration.
• Observation: record the date and review comparable counts and feedback after a sensible period.

Keep the experiment proportionate. There is no need to buy a large campaign simply because the counter reached three digits. Choose something you can learn from, repeat and support.

Our first-month checklist gives this process a little more structure if you want a regular routine.

Keep the milestone

A screenshot, a note or a share card is enough. Include the metric and period so the image will still mean something later. You can be pleased with early progress without presenting it as proof of a large business.

Template to adapt: “[App] has reached its first 100 [metric] since [date]. Thank you to everyone who gave it a try. The most useful thing I’ve learned so far is [specific observation]. Next up: [improvement].”

Use a real observation and your actual count.

Perch brings installs, proceeds, reviews and rankings into one place, with milestone and sharing features for the moments you want to keep. The purpose is to make the check easier, so there is more attention left for the next person who opens your app.