Why we built a native Android Kotlin SDK instead of a web form
In October 2024, a studio with 12 apps across iOS and Android asked us a question that changed how we thought about the product. They said: 'Your iOS SDK is slick. But Android? We're still pointing voters to a web page. That's not a feature. That's a compromise.'
The Android question nobody else seemed to ask
Android gets the short end of the stick in B2B SaaS. Most product feedback platforms treat it as an afterthought: 'Here's an embedded web view. Ship it.' The reasoning is logical, cost wise. One codebase, one maintenance burden, one team. But here's the thing. An app studio with 6 iOS apps and 6 Android apps doesn't have half the problem. It has the full problem on both sides.
When we launched the iOS Swift Package SDK, we watched the data. Time to first vote dropped by 70%. Feature request quality improved. Comments became conversations instead of one-liners. The friction of leaving your app, finding a web page, logging in, voting. Gone. Users stayed in the experience they already knew.
The Android team at that studio was managing the exact same feature requests, the exact same roadmap decisions, with a friction wall between them and their own users. That imbalance bothered us. Not as a sales angle. As a design problem.
Building for the platform, not around it
Kotlin isn't a nice to have for Android. It's the language Google officially recommends. It's what modern Android developers expect. Reaching for Kotlin meant we had to build properly: native UI components, Material Design integration, proper lifecycle management, push notification hooks that don't feel bolted on.
That's harder than shipping a WebView. It means dealing with Fragment lifecycles, handling configuration changes, building against multiple Android API levels. It means testing on actual devices, not just in a browser. It means caring about things like battery drain and network efficiency in a way that a web form doesn't require you to.
But the payoff is immediate. When a user votes inside your app using our Kotlin SDK, it feels like part of your app. The notification when their feature ships? Native Android system notification. The voter identity across your portfolio of apps? The system permission and credential flow works the way Android developers built Android to work. No hacks. No workarounds.
Cross-app voting that actually works across platforms
Here's where native SDKs become essential. One of your studios has an iOS news app, an iOS fitness tracker, and two Android apps for different sports. A single user loves all four. With a web form approach, that user has to log in four separate times, or you're managing identity through some fragile token system.
Our Passport system runs on native credential storage. Your iOS voters use Keychain. Your Android voters use the Android Credential Manager. The voter participates across every app in your portfolio with a single sign. One identity, four apps, zero friction.
That matters for your analytics too. When you're building a roadmap across a portfolio, you want to see which features matter to the people who actually use multiple apps. Kotlin SDK users who vote in app A, then vote in app B two weeks later. They're real signals. They're not six separate web-form submissions from people who might be bots or test accounts.
The notification moment that changes behaviour
We launched push notifications at the same time as the Kotlin SDK. The moment a feature ships, voters get a native push notification on their Android device. Not an email. Not a dashboard they might check in a month. A notification.
The effect on retention is measurable. Studios report that voters come back to the app more often after shipping a feature they voted for. They engage with the comment threads. They see what other voters think about the implementation. The feedback loop closes in real time.
For Android specifically, push is where it gets interesting. Android handles notifications differently than iOS. Delivery is more immediate in some cases, configurable in others. The system is more flexible. A native implementation lets us use Android's notification channels, quiet hours, and priority levels without breaking the experience. A web form can't do any of that.
Why this matters as studios flee Canny
We've seen a wave of studios move away from Canny after their December 2025 price change. Most land here. What they say is consistent: 'We were paying per seat for a tool we barely customise, and our users still had to leave our app.' That equation never made sense for a mobile studio. You're selling an experience inside your app. Your feature feedback should live there too.
A Kotlin SDK isn't a sales feature. It's a design decision that says: Android users matter as much as iOS users. Your studio deserves tooling that works across both platforms without compromise. When we built it, we were thinking about your product manager on the Android team, who was tired of explaining why the voting experience was different from iOS. We were thinking about your Android users, who shouldn't feel like second-class citizens in your own feedback system.
The cost of building native is higher. The cost of not building native is passed on to your studios and your users in friction, in lost votes, in feedback that never quite closes the loop. We chose to absorb the cost.
If you're managing feature feedback across iOS and Android, ask yourself this: would your users spend one extra tap to vote on the features they want to see? Or would they skip it and just use your app?