SensorsAnalytics SDK for iOS: code tracking plus runtime based automatic tracking

What the SDK collects, and who runs it

This is the official iOS tracking SDK from Sensors Data, and the project describes it as a lightweight data collection and tracking SDK for the iOS side. The README is clear about what it does more than a normal analytics wrapper: besides code based tracking, it uses runtime mechanisms to implement full automatic tracking on iOS, referred to in the description as no tracking, code free tracking, traceless tracking and automatic tracking, plus click maps and visual automatic tracking. The company behind it, Sensors Data, is described as a big data analytics company based in Beijing with local service teams in Shanghai, Shenzhen, Hefei and Wuhan, covering industries including internet, finance, retail, manufacturing and more. For an engineer the relevant part is narrower: this is a client library that ships your app's behavioural events to a Sensors Data project, and the interesting engineering decision is the automatic tracking.

The automatic tracking approach and what it costs

The interesting technical claim is the runtime based implementation. Instead of requiring a developer to add a call on every screen, the SDK hooks into the runtime to observe what is happening in the app and derive the events itself. That is a meaningful difference in engineering terms, because manual instrumentation is where analytics implementations rot: every new screen is a place to forget the call, and every release shifts the mapping between events and screens. The cost of the approach is that the SDK now sits in the middle of your app's control flow and depends on runtime behaviour that Apple does not document as a stable contract. That is the trade-off you are accepting when you take automatic tracking over explicit event calls, and it is worth stating plainly before you adopt, because a change in the iOS runtime model can change what the SDK observes, and the click map and visual tracking features are built on that same observation layer.

The package layout: a core pod plus optional capabilities

The repository root shows how the SDK is packaged, and the structure is more interesting than a single target. There is a SensorsAnalyticsSDK/ directory with its own SensorsAnalyticsSDK.podspec, and then two separate optional modules with their own podspecs: SensorsAnalytics_DeviceOrientation/ with SensorsAnalytics_DeviceOrientation.podspec, and SensorsAnalytics_Location/ with SensorsAnalytics_Location.podspec. So the core SDK is one dependency and the device orientation and location capabilities are opt in, which matters for an app that does not want to request motion or location permission as part of a tracking dependency. There is also an Example/ directory with sample applications for four platforms: Example-iOS, Example-macOS, Example-tvOS and Example-watchOS. The presence of macOS, tvOS and watchOS samples is notable for an SDK the documentation describes in iOS terms, and it is the fastest way to see how the API is meant to be called.

Installing through CocoaPods or Carthage

The README carries badges for both distribution routes, Carthage Compatible and CocoaPods Compatible, and the CocoaPods badge names the pod SensorsAnalyticsSDK, with a platform badge pointing at the CocoaDocs docset. The integration instructions themselves are not in the README. It directs you to the iOS SDK integration manual on the Sensors Data site, and for commercial licensing details it points at a separate SDK site. There is also a table of recommended versions with links to two specific release tags, v4.5.7 and v4.4.5, which is unusual to see in a README and suggests those two lines are the ones the vendor considers safe for production use. The recent release tags tell a different, newer story: v5.0.12 on 2026-09-02, v5.0.10 on 2026-05-14 and v5.0.9 on 2026-03-30.

Platform requirements, and a gap between them and the current tags

The basic requirements section is short: iOS 9.0 and above, and Xcode 9.0 and above. That floor is deliberately low, which lets one binary serve apps with a wide range of deployment targets, and it is consistent with the SDK being written in Objective-C rather than Swift, with the primary language of the repository listed as Objective-C. The gap between the stated requirements and the recommended versions is the part to notice. The recommended table points at 4.x tags while the recent releases are 5.0.x, so a team starting a new integration has to decide which line to sit on, and the README does not say whether 5.x is suitable for production use. The repository also carries badges from a service that tracks the average time to resolve an issue and the percentage of issues still open, which is a rough way to see the maintenance signal from the README itself, and the last push was on 2026-09-03.

Licensing, contribution and the vendor relationship

Two things to sort out before you ship anything built on this. The first is the licence. The repository listing classifies it as other, a custom licence GitHub cannot classify, and the README's own licence section only links to the LICENSE file without summarising the terms, while a separate line points at a commercial authorisation site for the SDK. For a vendor SDK that sits inside your shipping app, that is a commercial conversation with the vendor rather than a permissively licensed library you can adopt on a whim, and the SDK is described as the first open source commercial user behaviour collection SDK in China, with the README stating that 1500 or more paying customers and more than 2500 apps have integrated it. The second is the contribution model, which is spelled out in five steps: fork sa-sdk-ios under your own GitHub account, clone the source locally, push your changes to a branch on your fork, open a pull request against the official development branch, and the SDK team reviews and merges once the tests pass. There is a ROADMAP.md in the repository for what is planned.

Editorial conclusion

Adopt the SensorsAnalytics SDK if your iOS app already sends behavioural events to a Sensors Data project and you want automatic tracking added without instrumenting every screen by hand, since the runtime based approach is the part that distinguishes it from a plain event API. Do not adopt it if you have no Sensors Data backend, and read the LICENSE file first, because the repository is classified as carrying a custom licence that GitHub cannot categorise, and the README separately points at a commercial licensing site for the SDK. Before you integrate, check that your minimum deployment target is iOS 9.0 with Xcode 9.0, decide whether you need the location or device orientation podspecs, and follow the official iOS integration manual rather than the README, which contains no code.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sensorsdata/sa-sdk-ios on GitHub