How to Add a Feedback Board and Changelog to Your iOS Swift App

Most feedback tools — Canny, UserVoice, Featurebase — are web-first. To put them inside an iOS app you end up wrapping a WKWebView, which feels slow, breaks dark mode, and never quite matches your UI. Features.Vote ships a native Swift SDK instead: drop-in SwiftUI views for a feature request board, feature voting, an in-app changelog, and a public roadmap — for iOS 16+, iPadOS, and macOS 12+, with zero external dependencies.

This guide walks through adding a feedback board and a changelog to your SwiftUI app. Watch the full walkthrough, then follow the steps below.

What you'll build

A feature request board where users submit and upvote ideas (VotingBoardView)
Feature voting — let users vote on features directly in your app
A native in-app changelog / "What's New" screen (ChangelogView)
Optionally, a public roadmap embedded in your app (RoadmapView)

All native SwiftUI — no WebView, no JavaScript bridge.

Step 1: Install the SDK (Swift Package Manager)

In Xcode, go to File → Add Package Dependencies… and paste the Features.Vote SDK repository URL, or add it to your Package.swift:

dependencies: [
    .package(url: "https://github.com/features-vote/features-vote-sdk", from: "1.0.0")
]

Then import FeaturesVote wherever you need it.

Step 2: Configure your project key

Initialize the SDK once at launch with your Features.Vote project key (find it in your project settings). Identify the current user so their votes and submissions are attributed correctly.

import SwiftUI
import FeaturesVote

@main
struct MyApp: App {
    init() {
        FeaturesVote.configure(projectKey: "your_project_key")
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

To attribute feedback to a known user, call one of:

FeaturesVote.updateUser(email: "jane@example.com")
// or
FeaturesVote.updateUser(customID: "user_123")

Step 3: Add the feedback board

Drop VotingBoardView into any screen — for example, behind a "Feedback" tab or a settings row. Users can browse existing requests, upvote the ones they want, and submit new ideas.

import SwiftUI
import FeaturesVote

struct FeedbackScreen: View {
    var body: some View {
        VotingBoardView()
            .navigationTitle("Feature Requests")
    }
}

That's the whole feature request board — submission, voting, and detail views are handled by the SDK and sync to your Features.Vote dashboard, where you can triage statuses (pending → under review → in progress → done).

Step 4: Add the in-app changelog

When you ship an update, show users what's new with ChangelogView. It renders the release notes you publish from your Features.Vote dashboard, so you never hard-code a "What's New" screen again.

import SwiftUI
import FeaturesVote

struct WhatsNewScreen: View {
    var body: some View {
        ChangelogView()
            .navigationTitle("What's New")
    }
}

A common pattern is to present this automatically the first time a user opens a new version — pair it with an @AppStorage version check so it only appears after an update, never on a fresh install.

Step 5 (optional): Add a public roadmap

If you want users to see what's coming, RoadmapView shows your roadmap columns the same way, fully native:

RoadmapView()
    .navigationTitle("Roadmap")

Why native instead of a WebView

It feels like your app. Native scrolling, dark mode, dynamic type, and your tint color — for free.
One backend for everything. Voting, roadmap, and changelog all sync to the same dashboard you use to manage feedback, publish releases, and notify users.
No iOS SDK from the incumbents. Canny, UserVoice, and Featurebase are web boards; embedding them means a WebView. A native Swift SDK is the differentiator.

Wrapping up

In a few lines of SwiftUI you've added a feedback board, feature voting, and an in-app changelog to your iOS app — all native. From here you can manage statuses, publish changelog releases, and route happy users to an App Store review while sending unhappy ones to your feedback board.