Mobile SDK (beta): Android and iOS

Principle

The FlowConsent mobile SDK (beta) is a decision and proof SDK, not an imposed UI: your app keeps its own consent screen, the SDK manages state (same v1 contract as the web cookie), propagation to third-party SDKs, and proof — every choice lands in your Consent Registry like a web consent, and triggers your webhooks.

Installation

Android — published on Maven Central:

dependencies {
    implementation("com.flowconsent:flowconsent-android:0.1.0")
}

iOS — via Swift Package Manager:

.package(url: "https://github.com/BeBranded-xyz/flowconsent-mobile", exact: "0.1.0")

The source code is open: github.com/BeBranded-xyz/flowconsent-mobile, with copyable demo apps for Android (Compose) and iOS (SwiftUI).

Android (Kotlin)

FlowConsent.configure(context, licenseCode = "XXXX-…", workerUrl = "https://….consent.flowconsent.com")
 
val decision = FlowConsent.readConsent()
if (!decision.hasValidConsent) showMyConsentScreen()
 
// after the user's choice:
val d = FlowConsent.setConsent(analytics = true, marketing = false)
firebaseAnalytics.setConsent(ConsentContract.toGoogleConsentMap(d)) // if your app uses Firebase

Denied by default: without a record (or stale, or after a banner configuration change — fetchRemoteConfig()), everything is denied with an explicit reason. Local pseudonymous identifier (never IDFA/GAID).

iOS (Swift Package)

FlowConsentCore ships the same engine (ConsentContract.parse, toGoogleConsentMap) plus the App Tracking Transparency doctrine:

if ConsentContract.shouldRequestATT(decision) {
    ATTrackingManager.requestTrackingAuthorization { _ in }
}

Rule: GDPR screen first; the ATT prompt is only warranted once marketing was accepted, and your app always triggers it.

Is Firebase required?

No. The SDK imports no third-party SDK: toGoogleConsentMap() returns a plain string map to pass to setConsent if your app uses Firebase/GA4. Without Firebase, use decision.can("analytics") to gate your own calls.