▸Install the Swift (iOS) SDK
// Package.swift
dependencies: [
.package(url: "https://github.com/respectlytics/respectlytics-swift.git", from: "3.0.0")
]
// Or via Xcode → File → Add Packages → paste the URL above.
The SDK ships only via Swift Package Manager. CocoaPods and Carthage are not published — fewer integration paths means fewer surfaces to keep audited.
▸Initialize Respectlytics in Swift (iOS)
import Respectlytics
@main
struct MyApp: App {
init() {
Respectlytics.configure(appKey: "<YOUR_APP_KEY>")
}
var body: some Scene { WindowGroup { ContentView() } }
}
Call configure once at app launch — typically in your App struct's init. No Info.plist keys are required: the SDK does not call ATTrackingManager and does not request the IDFA, so NSUserTrackingUsageDescription should NOT be added.
✦Privacy & implementation notes
AGPL-3.0 is a common license for SaaS-as-source projects (Plausible, Matomo, GitLab Community Edition). The license design is to prevent vendors from forking the project, modifying it privately, and offering their fork as a competing closed-source SaaS — but it does not impede internal self-hosting at all. For most enterprise self-hosters, the license is a non-issue.
Self-hosted Respectlytics is operated by the same management commands and Django infrastructure as our cloud — the deployment difference is purely the database hostname and the network egress profile. If you can run a Django + Postgres app on your infrastructure, you can run Respectlytics.
Apple rejected approximately 3% of apps in 2024 for incorrectly omitting NSUserTrackingUsageDescription when ATT was required by the SDKs they shipped. Respectlytics doesn't trigger ATT. The corollary is also true: do not add the key on Respectlytics's account — its presence implies you track across apps, even if your code never calls requestTrackingAuthorization.
Internally the Swift SDK uses Swift Concurrency: events are queued in an actor-isolated buffer (RAM-only), flushed on a 30-second timer and on UIApplication.willResignActiveNotification. Force-quit before flush drops queued events — by design. There is no UserDefaults or file backing.
⇋How this compares to other analytics SDKs
| Self-hosting | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Self-hostable | No | No | No (cloud-only) | Yes (AGPL-3.0 server) |
| SDK license | Apache 2.0 | Apache 2.0 | MIT | MIT |
| Server source available | No | No | No | Yes (public repo) |
| Operator-managed database | No | No | No | Yes (you choose) |
| Air-gapped deployment possible | No | No | No | Yes |
❓Frequently asked questions
What infrastructure do we need to self-host?
A Linux box (or container) running Python 3.12, Postgres 14+ (managed or self-managed), and a reverse proxy (nginx / Caddy / similar). The default configuration scales to ~10 million events/day on a 4-vCPU / 8 GB box; larger deployments scale horizontally. Hardware requirements are documented in the public README.
What's the AGPL-3.0 obligation?
If you modify the server source AND offer the modified server as a service to third parties (over a network), you must publish your modifications under the same license. Internal self-hosting for your own apps does NOT trigger publication obligations — it's only when you offer the server to others over a network. Consult your legal team for specific applicability; the FSF's AGPL FAQ is the canonical reference.
Are SDK changes also covered by AGPL?
No. The SDKs (Swift, Kotlin, RN, Flutter) are MIT-licensed — fork and modify freely with no copyleft obligation. Only the SERVER is AGPL.
Do self-hosted instances get our updates automatically?
No — you upgrade by pulling the latest source and running migrations. We publish release notes for each version. There's no auto-update; self-hosting means you control the deployment cadence.