WishKit Alternative for Android (2026)

WishKit is a solid in-app feature board — if your app lives on Apple platforms.

That is the whole problem.

WishKit’s SDK is iOS, iPadOS, macOS, visionOS, watchOS, tvOS. There is no Android package. No Kotlin artifact. No React Native or Flutter SDK. People still search “WishKit alternative for Android” because they liked the idea (users vote inside the app) and then hit a wall the week they ship a Play Store build.

This post is the practical version of that search. For the short version — pricing, a feature-by-feature table, and FAQs — see the WishKit alternative comparison page.

• Why a WebView is not an Android SDK
• What the usual workarounds cost you
• A side-by-side of tools that actually run on Android
• Working Kotlin (and Compose) setup so you can try it this afternoon

Why WishKit does not cover Android

WishKit’s job is specific: a native feature-request list inside an Apple app. Configure with an API key, present FeedbackListView, users submit and vote. Setup is fast. The UI feels like it belongs in Settings.

None of that ports.

If your product is:

• Android-only
• iOS + Android
• React Native
• Flutter

…you cannot drop WishKit in and call it done. You either skip Android users, wrap a website in a WebView, or run a second tool.

Skipping Android users is how you get Play reviews that say “I asked for this in the app and nobody heard me.”

What people try instead (and why it is messy)

1. Canny / Featurebase / Nolt in a WebView

This is the default suggestion in every “WishKit alternative” thread.

It works. Users can vote. You get a board.

It also means:

• Extra chrome (browser bars, login walls, cookie banners)
• Theme mismatch with your Android UI
• Offline = empty screen
• Device metadata is whatever the page can guess, not Build.MODEL + versionName
• App Review is usually fine, but the UX is the website you already have, stuffed into a screen

If your users already live on the web, fine. If they live in the app, you just added a second product they have to learn.

2. A second iOS-only SDK + a web board for Android

WishKit on iOS. Canny on Android.

Now you have two dashboards, two vote counts, and a roadmap argument every sprint because “iOS wants dark mode with 40 votes” and “Android wants it with 12,” and you cannot tell if that is 52 people or 30 people voting twice.

3. Email, Play reviews, and a Google Form

This is how most indie Android apps still collect requests.

Reviews are not a backlog. You cannot merge duplicates. You cannot tell a voter you shipped. You cannot hand the thread to Cursor.

4. Build the board yourself

A list, a vote column, a moderation queue, push when status changes. Easy for a weekend. Ugly by month three, when you need guest voting, rate limits, and “this user is on the Pro plan.”

If you like building infra, build it. If you want to ship the actual app, do not.

Native SDK vs WebView vs “just use WishKit”

WishKit is still the right pick if you will never touch Play. Do not switch for sport.

If Android is on the roadmap, pick a tool that has an artifact on Maven Central, not a URL you load in WebView.

What “native” has to mean on Android

Three checks. Fail one and you are back in WebView land.

1. The UI is Android UI. Views or Compose. Not https://your-board.canny.io inside a WebView.
2. Submissions carry app metadata. Package name, version code, device model, OS. Otherwise your agent (or you, at 1am) cannot reproduce the report.
3. Votes stay inside the app. If the user has to create a Canny account to upvote, most of them will not.

FeedbackJar’s Kotlin SDK does those three. Min SDK 21. com.feedbackjar:sdk. The SDK declares INTERNET itself. You do not add a permission for it.

Same board as iOS, React Native, Flutter, and the web widget. One dashboard. One vote count.

Add an in-app board to an Android app

Widget ID comes from the FeedbackJar dashboard after you start a trial.

1. Dependency

build.gradle.kts (app module):

dependencies {
    implementation("com.feedbackjar:sdk:1.5.1")
}

Maven Central is enough. No extra repo.

2. Init once

import com.feedbackjar.sdk.FeedbackJar

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        FeedbackJar.init(this, "your-widget-id")
    }
}

3. Show the prebuilt board

Views (no Compose, no Material, no RecyclerView pulled in):

import com.feedbackjar.sdk.ui.FeedbackJarView
import com.feedbackjar.sdk.ui.FeedbackJarActivity

// Full-screen activity shipped by the SDK
startActivity(FeedbackJarActivity.intent(this))

// Or embed the view
val board = FeedbackJarView(this)
board.setAccentColor(Color.parseColor("#e5484d"))
setContentView(board)

Compose (only resolves if your app already uses Compose — the AAR does not force Compose on you; it’s a compileOnly dependency of the SDK):

import com.feedbackjar.sdk.ui.compose.FeedbackJarBoard
import androidx.compose.ui.graphics.Color

FeedbackJarBoard(
    accentColor = Color(0xFFE5484D),
    boardId = "board-id" // optional: pin to one board
)

Both give you list → detail → new feedback, with voting and comments wired up, out of the box.

Put it on a Settings row. That is where people look when they want to complain. A floating button works too. A tab is overkill unless feedback is a core loop.

4. Identify the user (optional, do it)

FeedbackJar.setIdentity(name = user.name, email = user.email)

Cleared on logout with FeedbackJar.clearIdentity().

If you know the plan, attach it on submit so the board is not “47 votes” — it is “47 votes, including three Pro users.”

lifecycleScope.launch {
    FeedbackJar.submit(
        userText,
        properties = mapOf(
            "plan" to "pro",
            "flavor" to BuildConfig.FLAVOR
        )
    )
}

Every submit already includes Android version, device model, screen size, app version, and locale. You do not wire that yourself.

5. Confirm it landed

Open the app, submit “test from emulator,” open the FeedbackJar dashboard. If the post is there with device metadata, you are done.

Trial is 7 days, no card. Pricing starts at $9/mo and every plan includes the Android, iOS, RN, and Flutter SDKs plus the MCP server. You are not buying an Android add-on.

Docs: feedbackjar.com/docs/android SDK source: github.com/feedbackjar/kotlin-sdk

Same board on iOS (so you do not run two tools)

If you already liked WishKit’s “one view, one configure call” shape, the iOS package is the same idea.

import FeedbackJar
import SwiftUI

@main
struct MyApp: App {
    init() {
        FeedbackJar.configure(widgetId: "your-widget-id")
    }
}

struct FeedbackTab: View {
    var body: some View {
        FeedbackJarBoard()
    }
}

SPM: https://github.com/feedbackjar/swift-sdk

Android votes and iOS votes hit the same post. That is the point.

After the board exists: make something ship

A board that nobody closes is just a prettier inbox.

FeedbackJar’s difference vs WishKit is not “we also have Android.” It is that a coding agent can read the top-voted posts, pull the device metadata, mark the post Done, and notify every voter.

Flow that actually works:

1. User files a request in the Android board
2. You (or Cursor / Claude Code / Codex) ask the MCP server for the top open posts
3. Agent gets OS, app version, screen, the text — enough to reproduce
4. Fix ships, status flips to Done
5. Voters get the email instead of “any update on this?”

WishKit will help you see demand on iOS. It will not sit in the agent loop, and it will not see your Play users.

More on that loop: Close the feature request loop with MCP agents.

Other Android-capable options (short)

Not every team should pick the same tool.

• Instabug — Best if the job is crash + shake-to-report, not a public voting board. Sales-led pricing. Different category.
• Canny / Featurebase — Best if you are a web SaaS with a PM suite and mobile is a WebView you can live with.
• Build it — Fine for a prototype. You will rebuild voting, identity, and notify-on-ship.

If the job is “users vote inside iOS and Android, I want one backlog, I want the agent to close it,” that list collapses fast.

Frequently asked questions

Is there an official WishKit Android SDK?

No. WishKit is built for Apple platforms. Anything you see called a “WishKit Android alternative” is a different product, a WebView, or a custom board.

Will a Canny WebView pass Play review?

Usually yes. The issue is completion rate, not policy. People bounce when the page asks them to log in to vote.

Does an in-app feedback board hurt App Review / Play review?

A settings-row board that submits text and votes is normal product functionality. Do not collect data you do not declare. FeedbackJar’s guest voter id is a random UUID stored on-device, not an advertising or device id.

Can I keep WishKit on iOS and add FeedbackJar only on Android?

You can. You will regret the two backlogs. Migrate iOS to the same widget ID when you are ready.

Do I have to use the prebuilt UI?

No. FeedbackJar.submit(), listFeedback(), vote(), and comments are usable from your own Compose / Views screen. The prebuilt board is there so you are not designing a form on day one.

What metadata lands on each Android submission?

Android version, device model, screen size, app version, locale, plus any properties you pass (plan, flavor, screen name).

Bottom line

WishKit is not a bad tool. It is an iOS tool.

If you search “WishKit alternative for Android,” you do not need another comparison of Nolt and Frill. You need a Maven dependency, a Settings row, and one board that iOS can join later.

Add the SDK, submit one test post from an emulator, then decide.

Start a 7-day trial — no card. Same key works on Android, iOS, React Native, and Flutter.