Announcing the Quonfig Swift SDK

Quonfig now speaks Swift. There's a native SDK for iOS and macOS, it's shipping today, and you install it the way you install everything else in the Apple world now — Swift Package Manager:

.package(url: "https://github.com/quonfig/sdk-swift.git", from: "0.0.1")

Then import Quonfig and you're evaluating flags. It's the tenth SDK in the family, and like the JavaScript and React clients it's a frontend SDK: it fetches the server-evaluated config for a context, caches it, polls for updates, and reads typed values synchronously. Evaluation happens on the server, so there's no targeting engine to ship inside your app binary.

The 30-second version

import Quonfig

let quonfig = try await Quonfig.initialize(
    context: QuonfigContext([
        "user": ["key": .string("u_123"), "email": .string("a@example.com")],
        "device": ["mobile": .bool(true)],
    ]),
    options: .init(sdkKey: "YOUR_FRONTEND_SDK_KEY", domain: "quonfig.com")
)

// Synchronous, never-blocking reads — served from an in-memory snapshot.
if quonfig.isEnabled("new-checkout") { … }
let color = quonfig.string("button-color", default: "blue")
let limit = quonfig.int("rate-limit", default: 100)

initialize resolves once the first envelope is available — from the network, or, after a bounded timeout, from a cold-start cache or your supplied defaults. A hung network never hangs your UI. Reads are synchronous and never block; a not-yet-ready store just returns your default. And because it's SwiftUI-friendly, you can subscribe to live changes (diff-before-notify, so an unchanged poll doesn't churn your view).

The part I actually care about: dynamic log levels

If you've read this blog you know we're a little obsessed with logging. Quonfig started as a way to change log levels in production without a redeploy, and that idea does not get less useful when the "redeploy" is a multi-day App Store review.

So the Swift SDK ships a real logging integration — QuonfigLogger, built on Apple's unified logging (os.Logger):

let log = QuonfigLogger(quonfig: quonfig, loggerKey: "log-level.my-app")

log.debug("cache warm: \(count) entries")   // suppressed unless level <= DEBUG
log.error("checkout failed: \(err)")

The minimum level is a Quonfig log_level config. Flip it in the dashboard and the next log line on the device obeys the new threshold — no rebuild, no resubmission, no waiting on review. A support ticket comes in, you turn on DEBUG for that build, you read what you need, you turn it back off. Message arguments are autoclosures, so a suppressed line never pays to build its string.

This is the same pattern as our Go (slog) and Node (winston/pino) adapters, done the idiomatic Apple way — no third-party logging dependency, just the platform's own os.Logger.

Built the way an Apple SDK should be

A few things I insisted on:

• Zero external dependencies. Nothing in your dependency graph but Quonfig.
• Swift Concurrency throughout, compiled under StrictConcurrency=complete. The store is an actor; reads are lock-guarded and never hop the actor. It's clean under the thread sanitizer.
• A shipped App Store privacy manifest. PrivacyInfo.xcprivacy is wired into the package resources — not just sitting in the repo where it does nobody any good. The eval request's URLCache is disabled so the context-bearing URL never lands in an on-device cache.
• Cache-first, no flicker. Last-known values render instantly on cold start, and are served on a failed poll too, so a bad network keeps the last good config on screen instead of snapping to defaults.

One honest caveat, the same one LaunchDarkly and Statsig make: evaluation is server-side, so a brand-new context you've never seen can't be evaluated offline. A previously-seen context serves from cache; anything else falls back to your defaults.

Get it

.package(url: "https://github.com/quonfig/sdk-swift.git", from: "0.0.1")

Full docs — install, the typed getters, updateContext, the logger, the privacy details — are at docs.quonfig.com/docs/sdks/swift.

Next on the list for the Apple SDK: SSE push so updates arrive without polling, a SwiftUI ObservableObject wrapper, tvOS/watchOS, and an OpenFeature provider. But the core is here today, and I'd love for you to try it.