Requirements

Those platform floors come from Package.swift and are the real minimums. The SDK deliberately uses ObservableObject rather than the newer observation macros so it works below iOS 17.

Base URL

The client defaults to ContentFlowConfiguration.defaultBaseURL, and you should leave it alone:

https://app.contentflow.click/api/v1

Every request the SDK makes, the live-update stream included, carries the same four headers. They are built in one dictionary literal inside APIClient and nowhere else, with no conditional on any of them, so no code path can forget one.

Accept-Language is added whenever a locale is configured, on reads and writes alike. Neither this SDK nor the Kotlin SDK ever sends X-API-Key: both use X-CF-Key exclusively, even though the server accepts either.

The device id is a random UUID created once and stored in the Keychain, with a UserDefaults fallback where the Keychain is unavailable. It is never the IDFA, never identifierForVendor, and never a hardware identifier. Clearing app data or resetting the Keychain rotates it.

Environment comes from the key suffix

ContentFlowEnvironment.derived(fromKey:) reads the key and nothing else: a key ending exactly in _test is .test, everything else is .live. There is no environment argument, no environment field in any request body, and no way to flip one from the client. Test and live keys also get separate on-disk cache namespaces, so their content can never mix. Read the resolved value from client.environment.

Installation

Honest status first, because this matters more than the snippet.

Local package, Swift Package Manager

Point at your checkout of contentflow-sdk-swift. The package directory name is the package identity for a path dependency, so the package: label below matches the folder.

dependencies: [
    .package(path: "../contentflow-sdk-swift")
],
targets: [
    .target(
        name: "App",
        dependencies: [
            .product(name: "ContentFlow", package: "contentflow-sdk-swift")
        ]
    )
]

Local package, Xcode

1. Drag the contentflow-sdk-swift folder into your project navigator, or use File → Add Package Dependencies → Add Local.
2. In your target's General → Frameworks, Libraries, and Embedded Content, add the ContentFlow library product.
3. import ContentFlow.

Quickstart

Four things, in this order: register a renderer, start the client, place a slot, read fields by tag. Skipping the first one is the difference between a card on screen and an empty VStack.

1 · Bootstrap

import ContentFlow
import SwiftUI

@main
struct BankApp: App {
    init() {
        // 1. Tell the SDK what to draw for each placement.
        ContentFlow.registerRenderer(for: "home.discovery") { block in
            AnyView(DiscoveryCard(block: block))
        }

        // 2. Start it.
        ContentFlow.start(
            apiKey: "ws_a1b2c3d4_app",
            tenantId: "ws_a1b2c3d4",
            locale: .current
        )
    }

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

2 · Place a slot

struct HomeScreen: View {
    var body: some View {
        VStack {
            BalanceView(account: user.account)
            ContentFlowSlot(placement: "home.discovery")
            TransactionsView()
        }
    }
}

The slot renders cached content immediately, revalidates in the background, and keeps stale content on screen through a transient refresh failure. A placement with no published block renders EmptyView, never an error state. Adding more slots never adds another sync or another live connection.

3 · Read the fields

enum DiscoveryFields {
    static let title  = FieldKey<String>("#title_main", type: .text)
    static let image  = FieldKey<ContentImage>("#header_image", type: .image)
    static let price  = FieldKey<Decimal>("#price", type: .number)
}

struct DiscoveryCard: View {
    let block: ContentBlock

    var body: some View {
        VStack(alignment: .leading) {
            // Lenient: nil when the field is not published.
            if let title = try? block.value(for: DiscoveryFields.title) {
                Text(title)
            }
            // Strict: throws .fieldMissing or .unsupportedFieldValue.
            if let image = try? block.require(DiscoveryFields.image),
               let url = image.url {
                AsyncImage(url: url)
            }
        }
    }
}

The workspace is derived from the key, not configured

Marketing publishes this two-argument form, and it works, no tenant required:

ContentFlow.start(apiKey: "ws_a1b2c3d4_app", locale: .current)

A real key is shaped <tenantId>_app for live or <tenantId>_test for test, and this SDK strips exactly that suffix. The server is more forgiving than that: it strips _app or _test as well, and when neither one terminates the key it falls back to everything before the last underscore. The two rules agree on every well-formed key and part company on legacy ones, which is why the difference gets its own table below. The server does not require X-Tenant-Id on any /sdk/* call, which is what lets this overload reach the right workspace with no Info.plist entry and no environment variable; the SDK still sends the header on every request, as Requirements sets out. Nothing about this two-argument form is a trap.

Pinning the tenant explicitly is optional

Pass it if you would rather a mismatch fail loudly than silently trust whatever workspace the key resolves to:

ContentFlow.start(apiKey: "ws_a1b2c3d4_app", tenantId: "ws_a1b2c3d4", locale: .current)

A key this SDK refuses is not always a key the server refuses

The server's resolver and this SDK's resolver are not the same function, and the difference is visible from your app. The server strips _app or _test, then falls back to the text before the last underscore. The resolver behind start(apiKey:locale:) strips _app or _test and has no last-underscore fallback at all: anything else resolves to nothing, the client is left unconfigured, and the first call throws ContentFlowError.invalidConfiguration before a request is ever built. The Kotlin SDK implements the server's rule byte for byte instead. The same legacy key can therefore be stopped on iOS and dialled on Android.

Read the table this way: a legacy-shaped key that the server would resolve into a workspace id that does not exist is stopped client side on iOS and reaches the network on Android, where it comes back 404. Neither platform can reach a workspace the key does not name, so this is a difference in where the failure lands and what it is called, not in what is exposed. The Swift test suite asserts the divergence explicitly, with pk_live_abc as its named case.

Both the key and the workspace id come from Dashboard, Developers, "Your keys". Check ContentFlow.isStarted if you want a boolean: it is true only once start has been called with a configuration that actually validates.

Renderers are required, not optional

The payload carries content fields and their declared types. It carries no layout, no template identifier, and no rendering instructions. A field list cannot define a SwiftUI component, so ContentFlowSlot renders through a registry your app owns.

ContentFlow.registerRenderer(for: "home.discovery") { block in
    AnyView(DiscoveryCard(block: block))
}

Register during bootstrap, before or immediately after start. The closure is @MainActor and returns AnyView.

Inline renderers

For a one-off, pass the view builder to the slot instead of registering. This bypasses the registry entirely for that slot.

ContentFlowSlot(placement: "home.carousel") { block in
    VStack {
        ForEach(block.fields) { field in
            Text(field.value.displayText ?? field.tag)
        }
    }
}

Slot options

ContentFlowSlotModifier controls two things and nothing else.

.default is both on (fallback in DEBUG only). .silent is both off. Apps running more than one tenant can pass an explicit client: ContentFlowSlot(placement:client:modifier:).

Placement is exactly the block key

There is no placement abstraction in the wire protocol yet. ContentFlowSlot(placement: "home.discovery") reads /sdk/blocks/home.discovery, and the string you pass is the block type key verbatim.

• Placement strings are case sensitive.
• The SDK performs no normalization, prefixing, case conversion, or fallback matching.
• If your dashboard keys do not look like home.discovery, use whatever they actually are.

The renderer registry follows the same rule. Registering home.discovery and asking for Home.Discovery, home_discovery, or discovery resolves nothing. The package asserts exactly that, so it is a guarantee rather than a coincidence.

Fields are addressed by tag

On the wire, a block carries a values map keyed by tag, plus a fields schema array of { tag, type }. The SDK joins the two, so it renders by declared type instead of guessing from the tag name, and hands you a flat [ContentField]. Wire order is preserved on block.fields for debugging and generic rendering, but application code should never index into it: field order is not part of the contract, and a marketer reordering fields in the dashboard changes positions with no version bump you can react to.

Typed keys

Declare a FieldKey once, next to the screen that uses it. This is the whole type-safety story in v1: no code generation, no schema download, no build plugin.

// Explicit initializer
let title = FieldKey<String>("#title_main", type: .text)

// Or the named factories, which pick the type for you
let subtitle: FieldKey<String>        = .textarea("#body_copy")
let hero:     FieldKey<ContentImage>  = .image("#header_image")
let price:    FieldKey<Decimal>       = .number("#price")
let enabled:  FieldKey<Bool>          = .toggle("#enabled")
let variant:  FieldKey<String>        = .select("#variant")
let slides:   FieldKey<[ContentBlock]> = .collection("#slides")

Strict and lenient access

Both accessors live on ContentFieldContainer, which ContentBlock conforms to.

A type mismatch always emits a diagnostic as well as throwing, so a schema mistake surfaces as an error you can read rather than as UI that silently did not appear. Lookup is exact first; as a convenience the leading # is optional on the query, so field("#title") and field("title") resolve the same field. A duplicate tag resolves to the first occurrence and warns at decode time.

Field types

Seven types. Six are scalar; .collection is the one that holds a list, and its elements are ordinary ContentBlock values. A server type the SDK does not recognize decodes to ContentFieldValue.unknown(type:value:) with the raw JSON preserved, and warns. A value published with no schema entry is still surfaced, with its type inferred from the JSON kind, so content never disappears because a schema entry was missed. Neither case fails the block.

Collections: a card is a block

A field the dashboard declares as collection holds an ordered list of whole block instances, which the server inlines under the collection's tag. Each card arrives with its own key, instanceId, version, segment, values and field schema, and is decoded by the very same decoder that decodes a top-level block.

There is no Card type, no CollectionItem type and no second set of accessors. The model collapsed rather than grew: the only addition is that ContentFieldValue gained a .collection([ContentBlock]) case.

Reading one

collection(_:) lives on ContentFieldContainer, the protocol ContentBlock conforms to, so it is available on a wrapper and on a card alike.

func collection(_ tag: String) -> [ContentBlock]        // ContentFieldContainer
func element(at index: Int) -> ContentBlock?          // [ContentBlock]
func card(instanceId: String) -> ContentBlock?       // [ContentBlock]

collection(_:) never throws and never returns nil. An absent tag, a tag carrying something other than a collection, and a collection the server filtered down to nothing all read as an empty array, so you can iterate the result without unwrapping and a wrapper never draws list chrome around zero cards. Tag normalization is the same as field(_:): the leading # is optional on the query.

element(at:) is the bounds-safe positional read for the times you genuinely want "the third card". Position is a way of reaching a card, never its identity. card(instanceId:) is the identity lookup.

A carousel, end to end

Register a renderer for the card key and one for the wrapper key. ContentFlowCollection resolves each card through the registry entry for the card's own block key, so a wrapper's renderer never has to know how its children look.

enum CardFields {
    static let title = FieldKey<String>("#title", type: .text)
    static let image = FieldKey<ContentImage>("#image", type: .image)
}

// A card is a block, so it gets an ordinary renderer.
ContentFlow.registerRenderer(for: "reading_card") { AnyView(ReadingCard(block: $0)) }

ContentFlow.registerRenderer(for: "reading_carousel") { carousel in
    AnyView(
        VStack(alignment: .leading) {
            if let heading = try? carousel.value(for: FieldKey<String>("#heading", type: .text)) {
                Text(heading)
            }
            ScrollView(.horizontal) {
                HStack(spacing: 12) {
                    ContentFlowCollection(block: carousel, tag: "#slides")
                }
            }
        }
    )
}

struct ReadingCard: View {
    let block: ContentBlock

    var body: some View {
        VStack(alignment: .leading) {
            if let image = try? block.value(for: CardFields.image),
               let url = image.url {
                AsyncImage(url: url)
            }
            if let title = try? block.value(for: CardFields.title) {
                Text(title)
            }
        }
    }
}

Iterating yourself works just as well, and ContentBlock is Identifiable on instanceId, so ForEach keys correctly with no id: argument:

ForEach(carousel.collection("#slides")) { card in
    ReadingCard(block: card)          // id is card.instanceId
}

let thirdTitle = try? carousel
    .collection("#slides")
    .element(at: 2)?
    .value(for: CardFields.title)

The two SwiftUI views

showsDevelopmentFallback defaults to ContentFlowSlotModifier.isDebugBuild on both, matching ContentFlowSlot. Identity is the card's instanceId rather than the array position, so reordering slides moves views instead of rebuilding them.

Analytics

Track a card the way you track any block: EngagementEvent.impression(card, position: index), .tap(card), and the rest. Each builder copies the block's own instanceId, key and screen onto the event, so a card is the owner of its own metrics in every wrapper it appears in, with no extra wiring. Per card performance works out of the box.

Malformed cards degrade, they never fail the wrapper

• A collection value that is not an array reads as an empty collection.
• Inside the array a card is skipped when it is not an object, has no usable key, no usable instanceId, or no values map. One bad card never invalidates its siblings, and the survivors keep their delivered order.
• Nesting is capped at one level, matching the server, so a hand-built or stale payload cannot drive unbounded recursion. A collection nested deeper reads as empty.
• Every one of those emits a diagnostic, so the reason is readable rather than invisible.

Collection decoding is covered by the test suite: a collection of cards decoding through the very same block decoder as a top-level block, asserted by equality against the same raw object parsed standalone; card identity being instanceId rather than array position; a card's image getting identical treatment to a top-level image; malformed cards skipped while siblings survive in order; a non-array value reading as empty; the one-level nesting cap; and an event on a card carrying the card's own instanceId.

Repeaters were withdrawn, and replaced by collections

The withdrawn design stored a list's items as nested values inside a single block instance. That made every item a value rather than an entity, so an individual card could not carry its own segment targeting, its own schedule, its own approval state, its own A/B variants, or its own analytics. ContentFlow is instance centric and all of that machinery already exists at the instance level, so a list built out of values sat outside it.

A collection is that list expressed as a wrapper holding an ordered set of real block instances, so every card inherits all of it. In Swift that means FieldType.collection, ContentFieldValue.collection([ContentBlock]), collection(_:), and the two SwiftUI views. Nothing carries over from the old shape: declare FieldKey<[ContentBlock]>, not a repeater key, and expect whole blocks under the tag, never { id, values } items.

The platform-level explanation is at Blocks & fields, Collections.

Two different things are called version

They are unrelated. The block counter is never sent in If-None-Match, and the snapshot validator is never a revision number. The SDK keeps them apart for you, and both are surfaced so you never have to reconstruct either one. Weak ETags are stored and replayed verbatim, W/ and quotes included, and are never parsed.

Caching and offline behaviour

Stale-while-revalidate, by default, with a disk snapshot. The policy in full:

1. The last good disk snapshot is published immediately at start, before any network call.
2. The SDK revalidates using the stored ETag.
3. On 304 the cached body is kept and only the validation metadata is refreshed.
4. On 200 the snapshot and its ETag are replaced atomically.
5. On network failure the stale snapshot keeps serving. A failed refresh never clears good content.
6. A successful full sync is authoritative: blocks absent from it are removed. A network failure is never treated as evidence of deletion.

Details worth knowing when you are debugging:

• The cache namespace is a SHA-256 of the full API key, tenant, derived environment, and cache schema version. Locale is part of the filename. Live and test content therefore cannot mix.
• If-None-Match is sent only when the matching cached body actually exists. A 304 with a missing or corrupt body triggers one unconditional retry.
• Writes are atomic. A process kill mid-write leaves either the old snapshot or the new one, never a half file. Bodies are stored verbatim with a checksum, so a model change can never force-decode an old archive.
• A corrupt or schema-incompatible cache deletes only the affected ContentFlow namespace, emits a diagnostic, and falls through to the network. It never crashes startup.
• Identity traits, consent bodies, push tokens, and auth headers are never written into the content cache.

Refresh schedule

Controlled by SyncPolicy, which you pass through ContentFlowConfiguration.

SyncPolicy.manual turns all of it off, which is what you want in tests or in an app that drives its own schedule. No promises are made about background refresh timing, because the OS owns that.

Reading on demand

CachePolicy selects how a single read blends cache and network: .staleWhileRevalidate (default), .networkOnly, .cacheOnly. RefreshPolicy does the same job for sync: .revalidate (default), .force, .cacheOnly. ContentFreshness tells you which one you got: .fresh, .revalidated, or .cached(Date). Timestamps are informational; server freshness is decided by ETag validation, never by the device clock.

Live updates

• One stream connection per client. Adding slots never adds connections.
• Closed on background, reopened on foreground, followed by a revalidation because events may have been missed.
• A reopened stream resumes from the last event it saw by sending that id as a ?lastEventId= query parameter. The Kotlin SDK resumes with the standard Last-Event-ID request header instead, so a proxy rule, a log filter, or a WAF signature written for one platform does not cover the other.
• Exponential backoff with full jitter, capped at 60 seconds, reset after a stable connection.
• Authentication and authorization failures are terminal for the stream: no amount of reconnecting fixes a rejected key, so the SDK stops and says so. Restart the client after fixing the configuration.
• A burst of invalidations collapses into a single sync.
• Observable state is only ever published on the main actor. Disk and JSON work never runs there.

Subscribe to everything the client publishes with updates(), an AsyncStream<ContentUpdate>. Each caller gets its own stream; they all share one sync and one connection.

for await update in await ContentFlow.shared.updates() {
    switch update {
    case .blocks(let blocks, let freshness): break
    case .strings(let catalog):             break
    case .invalidated(let reason):         break
    case .failed(let error):              break
    }
}

For a single placement, blockState(for:) returns a ContentBlockStore, a MainActor ObservableObject publishing a ContentBlockState. Repeated calls for the same placement return the same store, and store.refresh() forces a network read for it.

state.block gives you the best block to render right now, fresh or stale, without matching on the case.

Localized strings

let strings = try await ContentFlow.shared.getStrings(locale: Locale(identifier: "ar"))
label.text = strings.string("home.title", fallback: "Welcome")

LocalizedStrings exposes locale, values, a subscript(key:) returning String?, isEmpty, and smartKeys with isSensor(_:) for keys the dashboard has armed as Sensors (empty where the server does not report them). There is deliberately no interpolation in v1: an interpolation syntax needs documented escaping, missing-variable behaviour, and localization rules before it becomes permanent API.

Switch locale at runtime with setLocale(_:). It drops locale-specific in-memory state, republishes the disk snapshot for the new locale, and revalidates. The locale is normalized to a BCP 47 tag. That tag travels as Accept-Language on every request, reads and writes alike, and as ?locale= on the GET reads only: /sdk/sync, /sdk/blocks/:key, /sdk/strings, and the stream. A POST carries the header and no locale query parameter. The Kotlin SDK splits it the same way.

Identify

Linking a device to a user is an explicit network call. There is no setUserId and no hidden mutable identity.

let client = ContentFlow.shared

let identity = try await client.identify(
    userId: "u_123",
    traits: ["plan": "premium", "signupDaysAgo": 12]
)
print(identity.segments)

• Pass nil for userId to keep the device anonymous.
• Passing a non-empty traits dictionary replaces the device's stored trait set wholesale: the SDK assigns it directly, it does not merge with what is already stored, so send the full set you want kept on every call. An empty dictionary, or omitting traits entirely, is a no-op on the server: stored traits are left exactly as they are. There is no way to clear stored traits through this field; call DELETE /sdk/identify to erase a device's data. Trait values are JSONValue, which is expressible by string, number, boolean, array, and dictionary literals.
• Segment membership is resolved at identify time. Re-call it on login, logout, and whenever a trait you target on changes. Sync does not re-evaluate segments on its own.
• Identity carries deviceId, userId, segments, and analyticsConsent. The server's echo of consent is informational only: the SDK never treats it as a grant.

Push tokens

try await client.registerPushToken(deviceToken, platform: .apns)

There are two overloads: one takes the raw Data from didRegisterForRemoteNotificationsWithDeviceToken and hex-encodes it for you, the other takes an already-encoded String. PushPlatform is .apns, .fcm, or .webPush. An empty token throws .invalidConfiguration.

Consent

Everything is denied on a fresh install: analytics, push, sms, whatsapp, email, location, marketing. Read the current state with consentSnapshot().

// The only call that changes the analytics decision.
try await client.setAnalyticsConsent(.granted)

// Per-channel. Needs an identified user: channel consent is stored
// on a person, not on an anonymous device.
try await client.setChannelConsent(.granted, for: .push)

let snapshot = await client.consentSnapshot()
snapshot.analytics                     // .granted / .denied
snapshot.hasExplicitAnalyticsDecision  // has the app ever decided?
snapshot.status(for: .sms)             // .denied until granted

The three-state wire contract

This is the part worth reading twice, because it is the difference between a correct integration and a compliance incident.

• identify has no consent parameter and cannot change consent in either direction. setAnalyticsConsent is the only call that does.
• Granting a delivery channel never fabricates an analytics decision. hasExplicitAnalyticsDecision stays false.
• With analytics consent denied, events are neither sent nor queued. The call returns .droppedNoConsent instead of pretending to succeed.
• Revoking purges the local event queue immediately. Nothing analytics-related outlives a revoke.
• Content sync keeps working with consent denied. That is deliberate: consent gates analytics, not content. A user who declined analytics still gets a working app.

ConsentChannel is .push, .sms, .whatsapp, .email, .location, .marketing. The location case is sent on the wire as locationTracking; the SDK handles that mapping.

Analytics events

Every tracking call reports what actually happened, so a consent drop is visible at the call site instead of looking like a silent success.

switch try await client.trackEngagement(.tap(block)) {
case .accepted:         break   // delivered on this call
case .queued:           break   // offline, will retry
case .droppedNoConsent: break   // consent denied, never sent
}

Each builder takes a ContentBlock and copies its instanceId, key, and screen onto the event, so you do not thread identifiers through your view code. The full initializer is available when you need to set blockType, position, custom properties, or a specific occurredAt. Event ids are client generated so an ambiguous retry can be deduplicated server side.

trackEngagement also takes an array. Queued events are batched, persisted across launches, capped, and aged out; a batch that fails is requeued once and held rather than dropped, so duplicate delivery is possible by design and deduplication happens on the id. flushEvents() sends whatever is queued now and returns whether the queue drained.

Identity events

trackSignUp(username:properties:) and trackSignIn(username:properties:) are thin wrappers over trackIdentityEvent(_:), sending exactly sign_up and sign_in. IdentityEvent also carries optional fullName, email, and phone, and supports .custom(String) for your own event names. These are analytics calls and are consent gated; username is required by the wire contract, and an empty one throws.

API reference

ContentFlow, the entry point

ContentFlowClient, an actor

Configuration

Types you will touch

ContentFlowRendererRegistry also exposes renderer(for:), unregister(placement:), removeAll(), and registeredPlacements, which are useful in tests and in a debug screen that lists what your app has wired up.

Errors

ContentFlowError is the whole taxonomy. It conforms to LocalizedError, so errorDescription is safe to log.

Retries are bounded and deliberate: reads retry transport failures, timeouts, rate limits, and 5xx; writes are never replayed on a status failure, because the write may already have landed. Authentication and authorization failures end the live-update stream rather than reconnecting forever.

Diagnostics

Schema problems are reported here rather than thrown, so a content mistake never turns into missing UI with no explanation. Wire this into your logger on day one; it is the cheapest debugging you will get.

ContentFlowDiagnostics.level = .verbose
ContentFlowDiagnostics.setHandler { diagnostic in
    logger.log("[\(diagnostic.category)] \(diagnostic.message)")
}

DiagnosticsLevel is .none, .errors (the default), .warnings, .verbose. Pass nil to setHandler to restore the default print sink. Each ContentFlowDiagnostic carries level, category, message, and timestamp.

Diagnostics are emitted for: an unparseable key, a tenant mismatch, unknown field types, duplicate tags, wrong-typed accessors, double-wrapped envelopes, cache corruption, unregistered placements, event drops, and stream reconnects.

What is in v1, and what is not

The JavaScript SDK has a much larger surface than this one. Rather than stub the difference, v1 leaves it out, so you can tell at a glance whether the thing you need exists.

Included

start, stop, close, identify, registerPushToken, setAnalyticsConsent, setChannelConsent, consentSnapshot, trackEngagement (single and batch), trackIdentityEvent, trackSignUp, trackSignIn, flushEvents, setLocale, sync, fetchBlock, getStrings, currentBlocks, updates, blockState, ContentFlowSlot, and renderer registration.

Folded into a different shape

Deferred until a production wire contract exists

updatePushTopics, getPushTopics, updatePushPreferences, getConsentConfig, requestConsent. These are omitted rather than stubbed, because a local-only implementation would make an app believe server push delivery changed when it did not.

Deliberately not in the core SDK

No code generation. Typed field keys give enough v1 safety without a schema download, a build plugin, or a CI story. If generation arrives later it should emit key constants, typed field keys, and schema version metadata, never a network client.

Moving off a hand-written REST client

If you wrote your own client against the REST reference, you already have the hard parts right and the migration is mostly deletion. Here is what the SDK takes over.

Things to check as you cut over:

• Your placement strings. They are block keys, case sensitive, with no fuzzy matching. If your old client normalized them, that behaviour disappears.
• Your consent code path. If it sent consent: false by default, stop. Send nothing until the user decides, and read the three-state contract.
• Your device id. The SDK generates its own. Migrating an existing id is not supported by the public API, so a switch-over means the device looks new: fresh consent state, fresh segments until the next identify. Plan that, do not discover it.
• Your base URL constant. Delete it and let the default stand.
• Your renderers. This is new work: the SDK will not draw anything until a placement is registered.

The wire details behind all of this are unchanged and stay documented on the REST API reference. Nothing on this page contradicts that page; the SDK is a client for exactly that contract.