FeedbackKit vs ChatKit: Chat Inbox or Feature-Request Board

ChatKit and FeedbackKit both sit inside an iOS app and both bring you what users think. That is where the overlap ends. ChatKit is a private chat: a user types a message, you reply, and nobody else sees the thread. FeedbackKit is a shared board: users post feature requests, see each other's, vote and comment, and you move each request through a status. This post is less "which is better" and more "which problem do you have", with a section on using both.

We make FeedbackKit, so read this with that in mind. The ChatKit we mean is the in-app chat SDK at trychatkit.com, not OpenAI's ChatKit or other products with the same name. Every ChatKit fact below comes from that site, checked on 17 October 2026. The site names no company or maker, and its footer reads "© ChatKit". Its /pricing and /docs pages returned "not found" when we checked, so what follows is what the homepage says. The side-by-side table is on FeedbackKit vs ChatKit.

The short version

• ChatKit is a one-to-one in-app chat inbox for iOS apps. You add a Swift package, place a SwiftUI ChatKitView on a screen, and reply to users from ChatKit's web inbox. There are no servers to run.
• FeedbackKit is a feature-request board with voting, inside your app, on iOS, macOS, visionOS, Android, Flutter and React Native. Requests have statuses, can be ranked by the MRR of the users behind them, and sync to issue trackers on Pro and up.
• FeedbackKit has no chat or support inbox. ChatKit has no voting or statuses. If you need both jobs done, you need both kinds of tool.

What each one is for

ChatKit's homepage describes a simple setup. Add the Swift package in Xcode, call configure once with your API key, and put ChatKitView inside a NavigationStack. Messages arrive in one inbox in real time, you reply there, and the user sees your reply inside the app. Each device gets its own thread, with no sign-in code or user IDs to manage. The site pitches it at indie apps and small teams, and says plainly that it is not meant for high-volume support with macros, SLAs or ticket routing. It lists iOS and no other platform, and no API or webhooks.

A chat is good at things a board is bad at. A user with a bug can describe it in their own words, you can ask a follow-up question, and the conversation stays private. People will tell you things in a chat they would never post publicly.

A board is good at a different thing: showing demand. In a chat inbox, ten users asking for offline maps arrive as ten separate threads, and you have to keep the count yourself. On a FeedbackKit board, they find the existing request and vote on it. In Trailmate, our fictional hiking app, that is how Offline maps reaches 248 votes and Trail difficulty filter 131, and each new request starts with its submitter's vote. Users can comment on a request to say why they want it, and the whole team sees the same ranked list.

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

Platforms and SDKs

ChatKit lists a native Swift package for iOS, shown with a SwiftUI screen. Its site lists no Android, Flutter, React Native or JavaScript SDK, and does not state a minimum iOS version.

FeedbackKit has native SDKs for Swift and SwiftUI (iOS, macOS and visionOS), Kotlin with Jetpack Compose (Android), Flutter and React Native, each with ready-made screens. JavaScript for the web is a headless client with no screens, and there is a Vapor SDK and a REST API. Docs: Swift, Kotlin, Flutter, React Native.

One caveat from our side: the Swift SDK needs iOS 26, macOS 26 or visionOS 26 or later, with no watchOS or tvOS. If your app supports older iOS versions, check that before you plan around it.

Managing what comes in

ChatKit's inbox holds conversations. Its site describes no statuses, tags, assignments or prioritisation, which fits a tool meant for small teams replying by hand.

FeedbackKit is built around triage. Each request has one of six statuses: Pending, Approved, In Progress, TestFlight, Completed and Rejected. Voting stops on Completed and Rejected. On every plan your app passes each user's MRR through the SDK, and you can sort requests by the total MRR of the users behind them. You can merge duplicates, counting each voter once, and work from the web dashboard or the native admin apps for iPhone, iPad and Mac. On Pro and up a request can become an issue in GitHub, Linear, Notion, ClickUp, Monday.com, Trello, Airtable, Asana or Basecamp, with status sync. There is no Jira, Zapier or Make. The details are on the integrations page.

Closing the loop

In ChatKit, you close the loop by replying in the thread, and the user sees it inside the app. That is personal, and it works well while the number of conversations stays small.

FeedbackKit closes the loop when a request changes status. A new project emails on Approved, In Progress, Completed and Rejected. The person who submitted the request gets that email on every plan; choosing which statuses send it needs Pro, and emailing voters who opted in needs Team. A Rejected request can carry a reason that goes into the email. Your team gets email for new requests on every plan, and push for new requests and new comments in the FeedbackKit app. New-comment email to the team needs Pro, and Slack is on Pro and up. Your app's users get status email, never push. For how the rules work, see our post on status emails.

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

Pricing

ChatKit's homepage says "Free to start" and has a "Get started for free" button. It publishes no plan names, limits or paid prices, and its pricing page returned "not found" on 17 October 2026. If cost matters to your decision, ask ChatKit what its paid plans will cost before you build around it.

FeedbackKit's prices are on our pricing page, in US dollars:

No FeedbackKit plan limits how many of your users vote. On Free, items past the cap of 10 are saved but hidden from the board. Yearly billing saves about 17%.

Using both

Chat and a board do not compete for the same moment, so plenty of app teams could run both. A sensible split looks like this:

• Chat for the personal things: bug reports, account questions, and anything a user would rather not post where others can see it.
• The board for ideas: when a chat turns into "it would be great if…", point the user to the request board in your app so they can post it, and others can vote on it.
• Status emails for the follow-up: when that request moves to Completed, the person who posted it hears about it without you digging out an old thread.

The cost is two SDKs and two places to check. If you are a solo developer with a small audience, chat alone may be enough for now. If requests are piling up and you cannot tell which ones matter most, a board is the missing piece. Our guide to in-app chat on iOS covers the chat side in more depth.

So which one

Choose ChatKit if you want private, one-to-one conversations with your users rather than a shared list of requests. Choose it if your app is iOS alone and you want one SwiftUI screen and an API key, or if you would rather reply to each message personally than ask users to vote.

Choose FeedbackKit if you want users to see each other's requests, vote and comment, so demand is visible instead of spread across private threads. Choose it if you also ship on macOS, Android, Flutter or React Native, or if you want requests ranked by MRR, statuses users can follow, and issue-tracker sync with GitHub, Linear and others (Pro and up).

For other chat and feedback tools, see our ChatKit alternatives post. To put a voting board in your own app: Start free.