You are two weeks out. The build works, the screenshots are done, and everyone who has opened the app so far is either you or someone who likes you. What you want is a stranger launching it cold and telling you what they thought it was for.
Searching for that goes wrong more often than it should, because "get feedback on my app" and "get reviews on my app" read like the same request and are not. One is a conversation about your product. The other is the behaviour Apple names as grounds for removing you from the Apple Developer Program — not the app, the account, and every app under it.
So it is worth knowing exactly where that rule sits, and what is left once you stay clear of it.
The rule is not Guideline 3.1
The usual citation for review manipulation is Guideline 3.1. That shorthand is everywhere, including in this site's own source comments. Fetch the page and it is not where the sentence lives.
In the markup of the App Review Guidelines, the 3. Business heading is followed by two paragraphs marked section-intro, and only then does 3.1 Payments begin. The second of them is the one everybody means:
If we find that you have attempted to manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback, or engage with third-party services to do so on your behalf, we will take steps to preserve the integrity of the App Store, which may include expelling you from the Apple Developer Program.
It carries no guideline number at all. Every numbered rule on that page has an id attribute — 3.1.1, 3.2.2, 5.6.3 — and this paragraph has none. It is the preamble to the whole Business section, so it is not scoped to payments or in-app purchase or anything narrow enough to argue about.
Four words in it do most of the work: paid, incentivized, filtered, or fake. Paid and fake are the ones people expect. Filtered catches developers who thought they were being careful — asking only the users you expect to be happy sits in the same list as buying reviews. And engage with third-party services to do so on your behalf means outsourcing does not move the liability.
Two other places on the same page say the same thing from different angles. The document's own Introduction lists trying to "manipulate ratings or App Store discovery" as cheating the system, and states both consequences: the apps come off the store and you are "expelled from the Apple Developer Program". And 5.6.3, Discovery Fraud, under the Developer Code of Conduct, names "charts, search, reviews, or referrals" as things that may not be manipulated. That one does have a number.
Read all three and the shape is consistent: the stated remedy is the account, not the listing.
The remaining rule worth reading exactly is 3.2.2(x), in the list of unacceptable business practices. It is about your own code, not your marketing:
Apps must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app.
What Apple offers instead, and where it stops
Guideline 2.2 settles the distribution question: demos, betas and trial versions do not belong on the App Store, and TestFlight is where they go. It also carries the line people miss while planning tester recruitment — builds in TestFlight "cannot be distributed to testers in exchange for compensation of any kind, including as a reward for crowd-sourced funding". Paying for testers is closed off for the same reason paying for reviews is.
The caps below are from Apple's TestFlight page and the App Store Connect help page for inviting external testers, both fetched on 2026-08-20.
| Channel | Who it reaches | Cap Apple sets | What it will not give you |
|---|---|---|---|
| TestFlight, internal | Team members in App Store Connect holding the Account Holder, Admin, App Manager, Developer or Marketing role | 100 | Anyone who has not already seen the app |
| TestFlight, external by email | People whose email address you already have | 10,000 per app | Reach past your own contact list |
| TestFlight, external by public link | Anyone who clicks, filtered by the device and OS criteria you set | A limit you choose between 1 and 10,000 | Any say in who they actually are |
| Peer critique on your listing | Developers reading your product page or build | None | How the app behaves on a device |
If you check those yourself, note that Apple's /help paths return HTTP 200 for pages that do not exist. Measured while writing this, the real external-testers page is 380,866 bytes against 83,361 for an invented sibling path that also answered 200. Verify by title or body size, not status code.
Apple's guidance on public links is to put them in marketing communications and set criteria so only testers on a matching device and OS version can accept — then disable it once the group is full, rather than leave people accepting an invitation to a beta with no room.
What comes back is narrower than people expect: a screenshot the tester can mark up and send with a comment, and crash reports with optional written context, all landing in the TestFlight section of App Store Connect. External distribution first needs a beta app description, beta app review information, and a build approved by TestFlight App Review.
If the audience is two friends rather than a beta programme, the guidelines' Introduction points at installing with Xcode or using Ad Hoc distribution instead.
The part TestFlight does not do
TestFlight tells you the build runs and where it crashed. It does not tell you that your first screenshot reads as a different category of app, or that your subtitle answers a question nobody asked.
That gap is what /feedback-exchange fills: post an app or a TestFlight build with a brief, get structured critique back — first impression, what works, what to fix — and earn the right to post by writing it for someone else. The interesting part is not the feature list. It is what had to be true for the thing not to drift into a review ring on its own.
- Reciprocity is a database trigger, not a disabled button. The insert is rejected once
requests_made >= feedback_given + starter_grant, with a ceiling of three open requests. The client mirrors the numbers only so the UI can grey a control out ahead of a rejection it cannot prevent. - The starter grant is 3, and it was 1 first. A grant of 1 made the board impossible to start: a new account could post once, then owed feedback before posting again — but an empty board has nobody to give feedback to, and feedback on your own request is blocked.
- Both feedback fields have a 20-character floor, written as a
CHECKconstraint rather than a form validator. It is the anti-farming rule: "looks good" does not buy a credit. - A column belongs to whoever it is about, not whoever can reach the row.
helpfulandowner_replyare revoked fromauthenticatedoutright and written only through functions that verify the caller owns the request being answered. - Two reports hide a post, a low threshold on purpose: soliciting a review swap endangers other people's developer accounts, not only the poster's, and a hide is reversible. "Asking for App Store reviews" is the first option in the report list.
- The board sorts least-answered first, so a busy day cannot bury someone still sitting on zero replies.
- An untouched AI draft cannot be submitted. The button stays blocked while what you are about to send is byte-identical to the generated text — an AI's read of a listing it cannot run is worth nothing to the recipient.
- A TestFlight link is pinned to
testflight.apple.com/join/<code>by the same pattern in the client and in a database constraint — a security control rather than formatting, because the URL renders as a link other developers click.
Nothing in it links to, mentions or scores an App Store review, and the banner saying so cannot be dismissed. Open requests close themselves after 30 days.
What this cannot tell you
Whether your app is good. Five developers are five opinions from people who are not your customers, and developers notice developer things — polish, conventions, whether the tab bar is standard. They are a poor proxy for someone who downloaded the app to solve a problem at 11pm.
Whether the listing converts. Nothing public exposes impressions or conversion rate for anyone's app, including your own. Apple's Product Page Optimization measures it properly and needs live traffic to do so, which makes it a post-launch instrument — the arithmetic of how much traffic is on /product-page-test.
Whether any of this moves your ranking. Apple documents no ranking factor for feedback of any kind, so nobody outside Apple is in a position to claim one — and this post is not going to invent it.
Who your testers are. A public link filtered by device and OS is still a link. The people who click it are the kind of people who click beta links, which is a real sample of somebody but probably not of your market.
What any given venue allows. Rules for posting a build differ from place to place and change without notice. Read the rules where you are posting.
How launch day will go. TestFlight installs are not App Store downloads. They never appear on your product page, never enter a chart, and do not carry over.
Where to put the link
/feedback-exchange is the critique loop, and it never touches an App Store review. /launch-directories is the venue list for when the public link is ready — every URL on it was fetched before it was added, and none of them carries a claim that submitting achieves anything. The rest is between you and the venue's own rules.