The Swift Package SDK story: why we built voting where your users live
I built Shpd because I was tired of watching feature votes disappear into the void. Our users would click a web link, vote on Canny, and then forget about it entirely. One afternoon, a customer message landed in Slack: 'Why do I have to leave my app to tell you what I want?' That question broke something in me. We rewrote everything.
The web form problem nobody talks about
Here's the thing about web-based feedback tools: they work brilliantly if your users are already sitting at a laptop thinking about your app. But mobile app users? They're in motion. They're on the Tube. They're between meetings. They're not going to tap a link, navigate to a new browser tab, wait for a page to load, and vote on a feature request.
I watched this pattern repeat across three of our portfolio apps. Canny's integration was technically sound. But the funnel was leaky. Users would start the voting flow and drop off. We'd get tonnes of empty submissions. The voting board looked active but the data was noise.
The real insight came from talking to a studio running eight fitness apps. They said: 'Our users are voting inside their app for everything else. Why should feature feedback be different?' That's when we decided to build a native iOS SDK.
What a native SDK actually buys you
A native Swift Package isn't just a cosmetic choice. It changes the physics of how voting happens. Your app can show a feature board that feels native, that scrolls smoothly, that respects your design system. No WebView lag. No browser chrome. It's there in your app the same way a menu or a settings screen is there.
But the bigger win is context. When someone votes from inside your app, you know they're actively using it. You can time notifications better. You can show the voting board as a native sheet or modal. You can integrate it with push notifications so voters get alerted the moment their feature ships, without leaving the app.
We built the SDK so it takes about fifteen minutes to integrate. Drop it into your Xcode project. Configure your app ID. Add a voting button to your settings or menu. Done. The board lives in your app, and voter data flows back to your dashboard in real time.
Scaling voting across your entire portfolio
Once the iOS SDK was working, a different challenge emerged. If you run multiple apps, and each one has its own voting board, voters get fragmented. Someone votes for 'dark mode' in App A, then votes for the same thing in App B, and you've got duplicate requests across separate islands. Or worse, you don't know it's the same person voting twice.
We built Passport. It's a cross-app voter identity layer. One person, one identity, across every app in your studio. They log in once and their votes synchronise. When a feature ships, they get a single notification that says 'Your request in App A is live,' not five separate messages.
This sounds simple but it's the difference between managing feedback at portfolio scale and drowning in noise. A studio with ten apps can now see which features are genuinely popular across the whole suite, not just loud in one app.
The moment it clicked: real data from real studios
Our first customer to ship the iOS SDK was running four meditation apps. Within two weeks they had 340 votes on the voting board. Not clicks. Not impressions. Actual, substantive votes from real users in the app. The engagement rate was sixteen times higher than their old web form ever achieved.
That same studio also had Attribr hooked up to their Scale plan, so they could see which voters were actually active users versus people who'd opened the app once and forgotten about it. Turns out their most valuable features were being voted for by their long-tail retention cohort, not their power users. They would have missed that entirely with a generic feedback tool.
Another customer, a gaming studio with nine apps, used the cross-app Passport to identify a feature that appeared in four separate voting boards. When they shipped it, 840 voters got a notification at the exact moment the feature went live. Forty-three per cent of them opened the app that day to check it out.
Why this matters more than it sounds
The reason I'm telling you all this isn't to boast. It's because mobile app studios have been using tools built for web feedback forms. Canny is solid software, but it's not built for studios shipping multiple apps where voting happens inside the product, not outside it.
When we built the native iOS SDK and the Android Kotlin library, we weren't trying to be different for its own sake. We were solving a specific problem: studios with two to thirty apps need their users to vote where they actually are, which is inside the app. And when users vote from inside your app, you get real data, not web form noise.
The Swift Package also means no App Store review headaches. No StoreKit complications. No markup on in-app purchases for voting. Just a native component that integrates like any other framework you'd add to a project.
If you're building multiple apps and your feature voting is happening in a separate web dashboard, ask yourself: are your users actually engaged, or are they just abandoning the form? That question changed everything for us.