Broctic

Download the SDK (legacy)

Legacy, for imported and hand-written apps: the Swift and TypeScript analytics clients as single files. A Studio app is instrumented by its kit and needs neither.

Get the file

Legacy — for an app Broctic did not build

An app built in the Studio ships kit/analytics.ts and is instrumented from its first build, writing to Broctic and, once one is linked, to its own PostHog project. Adding one of these files to it would be a second analytics client sending every event twice. These downloads are for an imported or hand-written app, which Broctic does not inject a client into. They write to /v1/events only — session replay comes from linking a PostHog project, not from these.

There are two clients and they are the same client: same wire format, same batching, same retry rules, same anonymous-id semantics. A funnel does not change shape because an app is native rather than React Native. Pick the one that matches what you are writing.

Swift — native iOS, iPadOS, macOS

One file, no Swift Package. Drag it into an Xcode target and call `Broctic.start(key:)` once at launch. Requires iOS 15+; compiles clean under Swift 6 strict concurrency.

BrocticAnalytics.swift559 lines

TypeScript — Expo, React Native, web, Node

One file, zero dependencies, no package to add. Give it AsyncStorage (or anything with getItem/setItem) so the anonymous id survives a cold launch.

broctic-analytics.ts265 lines
terminal
# Swift — into an Xcode target
curl -O https://broctic.com/sdk/BrocticAnalytics.swift

# TypeScript — into an Expo, React Native, web or Node project
curl -O https://broctic.com/sdk/broctic-analytics.ts
There is no package to install and no version to pin. That is deliberate: this is also what an AI assistant is handed when asked to instrument an app, and a package is a step that fails differently in every project. It is also what a developer reads before deciding to trust an analytics client with their paywall — a few hundred lines they can audit in one sitting beats a binary they cannot.

What both clients do

  • Batch. Twenty events or three seconds, whichever comes first.
  • Persist. The anonymous id and any unsent events survive a cold launch.
  • Retry the right failures. 5xx, 429 and network errors stay queued; 4xx is dropped, because a bad key or a bad shape will still be bad next time.
  • Flush when the app goes to the background. That is the difference between measuring a paywall and measuring the paywalls people did not quit at.
  • Never throw into your app. Errors go to an onError callback that defaults to silence — an analytics library that can crash a paywall is worse than no analytics.

The Swift client additionally fills in platform, app version, OS version, locale and country from the bundle and the system. Those are the five values an integrator most often gets subtly wrong, and the app already knows all five.

What you need before it works

  • A publishable key (bpk_), created on the app's page in the console under Events. It can only do what a shipped app needs for that one app — write its events, fetch its onboarding funnel, check its purchases. It is expected to be extracted from the binary, so committing it is safe.
  • An organization API key (brk_) must never ship in an app. It reads and changes the whole organization.
  • The 20 standard event names. Anything else is stored faithfully and compared to nothing — see events.

Check it is working

Open the app's page in the console and go to Events. The page watches for the first one and fills in by itself when it lands. Every name received is listed and marked standard or custom — a name you expected to see marked custom is misspelt against the vocabulary, and the fix is in the app, not in the funnel step.