Why Your App Submission Got Rejected (and Fixes)

Most rejections come down to one of a small set of causes: the app isn't actually reachable yet, the listing doesn't say what the product does, it's paid with no way to try it for free, or it trips a policy line the directory won't bend on. None of these are permanent. Fix the specific thing, then resubmit the same listing rather than starting a new one, and say what changed in one line. The rest of this covers each cause from the side of the person who opens your link and decides, plus a table you can check your own submission against before you send it anywhere.

We review every submission to TryMy by hand: someone opens the app, tries it, and writes the listing. That means we can describe what a rejection actually looks like from behind the desk, instead of quoting a rejection rate. You'll notice this post has no percentages in it. That's deliberate. A lot of pages on this topic hand you a precise-looking percentage for how many submissions fail on the first attempt, or how many get rejected for a bad screenshot, without saying where the number came from or how many submissions it is based on. We're not going to do that. What follows is what a reviewer actually sees, not a stat pulled from nowhere.

What does your rejection reason actually mean?

Check your own listing against this before you submit anywhere, not just here.

Reason	What the reviewer saw	The fix	Can you resubmit?
Not live	A link that 404s, a "coming soon" page, or a build gated behind an invite list	Ship it, then submit	Yes, immediately once live
Broken or unclear URL	A redirect chain, a localhost or staging link, or a link that needs a VPN or login the reviewer doesn't have	Submit the real production URL, and include demo credentials if login is required	Yes
Vague description	Marketing language with no verb telling the reviewer what the app does ("the future of productivity")	Rewrite around the concrete action: what a user does, in the first sentence	Yes
No free way in	Paid-only, no trial, no freemium tier	Add a free tier or trial, or accept the app isn't a fit for a "try it" directory	Only after a real product change
Policy violation	Crypto casino, adult content, malware flag, an obvious bait-and-switch between the listing and the actual product	None that keeps the same product	No, not for this directory
Duplicate submission	The same app (or a near-identical relaunch under a new name) already listed	Ask for the existing listing to be updated instead of resubmitting from scratch	Depends on the directory's policy
Screenshot or branding mismatch	A screenshot that doesn't match what loads at the URL, or a logo pulled from a different product	Take a fresh screenshot after loading the real, current app	Yes

What does a reviewer look at first?

The URL, before anything else. Every other field on a submission form, tagline, description, category, is text you wrote about your app. The URL is the only field that isn't a claim. It's the thing the reviewer can go check. So the first click is always the link, and everything after that is coloured by whether it worked.

After the link loads, the second thing is whether the page in front of the reviewer matches the words in the form. If the tagline says "AI-powered scheduling assistant" and the page that loads is a waitlist form with an email box, that's a mismatch, not a lie exactly, but a listing that describes a product that doesn't exist yet at that URL. The description has to be a fair summary of what actually loads, not of what you're planning to ship.

Why does "not live yet" reject more submissions than anything else?

Founders submit early because submitting feels like progress, and a listing in a directory looks like traction. But a directory is a "try it" surface, not a "coming soon" surface, and a reviewer who lands on a landing page with no working product has nothing to try. There's no dishonesty in this, most people submitting a coming-soon page know it isn't done, they're hoping to get in the queue early. The problem is just that a review can't happen against a product that isn't there yet.

This is also the one Apple has written down explicitly for its own store: submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission," and separately, "[d]emos, betas, and trial versions of your app don't belong on the App Store" in Apple's App Store Review Guidelines. Google Play states the same idea more plainly in its own policy: "[a]t a minimum, apps should provide users with a basic degree of functionality and a respectful user experience," in the Google Play Developer Content Policy. Different platforms, same bar: reviewable means loadable and usable today, not soon.

If your app genuinely isn't live, the honest move is to wait. A submission you send while the site is still a waitlist page just becomes a second submission you have to remember to send again later, and a reviewer who saw the placeholder once is a little more skeptical the second time.

What counts as a low-quality or unclear listing?

Two different problems get lumped under "low quality," and they need different fixes.

The first is a genuinely thin product: something that works but does very little, a single-feature tool with no real polish, a wrapper around someone else's API with nothing added. That's a product problem, not a copy problem, and no amount of rewriting the description fixes it.

The second, more common problem is a fine product with an unclear listing. This is a copy problem, and it's fixable in five minutes. The tell is a description built entirely from adjectives instead of verbs: "seamless," "powerful," "next-generation," with no sentence that says what a user actually does in the app. Google's own search guidance calls out a version of this same pattern in web content, describing pages that provide "little value to users" through recycled or synonymized text with nothing original added, in its search spam policies documentation. A reviewer reading a listing built the same way, all adjective, no verb, has no way to tell what they're about to open.

The fix is to write the first sentence as an action: "X lets you do Y" or "X turns A into B," with the specific thing a user does named plainly. Save the adjectives for the second sentence, if you use them at all.

Which categories get rejected on policy grounds?

Some rejections have nothing to do with quality and everything to do with a line the directory won't cross regardless of how well-built the product is. On TryMy specifically, that line is stated plainly on the submission page and the about page: no scams, no crypto casinos, no malware, no bait, and the product has to be something people can actually try for free, whether that's fully free, a free trial, or freemium. A well-built paid-only tool with no free tier isn't a bad product, it's just not a fit for a directory whose entire premise is trying things before you commit to them.

Other directories draw the line in different places, adult content, gambling, MLM and affiliate-only sites, weapons, are common ones. None of these are arbitrary meanness on the reviewer's part; they're the directory protecting the thing that makes it worth visiting in the first place. If your product sits in one of these categories, no rewrite gets you in, and the honest thing to do is find a directory built for that category instead of resubmitting the same listing hoping for a different reviewer.

How should you resubmit after a fix?

Fix the specific thing the rejection named, not everything you can think of at once. If the reason was a dead link, fix the link. If it was a vague description, rewrite the description. Resubmitting with ten unrelated changes makes it harder for a reviewer to tell what actually changed, and on a manually reviewed queue, that means a slower second look, not a faster one.

Where the directory supports it, reply to the rejection rather than opening a fresh submission, and say in one sentence what changed: "fixed, the app is live at this URL now" or "rewrote the description to say what it does." That one line saves a reviewer from having to re-diff your listing against what they remember rejecting. On TryMy, review for a standard free listing runs a few days because a person is actually opening the app; a featured submission skips the queue and gets reviewed within a day, which is one of the very few things a paid, featured listing actually buys you.

Give it a reasonable gap before resubmitting, at least until you'd expect a person to have gotten to it, rather than sending the same link again the next morning. If you've made the fix and prepared everything the listing needs beforehand, our own submission checklist and the directory description guide cover the assets and the wording most reviewers are checking for, across any directory, not just this one.

Why do some directories never reply at all?

Because most directories run on volunteer or single-person review, and a rejection with no explanation is usually a time constraint, not a verdict on your product. A person clearing a queue of dozens or hundreds of submissions a week doesn't have time to write a custom explanation for every "no," so many directories either send a form rejection or send nothing at all. Silence past the stated review window (check the directory's own FAQ or about page for what that window is) is worth treating as a soft no and moving on, rather than resubmitting into the same silence repeatedly.

This is also where it's worth separating two different goals: getting listed, and getting people to actually try your app. A listing that never gets a reply from one directory hasn't cost you anything except the time it took to submit. If a handful of directories go quiet, the free submission short list has others that reply reliably, and plenty of founders get more traction from trading effort directly with other builders, a review for a review, a share for a share, than from waiting on any directory's queue. favors.dev exists for exactly that kind of direct trade between people building things, if a queue that never answers has you looking for a faster loop.

Frequently asked questions

Can I resubmit after a rejection?

Yes, on almost every directory, including this one. Fix the specific issue named in the rejection, then resubmit the same listing rather than opening a new one from scratch, and note what changed. Directories that ban resubmission entirely are rare and usually reserve it for policy violations, not fixable issues like a dead link or a thin description.

Do directories reject apps that aren't free?

Some do, some don't, it depends entirely on what the directory is for. TryMy specifically requires the app to be free to try in some form, fully free, a free trial, or freemium, because the whole premise is letting people try things before committing. A general startup directory with no "try it" angle may have no such requirement. Check the directory's stated policy rather than assuming either way.

Does a coming-soon page count as live?

No. A waitlist, an email capture page, or a "launching soon" splash counts as not live for review purposes, even if the page itself is polished and the launch is close. Reviewers need something they can actually open and use today. Submit once the product itself, not just the marketing page, is reachable.

Why did my submission get no response?

Most likely the directory is small, volunteer-run, or working through a large queue, and sends no reply for anything that isn't accepted. Check the stated review window first. Past that window, treat silence as a soft no, make sure the listing is genuinely ready, and either resubmit once or move on to a directory that replies.