How to Gather User Feedback Inside an iOS App

People who use your app every day know what is missing from it. Most of them will never tell you, because telling you takes effort. Your job is to make it easy at the moment they think of it, and to send each kind of feedback somewhere you will read it. This guide covers five channels that work for iOS apps, what each one is good at, and where each one falls short.

The short version

• An in-app board is the best home for feature requests: users post, vote and comment without leaving your app.
• A prompt at the right moment catches ideas while they are fresh. Ask after a task is done, never in the middle of one.
• TestFlight is for beta testers, screenshots and crash context before a release.
• A support email is for problems that need a private, one-to-one answer.
• App Store reviews are public and hard to act on, but they show you what strangers think.

1. An in-app feedback board

A board is a list of requests inside your app. Anyone can add an idea, and everyone else can vote for it instead of writing the same thing again. That one change turns two hundred scattered emails into a ranked list with a count next to each item.

A board works best for feature requests and improvements, the "could you add…?" kind of feedback. It is less useful for urgent bugs, where the person needs help now rather than a vote. It also needs a little care from you: if requests sit in Pending for months, people stop posting. Change statuses as work moves, and reply on the request when you have something to say.

If you are new to the idea of shipping a board as part of your app, What is a feedback SDK? explains how the pieces fit together, and How to choose an in-app feature request tool for your iOS app lists the questions to ask before you pick one.

Where to put it

Put the board where people already look for help: a "Feature requests" row in Settings, an item in the help menu, or a button on an empty state. A board three screens deep in an "About" page will be found by almost nobody.

2. A prompt at the right moment

Timing matters more than wording. Ask straight after a moment of success, such as finishing a hike in Trailmate, our fictional hiking app, exporting a file or completing a level. Do not ask on launch, during onboarding or while someone is in the middle of a task.

Apple gives the same advice for rating requests. Its Ratings, reviews, and responses page, as of 7 May 2026, says to ask when people are most likely to feel satisfied, and that the SKStoreReviewController prompt can be shown up to three times in a 365-day period. Our guide to SKStoreReviewController covers that API in detail.

A rating prompt and a feedback prompt do different jobs. A rating helps your App Store page. A feedback prompt helps your roadmap. A good pattern is a small, dismissible question ("Anything you wish Trailmate did?") that opens your request form, shown no more than once every few weeks.

3. TestFlight

Beta testers are the people most willing to give detailed feedback, and TestFlight makes it easy for them. Apple's TestFlight page, as of 7 May 2026, says testers can take a screenshot in your app, mark it up and send it as feedback, and that a crash gives you a report with optional context from the tester. You read it all in the TestFlight section of App Store Connect. External testing goes up to 10,000 testers.

TestFlight is the right channel for "this screen broke" and "this flow confused me" in a build you have not released yet. It is a poor channel for long-term feature requests: the feedback stays with the build, other testers cannot vote on it, and your App Store users never see TestFlight. See TestFlight feedback for how to get more out of it.

4. A support email address

Some feedback is private: a billing question, a lost account, a bug that involves someone's own data. Email is still the best tool for that. Apple's ratings page also asks you to make your support contact easy to find in your app and on your product page, so unhappy users reach you before they reach the review box.

The weakness of email is that every request lives in one inbox and one head. When the same idea arrives for the tenth time, you have no count and the tenth person has no idea nine others asked. When an email is really a feature request, reply, then point the person to your board so their vote counts.

5. App Store reviews

Reviews are honest and public, and they reach you from people who would never email. They are also short, anonymous and hard to follow up on. You can reply to them in App Store Connect, and the reviewer is notified when you do. Our guide on replying to App Store reviews covers how to write those replies.

Treat reviews as a signal, not a backlog. When a review asks for a feature, add it to your board yourself or reply to tell the reviewer where they can vote.

Which channel for which job

Most apps need all five. The trick is to send each one to the right place, and to make the board the place where feature requests end up, whichever door they came in through.

How FeedbackKit fits in

FeedbackKit is the in-app board part of this picture. The Swift SDK installs with Swift Package Manager and gives you ready-made SwiftUI screens for the request list, the submit form and the detail view with votes and comments. It supports iOS, macOS and visionOS 26 or later. Setup is in the Swift docs.

Configure it once when your app starts, then show the board wherever it fits:

import SwiftUI
import SwiftlyFeedbackKit

@main
struct TrailmateApp: App {
    init() {
        #if DEBUG
        SwiftlyFeedback.configure(environment: .development, key: "your-dev-key")
        #else
        SwiftlyFeedback.configure(environment: .production, key: "your-prod-key")
        #endif
    }

    var body: some Scene {
        WindowGroup { ContentView() }
    }
}

struct SettingsView: View {
    @State private var showingBoard = false

    var body: some View {
        Button("Feature requests") { showingBoard = true }
            .sheet(isPresented: $showingBoard) {
                FeedbackListView()
            }
    }
}

For the prompt at the right moment, present the submit form on its own, for example after a hike is saved:

.sheet(isPresented: $askForIdea) {
    SubmitFeedbackView { askForIdea = false }
}

Users vote and comment inside your app, and a new request starts with its submitter's vote. If you know who the user is and what they pay, pass it on with SwiftlyFeedback.updateUser(customID:) and SwiftlyFeedback.updateUser(payment: .monthly(4.99)), so you can later sort requests by the total MRR of the users behind them. The same board is reachable from Android, Flutter and React Native apps through the Kotlin, Flutter and React Native SDKs.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

FeedbackKit does not replace TestFlight, your support inbox or App Store reviews. It gives the feature requests from all of them one place to land, where people can vote. Plans are on the pricing page.

Pick one place in your app this week and put the board there. Start free and see what your users ask for.