What's New in Swift SDK 1.2

Swift SDK 1.2 is the release that follows Swift SDK 1.1.1, and most of it is visible: the list gains search and proper loading and error states, and the detail screen is rebuilt with native controls. It also renames and removes public API.

This release was originally tagged 2.0.0 on 14 October 2026 and renumbered on 17 October 2026 as 1.2.0, and it contains source-breaking changes despite the minor version number (the migration notes list each one).

The short version

• New: search in the list, with status and category suggestions.
• New: loading placeholders, an error screen with Try Again, and a remembered sort order.
• Changed: the detail screen uses native list controls, titles itself with the request, and has a Share button.
• Breaking: buttons.segmentedControl is now buttons.statusFilter, status and category colours are ThemeColor, and a few unused properties and strings are gone.
• Upgrade note: Swift SDK 1.3 was tagged later the same day and fixes defects that 1.2 still carries. Read the upgrade section before you pin 1.2.

What is new

Search

The list has a search field that matches titles and descriptions. As you type, it suggests status and category tokens, so "In Progress" or "Bug Report" can narrow the results along with the text. When nothing matches, a No Results screen offers to clear the search.

Loading, errors and a remembered sort

The list shows placeholder cards while it loads, after a short grace period so a fast load does not flash them. A refresh over a list that is already showing gets a small indicator at the top. A failed load shows "Couldn't Load Feedback" with a Try Again button, instead of an alert over an empty screen, and a rejected API key shows a configuration screen that also offers Try Again. The sort you choose, by votes, newest, oldest or comments, is saved in UserDefaults and restored the next time the list opens. List animations respect Reduce Motion.

A rebuilt detail screen

FeedbackDetailView now uses an inset list with labelled status and category rows, a compact vote button and a system comment field. Its navigation title is the request's own title instead of "Details". A Share button shares the title and description. Comments load as placeholder rows, refresh with a pull on iPhone and iPad or Command-R on the Mac, and show an empty state when there are none.

Smaller changes

• Feedback written in another language can be translated on the device into the device language, on iOS and macOS.
• The list and the detail screen share one vote dialog, so voting from the list now offers the operational and marketing sub-toggles under the mailing-list opt-in too.
• The submit form disables its fields while sending, and while it is incomplete a caption names the missing field. VoiceOver reads the same reason on the Submit button.
• SwiftlyFeedbackError gives readable, localised descriptions for its presentable cases, such as "Invalid API key or unauthorized access".
• Vote and comment counts use proper plural forms in every language.
• The vote dialog's email field and toggles have VoiceOver labels and hints.
• ThemeColor is now Equatable and Hashable.

Breaking changes and how to migrate

segmentedControl is now statusFilter

The setting never controlled a segmented control: it shows or hides the Status picker in the toolbar menu. The name now says so.

// Swift SDK 1.1.1
SwiftlyFeedback.config.buttons.segmentedControl.display = false

// Swift SDK 1.2
SwiftlyFeedback.config.buttons.statusFilter.display = false

Status and category colours are ThemeColor

Each status and category colour used to be a plain Color. It is now a ThemeColor, like primaryColor, so badges can use a different colour in light and dark mode. Wrap existing values in .color(_:), or use .adaptive(light:dark:):

// Swift SDK 1.1.1
SwiftlyFeedback.theme.statusColors.testflight = .teal
SwiftlyFeedback.theme.categoryColors.featureRequest = .indigo

// Swift SDK 1.2
SwiftlyFeedback.theme.statusColors.testflight = .color(.teal)
SwiftlyFeedback.theme.categoryColors.featureRequest = .adaptive(light: .indigo, dark: .purple)

color(for:) on both types returns a ThemeColor too. Call resolve(for:) with a colour scheme to get a Color.

Removed

• theme.secondaryColor and theme.tertiaryColor. No view read them. Delete the lines.
• buttons.addButton.bottomPadding. No view read it either.
• From the public Strings enum: feedbackDetailTitle, commentsTitle, formDescriptionPlaceholder, sendButton, mailingListOptInDescription and errorFeedbackLimitTitle. The detail screen titles itself with the request, and the comments header is a plural count.

Feedback equality

This one compiles unchanged. In 1.1.1, two Feedback values were equal when their ids matched. In 1.2, == and hash(into:) compare the whole value, so a re-fetched request whose vote count changed is no longer equal to the copy you held. If you used Feedback as a dictionary key or relied on onChange ignoring content changes, key on feedback.id instead.

How FeedbackKit fits in

Search helps most on a busy board. The same project can collect requests from your Swift, Android, Flutter and React Native apps, and your team reads them in one list. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Upgrading, and why to go straight to 1.3

Swift SDK 1.3 was tagged later the same day, under an hour after 1.2. It fixes several defects that have been in the SDK since 1.0 and are still in 1.2:

• The Status picker in the list's menu, and getFeedback(status:) or getFeedback(category:) with any filter, fail with a not-found error. The query string is escaped into the path, so the server never sees a filter.
• updateUser(customID:) saves the new id but the running client keeps the old one until the next launch, so votes cast straight after sign-in still go to the anonymous id.
• With logging on, which is the default, request bodies, including emails, user ids and MRR, are written to the system log.

1.3 has breaking changes of its own, chiefly new names for config, theme and shared, but the old names keep compiling with a warning. If you are on 1.1.1 today, the simplest path is to apply the migrations above and then the ones in the 1.3 post, in one step. An Up to Next Major rule from 1.2.0 moves to 1.3.0 on the next package update. If you must stay on 1.2, pin Up to Next Minor Version from 1.2.0, and the notes for apps pinned to 1.2 cover workarounds for each defect, and the current SwiftUI tutorial covers 1.3. The reference is in the Swift SDK docs.

Every plan includes the Swift SDK. Start free and try the board in your next build.