FeedbackKit vs WishKit: Choosing an In-App Feedback Tool

If you are weighing up an in-app feedback tool, WishKit and FeedbackKit will both come up, and they are not really the same shape of product. WishKit is a compact feature-request tool with deep roots in the Apple ecosystem: add the SDK, your users post and upvote wishes, you manage the list. FeedbackKit is a broader platform: six client SDKs, an embeddable web board, role-based team access, and sync into the issue tracker your team already works in.

That difference cuts both ways. If you ship an Apple-only app and want the smallest dependency that does the job, WishKit is a genuinely good answer, and there are specific cases below where it is the better one. This page is not going to claim otherwise.

A note on sourcing. Every WishKit fact here was checked against their own site and public repository on 12 August 2026; product pages change, so verify anything decision-critical at wishkit.io before you commit. Every FeedbackKit claim describes what ships today, gaps included.

Platform coverage

This is the clearest real difference, and the first place WishKit wins something.

WishKit's site describes iOS and web SDKs, and their iOS SDK repository states support for iOS 16+, macOS 13+, visionOS 1+, watchOS 10+ and tvOS 17+, under an MIT licence. That is a wide Apple net: two platforms FeedbackKit's Swift SDK does not cover at all, and an OS-version floor several years lower than ours.

FeedbackKit spreads sideways instead of backwards. There are six SDKs — Swift, JavaScript, React Native, Flutter, Kotlin for Android, and a server-side Vapor SDK — but the Swift package declares iOS 26, macOS 26 and visionOS 26, with no watchOS or tvOS target.

Three honest caveats on our side of that table. First, "not stated in the sources checked" means exactly that — a marketing page is not a full inventory, and you should ask WishKit rather than assume. Second, our JavaScript SDK is a headless API client: it gives you feedback, votes, comments, users and events as typed calls, but it ships no prebuilt UI. The ready-made web surface is the server-rendered embed, not a JS component library. Third, if your Apple deployment target is anything below this year's releases, our Swift SDK is simply not an option for you, and no amount of breadth elsewhere fixes that.

SDK docs, if you want to read before you install: Swift, JavaScript, React Native, Kotlin, Flutter.

Getting feedback into the workflow you already have

A feedback board that nobody on the engineering side reads is a very expensive suggestion box. The question that matters is what happens after a request gets votes.

FeedbackKit creates and links tickets in nine trackers: GitHub, Notion, ClickUp, Linear, Monday.com, Trello, Airtable, Asana and Basecamp. Each supports single and bulk creation, and stores a link back to the created item. Slack is supported for notifications, and HubSpot, Salesforce and Email Campaign for contact and campaign sync rather than tickets.

What we will not tell you is that those nine behave identically, because they do not. The route shape is uniform; the ongoing sync is not:

• Status sync works across all nine, though the mechanism differs — a named workflow state in Linear or Notion, an open/closed flip on a GitHub issue, a completed flag in Basecamp, a card move in Trello.
• Comment sync works on eight of the nine. GitHub does not have it. That is a real capability gap, not a setting you can switch on: comments posted on a FeedbackKit item do not appear on the linked GitHub issue. If your team lives in GitHub and expects two-way discussion, know this before you pick us.
• Vote-count sync is narrower still — ClickUp, Notion, Monday.com, Airtable and Asana can carry a vote count into a field. Linear, Trello, Basecamp and GitHub cannot.
• Trello status sync only moves a card where you have mapped a target list for that status.

The full per-provider matrix is on the integrations page. Check your specific tracker there rather than trusting the headline count of nine.

On WishKit's side: the features named on their site are Edit & Merge, Capture from X, User Comments, User Notifications, User Segmentation, Priority Support and Remove Watermark. Issue-tracker sync is not among the features named on the pages I checked — but absence from a marketing list is not proof of absence, and I am not going to present it as such. If tracker integration is your deciding factor, ask them directly.

Triage mechanics

Both products can merge duplicates — WishKit names Edit & Merge as a feature, and comments and user notifications too. So this is not a section where we have something and they have nothing. What I can do is describe how FeedbackKit's mechanics work concretely, and leave the comparison to you, since I have not tested theirs.

Merging in FeedbackKit moves votes from the duplicates onto the surviving item, de-duplicated by user, so one person who voted on three phrasings of the same request still counts once. Comments move across prefixed with the title they came from, so context survives. The vote total is then recalculated from the actual distinct voters rather than summed.

Items move through six statuses — pending, approved, in_progress, testflight, completed and rejected — and which of those a project exposes is configurable rather than fixed. Voting is blocked once something reaches completed or rejected, which stops a shipped or declined item from quietly accumulating votes that no longer mean anything, and archived projects go read-only rather than disappearing. Submitting feedback also casts a vote for the person who submitted it, on the reasoning that writing the request is a stronger signal than clicking an arrow.

The team-shaped parts are Owner, Admin, Member and Viewer roles per project, a public roadmap, and a catalog of apps using the platform.

Pricing

WishKit publishes their prices, so I can quote them: Free Forever at $0/month for one project and five feature requests; Premium at $15/month, or $12.50/month billed yearly, for two projects and unlimited feature requests; Enterprise at $39/month, or $32.50/month billed yearly, for unlimited projects. Priority Support and Remove Watermark appear among their paid features.

FeedbackKit has Free, Pro and Team tiers, which differ on how many projects you get, how much feedback per project, whether you can add team members, and whether integrations are available at all — integrations and configurable statuses are paid capabilities, not free ones. Our current figures live on the pricing page. I am deliberately not putting the two side by side here: the tiers bundle different things, and a table that lines up two numbers would imply a like-for-like comparison that does not exist. Compare the capability you actually need first, then look at what each costs.

So which one

Choose WishKit if your app is Apple-only and you need to support OS versions older than this year's — iOS 16, macOS 13, watchOS 10 and tvOS 17 are all within their range and outside our Swift SDK's. Choose it if you ship on watchOS or tvOS at all, where we have nothing to offer. Choose it if you want one small, MIT-licensed dependency and a feature-request board, and would rather not adopt a platform with roles, tiers and thirteen integrations you did not ask for. And choose it if a published price you can evaluate in sixty seconds matters to how you buy.

Choose FeedbackKit if you ship on more than one platform and want the same feedback board behind an iOS app, an Android app and a website. Choose it if feedback needs to become a ticket in Linear, Notion, ClickUp, Asana or Airtable without someone retyping it — checking our matrix first for your tracker. Choose it if several people triage, so per-project roles matter, or if merge semantics and status rules are the difference between a board you trust and a board you stop opening.

If you are still undecided, the cheapest next step is to read both sets of docs and install whichever looks lighter. Ours are at /docs, and WishKit's are linked from their site. We would rather you chose correctly than chose us.