Why we built native SDKs instead of web forms
Last month, a studio with eleven iOS apps sent us a Slack message: 'Your SDK saved us from having to explain to users why they're leaving the app to vote.' That sentence stuck with me. It captures something we learned the hard way when we started building Shpd.
The moment we realised web forms were leaking votes
When you ask a user to leave your app to vote on a feature, you've already lost half the battle. The friction is real. They tap the link, hit a login screen, fill in their email, wait for a verification code, and by the time they get to the voting board, the momentum is gone. Some come back. Most don't.
We watched this happen with Canny implementations across app studios. Feature requests sat there gathering dust. Voter counts plateaued. Engagement dropped month on month. The studios weren't bad at product management; they were fighting physics. People vote when voting is frictionless. If voting requires leaving the app, opening a browser, and logging into another service, it stops being impulse. It becomes a chore.
That's when we decided: voting needs to live where users already are. Inside the app. Native. Fast. Instant.
Why native means you don't need a password
The iOS SDK is a Swift Package. The Android one is a Kotlin library. Drop them in, and users can vote with zero setup. No email field. No password. No verification codes. Just open the voting board, tap a feature, and your vote registers instantly with their existing app identity.
This sounds simple until you think about the cascade of friction it removes. A user doesn't have to remember another login. They don't have to worry about password reuse. They don't have to trust a web form with personal information. The studio doesn't have to manage GDPR consent flows or password resets. The voting board doesn't sit behind a login wall; it's just there.
We built Passport, our cross-app identity layer, so that one voter can participate across every app in a studio's portfolio without logging in twice. They vote in your fitness app, your photo editor, your music player, all under one voter identity. That's not possible with a web form sitting on a separate domain.
The push notification moment
Here's the feature that made studios genuinely angry they'd been using web forms: when a feature ships, voters get a push notification. Not an email. A push. The moment your feature is live, they know.
You can't do that from a web form. You can't send a push notification to someone who voted on a website. You can only email them, and email lives in the email graveyard. But if voting happens inside your app, you control the entire loop. Feature goes live. Your backend triggers a webhook. The native SDK sends a push to everyone who voted. Users open the app and see their feature is here.
This isn't magic. It's consequence. Native lets you close the feedback loop in real time, instead of hoping voters check their email every week.
What a studio with eleven apps actually needs
That studio we mentioned earlier isn't unusual. Mobile app studios often have between five and thirty released apps. Each one has its own user base. Each one collects feature requests in the wild.
If you're using web forms, you need eleven separate voting boards, or you need to explain to users why they're voting on iOS requests in your photo app. Neither works. With a native SDK and cross-app identity, you can have one unified voting board that your entire portfolio contributes to. A user votes in your fitness app and sees that someone in your music player voted on the same feature. Context builds. Confidence in the product direction builds.
The other thing that matters: billing. We use Stripe, not the App Store. A studio with eleven apps doesn't want to be charged per app per month. They want to know the unit economics are honest. One team, unlimited apps, one invoice. That's how Shpd scales with you.
The form that actually survives contact with users
We're not saying web forms are wrong in general. They're fine for signups, contact forms, surveys that live outside your product. But for voting on features inside an app, they create a discontinuity. Users experience a jarring transition. The app vanishes. A browser tab opens. A form appears. None of it feels like part of your product.
A native voting board feels like your product because it is. It shares your app's design language. It respects your app's permissions. It loads instantly. It works offline and syncs when the connection returns. When a user votes, they're not filling out a form; they're participating in the roadmap they use every day.
We built Shpd for studios that ship regularly across iOS and Android. Studios that want to hear from users without friction. Studios that want to know, without guesswork, which features their voters actually want and when those features land.
If your users are leaving your app to vote, what are they telling you about the experience you've built?
Ready to try Shpd by MRVL?
One tap to download. No sign-up wall.