How we built FeedbackKit is a smaller story than a launch post usually tells, because the interesting constraint is not a feature list. The product lives inside someone else's app. We do not choose their UI framework, their navigation, or their privacy posture. Everything public about the product follows from that.
One model, one SDK per host
A person using a customer's app can submit a feature request, vote, comment, and see a status. The Swift SDK README names the statuses as pending, approved, in progress and completed, and it names categories for feature requests, bugs and improvements. Duplicate items can be merged from the admin side. A rejection can carry a reason the person in the app can read. That is the model.
The model is not the screen. The Swift package is for iOS, macOS and visionOS, and the README is explicit that there is no watchOS or tvOS target. Drop-in SwiftUI views cover the list, the form and the detail. Configuration is an environment plus an API key:
import SwiftlyFeedbackKit
SwiftlyFeedback.configure(
environment: .development,
key: "your-dev-api-key"
).sheet(isPresented: $showFeedback) {
FeedbackListView()
}The same README publishes the other clients as separate packages, not as a mode flag inside the Swift one: JavaScript on npm, React Native on npm, Flutter on pub.dev, and Kotlin on Maven Central. Beside those, the product page lists a Vapor SDK and a Hummingbird SDK. A server-side Swift app can talk to the same API without embedding a mobile UI. We work in both of those frameworks, which is also why the article that shares this date refuses to end with "use what we use".
The published tags on that repository are 1.0.0, 1.1.0, 1.1.1, 2.0.0 and 3.0.0. The current README describes 3.0.0 and points at a migration document for the older tags. The product kept its name. It did not become a new package every time the API moved. There is no 1.0.1 tag and no 2.1.0 tag. I am not filling those gaps with a story.
The admin app is ours, so it is native
The other half of the product is the admin app, where a product team triages what came in. That app is ours, so the native-or-cross-platform choice went the other way: SwiftUI on the Mac, on iPad and on iPhone. The screens we publish show a home dashboard with counts of projects, feedback, users, comments and votes, a single feedback item with its status tags and comment thread, and the project list on iPad and iPhone.
Feedback arrives in whatever language the writer thinks in. The translation we shipped in the admin app uses Apple's on-device Translation framework. That article covers session lifetime, batching and the visionOS trap. It is the AI-adjacent part of this product we are willing to describe in detail: not a chatbot bolted onto the SDK, but a triage queue that is multilingual because the people writing the requests are.
On-device translation with Apple's Translation framework
What the README says about where it talks
The Swift SDK's documented environments are local, development, TestFlight and production. Development, TestFlight and production point at api.dev.getfeedbackkit.com, api.testflight.getfeedbackkit.com and api.prod.getfeedbackkit.com. Keys come from the admin app and start with the prefix the README states, sf_. The product site is getfeedbackkit.com.
The product page also says the admin side has real-time analytics and more than ten tool integrations. This article does not name those tools. We have not listed them here, and a guessed list would be worse than none.
What we will not say about the building
A sister article about how we write operations software counts Claude co-author lines in the Swiftly Workspace repository and then says, on purpose, that it makes no measured claim about FeedbackKit. This post keeps that promise. I will not tell you what share of FeedbackKit a model wrote. The studio's native iOS work, including work I do myself, is mostly written with AI and reviewed by a person before it ships. That is a sentence about the offer on the home page. It is not a statistic about this repository.
Two earlier constraints still hold. The July article left out a minimum OS version because the marketing site and the package did not agree, so this one does not add a number either. And a library that stores anything does it inside the host app's container. The translation article says why that matters. A feedback SDK that quietly kept a copy of someone else's users would be rewriting the host's privacy posture.
If you want the loop in a SwiftUI app, the July article has the longer walkthrough. If you want the same model in a toolkit we do not own the screen for, the other SDKs are the public answer. Both are the same product, split at the point where the host app begins.
Comments
Loading comments…