iOS SDK

Add the dependency, call start() once, and the signals below arrive on their own. There is no event taxonomy to design first and no tracking plan to keep up to date.

Published on Swift Package Manager · CocoaPods.

Before you start

Requirements for the iOS SDK
Runtime	iOS 13 or newer. The package also builds for macOS 11 and tvOS 13. Swift tools 5.7.
Permissions	None, and no App Tracking Transparency prompt, because no advertising identifier is read.
Publishable key	Console, under Settings. It is a publishable key, safe to ship in client code: it can only append events.

Install

swift

.package(url: "https://github.com/SharminSirajudeen/drengr-sdk.git", from: "0.3.0")

Start it

In AppDelegate.swift / your App struct. Your publishable key is safe to ship in client code: it can only write.

AppDelegate.swift / your App structswift

// Xcode → Add Package: https://github.com/SharminSirajudeen/drengr-sdk.git (from 0.3.0)
import Drengr

Drengr.start(
    publishableKey: "drengr_pk_YOUR_KEY",
    ingestURL: "https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest",
    appPackage: "com.example.app"
)

What arrives on its own

You do not instrument these. They are captured from the moment start() runs. The third column names the iOS API behind each one, so you can check the claim against your own app.

Signals the iOS SDK captures automatically, and the platform hook behind each
Signal	What it records	Where it comes from
screen_view	Every screen or route the user lands on	A swizzle of UIViewController.viewDidAppear(_:)
tap	Taps, with the element's own label when it has one	A swizzle of UIWindow.sendEvent(_:)
net / net_fail	Outgoing requests: host, path, status, duration, size	A URLSession swizzle, so requests are captured without you changing call sites
crash	Uncaught exceptions with their stack	NSSetUncaughtExceptionHandler, chaining any handler already installed
rage_tap / dead_tap	Repeated taps that did nothing — the friction signal	The same UIWindow.sendEvent swizzle as tap
rage_scroll / dead_scroll	Scroll thrash and scrolls that moved nothing	The same UIWindow.sendEvent swizzle as tap
app_foreground / app_background	Lifecycle, which is what sessions are built from	UIApplication lifecycle notifications
identify	Your own user id, when you choose to send one	Your own call to Drengr.identify()

Call start() once, as early as you can — anything before it is not captured.

CocoaPods works too: add pod 'Drengr' and run pod install.

URLSession traffic is captured through a protocol hook; no swizzling of your own code.

What never leaves the device

Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.

And what is never collected in the first place:

What the Drengr SDKs do not collect, and why that is structural
Not collected	How you can tell
Screen recordings, screenshots or DOM snapshots	There is no column for pixels or markup on the events table, and no SDK reads the framebuffer.
Keystrokes	Tap capture records that a tap happened and the element's own accessibility label. No SDK attaches a key or text listener.
Raw request and response bodies	What is stored is a safe dotted-path projection, redacted and capped at 64 KiB on the device before anything is sent.
Authorization headers, cookies and API keys	Masked by name before capture, along with password, pin, cvv, ssn, otp and iban field names.
An IP address on the event	The events table has no ip or geo column, so no stored event carries one.
Advertising or cross-app identifiers	Identity is a random install_id the SDK generates. No IDFA, no GAID, and no device fingerprint is used for identity.

Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.

Start paused behind a consent gate with Drengr.start(startEnabled: false), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.

Consent controls on the iOS SDK
Start paused	Drengr.start(startEnabled: false)
Opt out	Drengr.optOut()
Opt back in	Drengr.optIn()
Where the choice is stored	UserDefaults, key dev.drengr.opt_out

Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.

Check it worked

Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.

Nothing showing up

Common reasons no events appear, and how to tell
What you see	Most likely cause
Console stays on “Get your first events in”	The key belongs to a different organisation, so the events landed in someone else’s tenant.
Events arrive, but the app you picked looks empty	The app_package you passed to start() is not the one you are scoped to in the console. Switch the scope, or match the value.
Nothing until you close the app	The first batch flushes on background. Send the app to the background once, or wait for the flush interval.
Taps and network arrive, screens do not	Screen capture attaches at start(); check that start() runs before your first screen.
Nothing at all, ever	start() is not reached, or it runs after the events you expected. Put it as early as you can and check for a thrown error before it.

Where to go next

Once events are arriving, these are the things worth doing in order.

Set up consent and opt-out before you ship to real users.
Name your events. Drengr proposes names from the traffic itself; you accept or reject them in the console's review queue.
Bring your history across from whatever you use today, so the numbers do not start at zero.

Not ready to install anything?

Drop a .har of traffic you already have and see the business events your current analytics is missing. It runs in your browser; nothing is uploaded.

Scan for blind spots →