Getting an app reviewed or listed in the right place can put it in front of people who are already looking for that type of product. It does not guarantee downloads, and a submission is not a substitute for a useful store listing. For an indie developer or small team, the practical approach is to launch where your audience gathers, make the app easy to evaluate, and measure which referrals produce activated users rather than chasing a large number of links.
This guide updates the original Windows Phone and Windows 8 list for current app launches. The old platforms are now historical context; the submission and discovery channels below are intended for current mobile, desktop, web, and developer tools.
Also see: 5 Tips for getting your apps reviewed by Review Sites
Start with a review-ready app
Before contacting a publication or submitting to a discovery service, prepare a small press and testing package:
- A one-sentence description of the problem the app solves and who it is for.
- A short demo video or a few current screenshots showing the main task.
- A test account or reproducible demo, if the app requires sign-in.
- Supported platforms, minimum versions, regions, languages, and pricing.
- A privacy policy and a clear explanation of permissions or data collection.
- A direct contact address and a concise changelog for the release you are pitching.
Give reviewers a real reason to cover the app. Useful angles include a narrowly solved problem, a significant release, an unusual technical approach, an accessibility improvement, or a good fit for their existing audience. Avoid sending the same mass email to every site or claiming that a listing will produce a particular amount of traffic.
Current places to launch or get discovered
These services have different purposes. Product communities and software directories can provide discovery; app stores provide distribution; neither one should be described as guaranteed editorial coverage.
| Channel | Best fit | How to use it |
|---|---|---|
| Product Hunt Launch | New apps, web products, and meaningful releases | Prepare the product page, maker profile, images, and launch-day response plan. Treat comments as product feedback, not just promotion. |
| BetaList | Early-stage startups and products seeking initial users | Submit when the product is usable by early adopters. The service may require an account or review before a listing appears. |
| SaaSHub Submit | SaaS products, developer tools, and alternatives to established software | Provide accurate capabilities and categories so people comparing tools can understand where the product fits. |
| Indie Hackers Products | Products built by independent makers | Share the problem, progress, and lessons learned. Expect to sign in and follow the community's current posting rules. |
| Hacker News Show HN | Technical products with something demonstrable for developers | Use a direct title and explain what people can try. Be ready to answer technical questions and follow the site's submission guidelines. |
Directory submissions are most useful when the listing is maintained. Update the description when the product changes, respond to legitimate questions, and remove claims that are no longer true. If a service requires payment, approval, or an account, check its current terms before treating it as part of a launch plan.
Submit through the relevant app store
An app store listing is often the first thing a potential reviewer checks. Complete the official publishing process before pitching coverage:
- For Windows apps, follow Microsoft's Windows app publishing documentation. Do not describe the Microsoft Store as a Windows Phone channel; current Windows distribution and supported device targets are different.
- For iPhone and iPad apps, use Apple's App Store submission documentation. Review the current requirements, metadata rules, privacy details, and review status in App Store Connect.
- For Android apps, use the Google Play Console documentation. Check current testing, release, target API, store-listing, and policy requirements before publishing.
Use the same name, icon, screenshots, and value proposition across the store page and the review pitch. A reviewer should be able to install or open the exact build you described. If the app is not yet public, provide a stable test path and state its expiration or access limits.
How to pitch an editorial review
Find a publication whose readers match the app instead of relying on an old ranking or a generic “top review sites” list. Read several recent articles first and look for a published contact, tip, or submissions page. If no such page exists, do not guess a private email address or assume the publication accepts unsolicited apps.
Keep the message short:
- Address the editor or publication by name.
- Explain the audience problem in one sentence.
- Say what is new or distinctive about this release.
- Link to the store page, demo, screenshots, privacy policy, and press material.
- Offer a review code or test account with clear instructions.
- Disclose relevant limitations, paid features, affiliate relationships, or sponsored arrangements.
Send one useful follow-up after a reasonable interval. If there is no response, move on. A rejection or silence is not evidence that the app is poor; it may simply be outside the publication's current coverage.
Measure whether coverage helps
Add campaign parameters to links where the destination supports them, and keep a simple launch log with the date, channel, message, and release version. Compare:
- Visits to the store or landing page.
- Install or signup completion.
- Activation of the app's main feature.
- Retention, trial conversion, or another outcome that matches the business model.
- Support requests and quality of feedback.
Avoid counting every visit as success. A small technical community that produces a handful of engaged users can be more valuable than a large untargeted audience. Use the results to improve the store listing and decide which channels deserve another submission.
Windows Phone and Windows 8: historical note
The original article focused on Windows Phone and Windows 8 review sites, app directories, and app IDs. Those links and app-store paths were tied to ecosystems that are no longer a dependable route for a current launch. They are intentionally not repeated here. If you are maintaining a legacy application, preserve its historical documentation separately and confirm the supported operating system, distribution method, and security expectations before directing users to it.
A practical submission checklist
Before sending a pitch or publishing a directory listing, confirm that:
- The app works on every platform and version you claim to support.
- The store or demo link opens for a first-time visitor.
- Screenshots and the description match the current build.
- Permissions, data handling, and privacy information are easy to find.
- The recipient's audience genuinely overlaps with your target users.
- You can support a test account and answer questions during the launch.
- You have a way to attribute visits and evaluate activated users.
This process produces fewer, better-targeted submissions than copying a legacy list. It also keeps your launch materials useful after the first review or directory listing.