In-app tester feedback on iOS and Android without an SDK

The best moment to collect a bug report is the second the tester sees the bug, while they are still on the broken screen. That is why teams add a "Send feedback" item to the debug menu, or a shake to report. The usual way to get one is a feedback SDK compiled into the test build. This guide shows a lighter way that works on iOS and Android: the app opens a feedback web page with the version, build and screen already filled in. No library, no tester sign in, about fifteen lines of code.

It also covers what Firebase App Distribution offers for in-app feedback, since many teams start there, and where each approach fits. Firebase facts come from its documentation as read on November 2, 2026.

Three ways to take feedback from inside the app

Approach	What you add	Good at	Costs
Feedback SDK	A library in the test build	Automatic screenshots, logs, app state	A dependency to update, review and keep out of store builds
Mail or chat link	A mailto: or chat URL	Zero setup	Reports arrive without build or screen, scattered across inboxes
Feedback URL with parameters	One function that opens a URL	Build, version and screen attached; one inbox; iOS and Android	No automatic screenshot or logs; the tester attaches images

What Firebase App Distribution offers

Firebase's in-app feedback comes from the optional App Distribution Android SDK, which the docs mark as beta (collect feedback from testers). In short:

• Android only. The feedback guide covers the Android SDK. On iOS, the App Distribution SDK is documented for new build alerts.
• Two triggers. A built-in notification the tester taps from anywhere in the app (showFeedbackNotification(), which needs the POST_NOTIFICATIONS permission on Android 13 and later), or your own trigger such as a menu item or a shake (startFeedback()).
• Automatic screenshot. The SDK captures a screenshot of the current activity and opens a full screen form.
• Google sign in. If testing features are not enabled on the device, the SDK asks the tester to sign in to App Distribution with their Google account.
• Two libraries. An API-only library for all variants and the full SDK for pre-release variants only. Firebase warns that the full SDK contains self-update code that "may be considered a violation of Google Play policy, even if that code is not executed at runtime."
• Where reports go. The Tester feedback tab of each release in the console, plus email alerts to project Owners and Editors. Sending feedback to Slack, Discord or Jira uses Cloud Functions, which needs the Blaze plan.

If your testers are Android users with Google accounts and you want the automatic screenshot, it is a solid option and it costs nothing. The gaps are iOS, testers without Google accounts, and the extra dependency.

The feedback URL approach

The idea is simple. Your test build already knows its version, its build number and the screen the user is on. Put those in a URL and open it in the browser:

https://appforshare.io/feedback/<token>?platform=ios&version=2.4.0&build=118&screen=Checkout

The page knows which build that is, shows a feedback form for it with the screen filled in, and takes screenshots from the photo library. The browser adds the device model, OS version and language. When the tester sends it, the report arrives in the same inbox as feedback from the install page.

iOS (Swift)

import UIKit

enum Feedback {
    static let base = "https://appforshare.io/feedback/YOUR_TOKEN"

    static func open(screen: String) {
        let info = Bundle.main.infoDictionary
        var c = URLComponents(string: base)!
        c.queryItems = [
            URLQueryItem(name: "platform", value: "ios"),
            URLQueryItem(name: "version", value: info?["CFBundleShortVersionString"] as? String),
            URLQueryItem(name: "build", value: info?["CFBundleVersion"] as? String),
            URLQueryItem(name: "screen", value: screen),
        ]
        if let url = c.url { UIApplication.shared.open(url) }
    }
}

// Shake to report, in a test build only
#if BETA
extension UIWindow {
    open override func motionEnded(_ motion: UIEvent.EventSubtype, with event: UIEvent?) {
        if motion == .motionShake { Feedback.open(screen: "Current screen") }
    }
}
#endif

Pass a real screen name where you can, for example from your router or the top view controller's title. BETA here is a compilation condition you set for your test configuration in the build settings.

Android (Kotlin)

import android.content.Context
import android.content.Intent
import android.net.Uri

object Feedback {
    private const val BASE = "https://appforshare.io/feedback/YOUR_TOKEN"

    fun open(context: Context, screen: String) {
        val uri = Uri.parse(BASE).buildUpon()
            .appendQueryParameter("platform", "android")
            .appendQueryParameter("version", BuildConfig.VERSION_NAME)
            .appendQueryParameter("build", BuildConfig.VERSION_CODE.toString())
            .appendQueryParameter("screen", screen)
            .build()
        context.startActivity(Intent(Intent.ACTION_VIEW, uri))
    }
}

// From a debug menu item, in the beta flavor only
if (BuildConfig.FLAVOR == "beta") {
    Feedback.open(this, "Checkout")
}

A shake on Android needs a small accelerometer listener; a debug menu item or a long press on a version label is often enough, and easier to find for testers. The dashboard also gives React Native and Flutter versions of the same function.

Tips that make the reports better

• Ask testers to take the screenshot first. The page cannot capture the app's screen, so a screenshot taken before opening feedback is the one that shows the bug. The tester can then mark it up with a pen on the form.
• Name screens the way your team does. "Checkout" in the report should match "Checkout" in your code and tickets.
• Use the info parameter for context. A test account id or a feature flag set saves a question later. Never put passwords, tokens or personal data in it.
• Keep the code in test builds. Use a build configuration or flavor, as above, so store builds do not carry a feedback link meant for testers.

How the AppForShare in-app feedback link works

The link is per project and is on every account plan, including Free. Turn it on from the project's Testing page; the dashboard shows the URL with code samples for Swift, Kotlin, React Native and Flutter.

• Parameters: platform (ios or android), version, build, screen and info.
• Build matching: the same platform and build number first, then the same version, then the newest build of that platform. Reports land on the build the tester was really running when the numbers match.
• No sign in: the tester does not need an account, and the install page password does not apply to the link. Anyone with the URL can send feedback, which is why it belongs inside test builds rather than on a web page.
• The form: Bug, Idea or Other, up to 4,000 characters, optional name and email, up to 5 screenshots with drawing. One screen recording per report on Pro and Team.
• Your side: reports show in the Feedback inbox and on the build page, marked as sent from the app, with the screen. The owner gets an email (at most one per build per hour, without the tester's text). Pro and Team add push, Slack, Microsoft Teams, Discord and webhook alerts and one click Send to Linear or Jira. Team adds release blockers.
• Control: "New link" replaces the token, so older builds stop opening the form. "Turn off" makes the link answer "not active".

Limits against spam are the same as on install pages: 10 reports per address per hour, 100 per build and 500 per account per day.

What it does not do

• It does not capture screenshots, logs or crash traces automatically. Use a crash reporting tool for crashes; on Pro you can add your crash dashboard link to each project so it shows next to builds and feedback.
• It is not an SDK, so there is no in-app form. Feedback opens in the browser and the tester returns to the app afterwards.

Read more on the in-app feedback link page, see how install page feedback works in collecting tester feedback with screenshots, or compare with Firebase on AppForShare vs Firebase App Distribution. Plans are on pricing.

Common questions

Can I collect in-app feedback on iOS without an SDK?

Yes. Open a feedback URL from the app with the version, build and screen as parameters. You lose automatic screenshots and logs, and you avoid a dependency and any sign in for testers.

Does Firebase App Distribution support in-app feedback on iOS?

Firebase's in-app feedback guide covers the Android SDK only. Its iOS SDK is documented for new build alerts.

Do testers need an account to send feedback?

Not on AppForShare. With the Firebase Android SDK, testers sign in with a Google account the first time.

Will this get my app rejected by the App Store or Google Play?

Keep the feedback code in test builds only, with a build configuration or flavor, and it never reaches the store. Opening a web page is not unusual for an app, but a tester feedback link has no place in a store build.