Why we built a native iOS Swift Package SDK (and why it matters)
Three weeks after launch, a studio founder messaged us. 'Your web voting board is clean,' she wrote, 'but my users will never leave the app to vote. Can we embed it?' That message sat in our Slack. We knew she was right.
The problem everyone else missed
If you've used Canny, ProductBoard, or most other feedback platforms, you know the pattern. A user finds a feature request, clicks a link, votes on a web page, leaves the app, forgets about it.
We watched studio founders fight this friction constantly. Their users had genuine ideas. But asking someone to leave your app, open a browser, hunt for a login, and vote on a separate domain felt like asking them to attend a meeting for a suggestion. The drop-off was brutal.
The real insight wasn't complicated. Mobile app studios don't have a user-feedback problem. They have a user-engagement problem. And no web form, no matter how well designed, solves that.
We could have built Shpd as a prettier web tool and called it done. Instead, we looked at what we actually knew: mobile. We're a UK app studio ourselves. We ship iOS and Android. So we asked ourselves a harder question: what if voting happened inside the app, with no redirect, no context switch, no friction?
Native wasn't a feature. It was the foundation.
Building a native iOS Swift Package meant rethinking everything. Not because native code is inherently better, but because it forced us to design for the mobile experience first, not bolt mobile onto a web-first architecture.
A voter can tap to vote and see the count update instantly. No page reload. No modal dialog. A notification lands on their phone the second their requested feature ships. They weren't told to check back later or visit a dashboard. The app told them directly.
We did the same for Android with a native Kotlin library. Both SDKs talk to the same backend, so a voter's identity travels across every app in a studio's portfolio. One person voting on a design feature in one app, a performance request in another. Their history follows them. We call it Passport.
This isn't marketing language. It's the difference between a voting tool and a feedback system that actually lives in the product experience where it belongs.
The SDK changed what a product roadmap could be
Here's what happened once studios had the SDK live: their voting boards became SEO-indexed pages that ranked for feature requests. Users could vote from inside the app, but the board itself lived on the web, searchable, shareable, persistent.
One studio told us their most-voted feature came from a user who found their roadmap through a Google search for a specific problem. Never used the app. Found the voting board. Voted. Downloaded the app three months later when the feature shipped and they got a push notification.
That's not a feedback tool outcome. That's a distribution channel.
The native SDK also meant we could build comment threads that didn't feel like afterthoughts. Studios could leave product notes directly on features. Voters could see context. And the whole thing worked on a 6-inch screen without a janky mobile web view.
Why this mattered for studios fleeing Canny
In December 2025, Canny announced a pricing change that rattled a lot of product teams. Some studios were paying reasonable amounts. Overnight, the math changed.
A fair number of them landed here. And we realised something: they didn't just want cheaper. They wanted the voting interface to actually sit inside their apps, where their users already were. They wanted cross-app identity so one voter could participate across their whole portfolio. They wanted push notifications that felt like part of the product, not a separate tool.
The native SDK became the thing that distinguished us. Not as a nice-to-have. As the thing that made Shpd feel like it belonged inside your app, not alongside it.
Billing through Stripe rather than the App Store helped too. No platform markup. Per-seat pricing that actually made sense. But the SDK is what made the difference in how studios thought about us.
What shipping native taught us about scale
Building two native SDKs meant we had to care deeply about backwards compatibility, small bundle sizes, and SDK update paths. These aren't flashy problems. But they're the difference between something studios can actually integrate and something that sits half-implemented in their codebase.
The SDK also meant we could ship features differently. A studio's users could vote for something on Monday. We could ship the feature by Friday. By Saturday morning, those voters had a push notification on their phones. No email broadcast. No in-app banner they might miss. A notification, from their app, saying 'That thing you asked for? It's here now.'
That feedback loop is tight enough that users actually feel heard. They're not waiting months to hear back. They're watching the roadmap move.
It also shaped how we thought about bigger studios with multiple apps. If Passport (our cross-app voter identity) didn't exist, a user voting across five apps would be five separate people. With it, one person voting on performance in one app, design in another, and backend architecture in a third. Studios could actually see what their audience cared about across their whole portfolio. That's a product insight you can't get from five separate web forms.
The decision we keep making
We could have taken the easy path. Build a web-first voting tool. Add a mobile web view. Call it done. Plenty of teams have done exactly that.
Instead, we keep choosing the harder path. We shipped the iOS SDK. Then Android. Then cross-app identity. Then push notifications tied to your actual release cycle. Each decision cost more than the shortcut. Each one also made Shpd feel less like a tool bolted onto your app and more like a natural part of how your users talk to you.
A year in, that choice looks right. Studios with five apps don't have to manage five separate voting communities. Users don't have to leave the app to be heard. Voters don't forget about features they requested because they get a notification when those features ship.
The native SDK wasn't a feature we added. It was the realisation that most feedback tools were built for the wrong context. They were built for web first. We built for mobile. That one decision changed everything about what Shpd could be.
If you've built mobile apps, you've probably thought about how to hear from your users better. The question isn't whether you need feedback. It's whether your feedback system lives in the same world as your users, or asks them to visit a different one to be heard. Which one do you think your users would actually prefer?