Your Mac app is ready. The download works, the screenshots look decent, and someone other than you has tested it.
Now you need people to find it.
If you’re wondering where to submit a Mac app, I’d start with a small mix: a Mac app directory, a relevant community, and a platform where people already look for software like yours.
Each needs a slightly different pitch. Someone browsing for a clipboard manager has different questions from a developer reading about how you built one.
Disclosure: I run MacNative, one of the directories below. Its standard listing is free, and I’ve included other options because the right choice depends on your app.
Here’s how I’d choose.
| Platform | When I’d consider it | What to prepare | Main limitation |
|---|---|---|---|
| MacNative | You want a listing in a Mac-focused directory | Screenshots, a clear description, pricing | Submissions go through review |
| r/macapps | You want feedback from Mac users | A demo, pricing, a useful comparison | Strict promotion rules |
| AlternativeTo | Your app replaces an existing tool | Accurate features and relevant alternatives | Free review can take months |
| Product Hunt | You can explain the app through a short demo | A focused launch page and time for questions | A launch needs preparation |
| Show HN | You built something a technical audience would want to try | A working app and an explanation of your decisions | A signup page alone doesn’t qualify |
1. MacNative: give your Mac app a discovery page
MacNative is a curated macOS app directory covering categories such as developer tools, productivity apps, and utilities.
You can submit your Mac app for a free listing. The standard plan includes a listing page with screenshots and basic analytics, subject to review. Optional paid promotion is separate; you don’t need it to submit. You can check the details on the pricing page.
Spend a little time on the description before submitting.
For example, a hypothetical window manager could introduce itself like this:
Save a window layout for each project and restore it when you reconnect your monitor.
That gives someone a task they can recognise. “A powerful productivity app for modern professionals” leaves them guessing.
Use screenshots that show that task, and make the price and system requirements easy to find. A directory listing should help someone decide whether to try your app.
2. r/macapps: prepare for questions, comparisons, and criticism
r/macapps is worth considering when you want to discuss your app with people who care about Mac software.
Read the current rules before writing a post. Some promotions belong in a megathread, and eligibility, format, and frequency restrictions matter. The October 2026 promotion thread asks developers to explain the problem, name comparable apps, and state pricing.
That’s a useful structure even outside Reddit:
- What does the app help someone do?
- What would they otherwise use?
- Why might they choose yours?
- What does it cost?
Be open about being the developer. Include limitations people will discover anyway, such as needing a recent macOS version or lacking a feature competitors offer.
Then stay around to answer questions. Budget time for the conversation after posting.
3. AlternativeTo: help people understand what they could switch from
AlternativeTo lets you submit software and suggest it as an alternative to existing products.
I’d consider it when your app has a clear comparison. Maybe it handles the same core task with a different pricing model, works offline, or suits a particular workflow better.
Choose those comparisons carefully. A lightweight notes app and a collaborative knowledge base might both store text, but someone switching between them could have very different needs.
There’s also a timing issue: AlternativeTo currently says free submissions can wait months for review. It offers optional paid priority review, which doesn’t guarantee approval.
Submit early if the fit is good. Don’t make approval part of your launch-day plan.
4. Product Hunt: useful when the benefit is easy to demonstrate
Product Hunt allows makers to submit their own products.
I’d consider it for an app whose value is visible quickly: a screen recorder, a design utility, or a tool that removes a repetitive step.
Build the demo around one complete task. Show the starting problem, the action, and the result. You can explain secondary features further down the page.
Product Hunt’s launch guidance also emphasises preparation and responding to the community. Set aside time to answer questions on launch day.
Decide beforehand what you want from the launch: trial downloads, useful feedback, or purchases. An upvote count alone won’t tell you whether people found the app useful.
5. Show HN: explain what you built and let people try it
Show HN is a possible fit for developer tools and Mac apps with an interesting technical approach.
Its guidelines require something people can try. A landing page collecting email addresses isn’t enough. They also encourage making the project easy to access, ideally without signup barriers.
Give readers something concrete to discuss:
- Why did you build it?
- What was difficult?
- What tradeoff did you make?
- What can someone test right now?
If your app processes files locally, explain what stays on the device. If you built a fast search tool, explain how you measured it.
Post when you’re available for the discussion, and don’t ask friends to upvote. The guidelines explicitly prohibit that.
Prepare one small submission kit
Before opening five submission forms, collect:
- A one-sentence description of the problem your app solves.
- Two or three screenshots showing actual use.
- A short demonstration.
- Pricing and trial details.
- Supported macOS versions and hardware.
- A working website and support contact.
Reuse the facts, then adapt the introduction to each audience.
For a directory, help someone compare options. For Reddit, give people enough context to respond. For Show HN, explain the implementation choices worth discussing.
How I’d start with limited time
Choose one directory and one community where your app fits.
Submit the directory listing first. Then prepare a useful community post and leave time to answer questions. Add a broader launch when your explanation and demo feel ready.
Track what happens after each submission: website visits, downloads, purchases, and the questions people ask. Use campaign links where permitted; some platforms require a clean website URL.
If visitors repeatedly ask whether your app works offline or supports Intel Macs, add that answer to the page. Promotion can reveal missing information as well as bring attention.
Which platform brought your Mac app its first users? I’d be interested in the type of app, where you shared it, and what happened after people clicked.
Top comments (0)