Collect beta tester feedback with screenshots, no SDK needed

A tester opens your new build, finds that the checkout button does nothing and sends you a message: "payment is broken". You reply asking which phone. A day later you learn it was an older Android phone, on the previous build. By then the release is late and nobody can reproduce the problem.

Most beta feedback is lost in that gap between what the tester saw and what the developer needs to know. This guide covers how to close it for iOS and Android test builds: how to collect feedback with screenshots and screen recordings without adding an SDK to your app, what a useful bug report contains, how to triage reports before a release, and a short template you can copy. At the end it shows how the Send feedback card on AppForShare install pages handles the same steps.

Three ways to collect feedback from beta testers

1. Email, chat and forms

The simplest option: testers send a message to a shared chat channel, an email address or a form. It costs nothing and needs no setup. The problem is quality. Testers forget to say which build they used, screenshots arrive without context, and reports from five testers end up in five different threads. It works for two or three people who know the app well, less so with clients or outside testers.

2. An in-app feedback SDK

A library compiled into the test build lets testers shake the phone or tap a button to report from inside the app. It can capture app state, logs and the exact screen. The cost is code in the app that you keep out of store builds, update with every OS release and review for the data it collects. For many small teams and agencies that is more work than the feedback is worth.

3. Feedback from the page testers install from

Testers already open a web page to install the build. If that page also takes feedback, the report can carry the build and the device automatically, because the page knows which build it served and what browser opened it. Nothing is added to the app. The trade off is that the report does not come from inside the app, so it cannot include app logs or a crash trace. For crashes you still want a crash reporting tool in the build.

Whichever you pick, keep one place for reports and tie every report to a build.

What a good bug report contains

A developer should be able to read a report once and try to reproduce it without asking a single question. That needs six things.

• A short title. What broke, where. "Checkout button does nothing on the cart screen" is better than "payment broken".
• Steps to reproduce. Numbered, starting from a known point such as opening the app or signing in. Include the data used, such as the account or setting.
• Expected result. What should have happened.
• Actual result. What happened instead, including any message on screen, word for word.
• Device and OS. Phone model and OS version. Many bugs exist only on one screen size, one OS version or one manufacturer's Android skin.
• Build. The version and build number. Without it, a bug fixed two builds ago gets reported again and someone spends an hour on it.

Two more details save time when they apply: how often it happens (every time, sometimes, once) and whether it is new in this build or was already there before.

Screenshots and screen recordings

A screenshot shows what the tester saw. A marked up screenshot shows what they meant: a circle around the wrong total, an arrow to the clipped label. Ask testers to mark the problem area instead of describing it.

A screen recording shows what a screenshot cannot: the sequence of taps, a screen that flickers, an animation that stalls, a tap that does nothing. For any bug that needs more than two steps, a recording of 20 to 60 seconds often replaces the whole steps section.

Both are built into the phone. On an iPhone, press the side button and volume up together for a screenshot (side button and Home on models with a Home button). For a recording, use Screen Recording in Control Center; if it is not there, add it in Settings first. On Android, press power and volume down together for a screenshot. Android 11 and later include a Screen record tile in Quick Settings, and many manufacturers ship their own recorder in the same place.

Ask testers to start recordings just before the problem. A five minute recording with the bug at minute four is slow to review.

A bug report template you can copy

Pin this in your tester channel or paste it into the form. Testers fill it in, and every report arrives in the same shape.

Title: [what broke, where]

Build: [version] ([build number])
Device: [model], [iOS / Android version]
How often: [every time / sometimes / once]
New in this build: [yes / no / not sure]

Steps to reproduce
1. [open the app / sign in as ...]
2. [...]
3. [...]

Expected: [what should happen]
Actual: [what happened, exact message if any]

Attached: [screenshot / screen recording]

Keep it short. A template with fifteen fields gets skipped.

How to triage tester feedback before a release

Keep two states: open and resolved

Every report is either open or resolved. Open means someone still needs to look at it or fix it. Resolved means fixed, a duplicate, not a bug or will not fix, ideally with a short note. If you track work in Jira, Linear or GitHub Issues, copy the reports that need code changes into a ticket and resolve the report once the ticket exists, so the two lists do not drift apart.

Mark release blockers early

Not every bug stops a release. Decide as soon as a report arrives whether it is a blocker. A simple rule that works for most teams: data loss, crashes on a main flow, blocked sign in or payment, and anything that breaks the upgrade from the previous version are blockers. Layout issues, wording and rare edge cases usually are not. Before a build goes to the store or to the client, the list of open blockers should be empty.

Triage by build

Look at reports per build, not as one long list. A bug reported on build 41 may be fixed in build 43. When a new build arrives, ask testers who reported issues to check them again on it, and resolve the ones that are gone.

Close the loop with testers

Tell testers what happened to their reports: fixed in the next build, known issue, not planned. Testers who never hear back stop reporting.

Deciding what testers should look at in the first place is a separate step. The guide on what to test in a new app build covers ordering tests by risk, and the AI test plan writes that list from what changed in the build.

How Send feedback on AppForShare install pages works

AppForShare shares iOS and Android test builds through an install link and QR code. Since November 2026, every install page of a build uploaded from an account also shows a Send feedback card. It follows the third approach above: nothing is added to your app and there is no SDK.

What the tester does

The tester picks Bug, Idea or Other and writes what happened, up to 4,000 characters. Name and email are optional, and filled in already for testers you invited. They can attach up to 5 screenshots and draw on them with a red pen to mark the problem, with undo. On Pro and Team they can also attach one screen recording per report (MP4, MOV or WebM, up to 45 MB).

The card appears once the page is usable: after the password, if the build has one, and while the link is live. On private Team projects only invited testers, the team and the client can open the page. Channel links work too, because on a phone they open the install page of the newest build.

What is attached automatically

The report includes the build it was sent from, the device and model, the OS version and screen size reported by the browser, the browser language and the country. Because these values come from the browser, it is still worth asking the tester to confirm the exact OS version when a bug looks version specific.

What the team sees

Reports arrive in the feedback inbox in the dashboard, with Open, Resolved and All views and a filter per build, and in a card on each build page. Developers and above can resolve, reopen and delete reports (deleting removes the files); Viewers can read them. Copy for an issue gives plain text you can paste into Jira, Linear or GitHub. There is no two way sync with those tools, and no reply from the dashboard yet, so you email the tester yourself.

On Team, a report can be marked as a release blocker and the inbox can show blockers only, which makes the check before a release a single view. Marking a blocker does not yet stop a build from being promoted to a Live channel, so the check is still a person's decision.

Alerts

On every plan the account owner gets an email when feedback arrives, at most one per build per hour. The email lists the device and counts but never the tester's text. On Pro and Team, a push notification topic for tester feedback is available, and the feedback.new webhook event can post new reports, with the message, to Slack, Microsoft Teams, Discord or your own endpoint. Setup is on the webhooks page.

The CLI command appforshare feedback lists reports, and the MCP server has tools to list and resolve them.

Which plan includes what

Feature	Free	Pro	Team
Send feedback on install pages	Yes	Yes	Yes
Up to 5 screenshots with drawing	Yes	Yes	Yes
Feedback inbox and email alert	Yes	Yes	Yes
Screen recording	No	Yes	Yes
Push, Slack, Teams, Discord and webhook alerts	No	Yes	Yes
Release blockers	No	No	Yes

Builds uploaded without an account do not show the card. Pro is $12 a month and Team $39 a month; see pricing for the rest of each plan.

What it does not do

• It does not collect crash reports, logs or anything from inside the app. Use a crash reporting tool in your test builds for that.
• There is no shake to report and no in-app button. Testers return to the install page to send feedback.
• Blockers do not yet stop a promote, and there is no two way sync with issue trackers.

Other build sharing tools take feedback in different ways, some through an SDK. The AppForShare vs TestApp.io page sets out how one of them compares.

Common questions

How do I collect feedback from beta testers without an SDK?

Give testers one place to report, such as a form, a shared channel or the page they install the build from, and ask for steps, expected and actual results, device, OS, build and a screenshot. A page that knows the build and reads the device from the browser fills in part of that automatically.

Should testers send screenshots or screen recordings?

Screenshots for anything visible on one screen, marked up to show the problem. Recordings for anything that depends on a sequence of taps, timing or animation. Short recordings that start just before the problem are the easiest to review.

What counts as a release blocker?

Each team sets its own rule, but data loss, crashes on main flows, blocked sign in or payment, and a broken upgrade from the previous version are common blockers.

Can testers send feedback without an account?

On AppForShare, yes. Testers do not need an account to send feedback. The build owner needs one: builds uploaded as a guest do not show the Send feedback card.