# Countly iOS SDK: analytics, crashes and experiments for Apple apps > The Countly iOS SDK is an MIT licensed Objective-C client for iOS, watchOS, tvOS and macOS that sends analytics, crash reports, push notifications, performance data and A/B test results to a Countly server. It is a client only: the data ends up in Countly Lite or Countly Enterprise, which is a commercial decision, not a technical one. **Countly/countly-sdk-ios** — Countly Digital Analytics iOS SDK with macOS, watchOS and tvOS support. - Repository: https://github.com/Countly/countly-sdk-ios - Website: https://countly.com/ - Stars: 628 · Forks: 240 - Language: Objective-C - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/countly-countly-sdk-ios ## One Objective-C client for four Apple platforms This repository holds the Countly iOS SDK, which is intended to be integrated into iOS, watchOS, tvOS and macOS applications. The primary language is Objective-C, and the top level of the tree shows why that is a reasonable choice: the codebase is a set of paired header and implementation files with names like `CountlyConfig.h` and `CountlyConfig.m`, `CountlyEvent.h` and `CountlyEvent.m`, `CountlyCrashReporter.h` and `CountlyCrashReporter.m`. The SDK is the client half of a larger product. It is meant to be used with Countly Lite or Countly Enterprise, and the Countly server itself lives in a separate repository. The broader Countly product is a product analytics solution covering mobile, web and desktop applications, and the vendor describes it as built with privacy by design. That arrangement defines what you are adopting. The SDK is MIT licensed and you can read every line of it, but the data lands in a Countly deployment that you either run yourself in the Lite edition or license from the vendor. If the requirement is an open source pipeline from device to dashboard, this repository is only the first hop. ## A facade over a set of focused managers The file list shows a deliberate structure. There is a `Countly.h` and `Countly.m` pair that acts as the entry point, and then separate managers for the different concerns of the SDK: `CountlyConnectionManager` for talking to the server, `CountlyConsentManager` for consent state, `CountlyPersistency` for local storage, `CountlyContentBuilder` and `CountlyContentBuilderInternal` for assembling payloads, `CountlyDeviceInfo` for device metadata, and `CountlyLocationManager` for location. Other pairs map directly onto the product features: `CountlyPushNotifications` with `CountlyNotificationService`, `CountlyCrashReporter` with `CountlyCrashData` and `CountlyCrashesConfig`, `CountlyPerformanceMonitoring` with `CountlyAPMConfig`, `CountlyExperimentalConfig` with `CountlyExperimentInformation`, and `CountlyFeedbackWidget` with `CountlyFeedbacks`. Two naming conventions are worth noting because they tell you what to configure and what to expect at runtime. Each feature has a separate configuration class, so you enable and tune features individually rather than through one settings object. And there are `Internal` suffixed headers next to the public ones, which is the usual Objective-C way of keeping implementation headers out of the public interface, so the surface you compile against is the un-suffixed set. The repository also carries a `Countly.xcodeproj` directory, a `.clang-format` file, and two podspec files, `Countly.podspec` and `Countly-PL.podspec`, plus a `CHANGELOG.md` and a `.markdownlint.json`. ## Feature coverage is broad and mostly self hosted The SDK ships with a feature list that covers the usual product analytics surface: Analytics, Push Notifications, User Profiles, Crash Reports, A/B Testing, Performance Monitoring, and Feedback Widgets for surveys, NPS and ratings. Each of those is a separate area of the codebase, and the class names line up with the list in a way that tells you how they are put together. Performance monitoring has its own config class named for application performance monitoring, and A/B testing is implemented as experiments with experiment information objects, which is the vocabulary of a variant and a control group rather than a feature flag service. Crash reporting is the part with the most moving parts. `CountlyCrashReporter` sits next to `CountlyCrashData` and `CountlyCrashesConfig`, and there is also a `CountlyHealthTracker`, which in the Apple ecosystem is the mechanism that reports the state of the app when it is terminated abnormally. Putting it that way means crash data can arrive on the next launch rather than at the moment of the crash, and it explains why the crash module has both a reporter and a data class. Push notifications use a separate `CountlyNotificationService` alongside `CountlyPushNotifications`, and the two podspec files suggest the notification delivery part is packaged separately from the core SDK, which is consistent with an extension target needing its own packaging. ## Integration instructions live on the support site There is no integration snippet in the repository readme, and no build or install command to copy. The documentation points to a support article for a detailed description of how to use the SDK, a specific section of that article for how to add the SDK to your project, and another section with minimal integration information. A working example lives in a separate repository, countly-sample-ios, which is the fastest way to see the whole shape of an integration rather than reading about it. What this means in practice is that the readme is a map rather than a manual. That is a reasonable division of labour for a vendor SDK that has to serve several platforms and two server editions, and it keeps the repository small, but it also means you cannot evaluate the SDK from the repository alone. The Xcode project, the podspec files and the class list tell you the shape, and the actual method calls live in the documentation. One piece of information the readme does give you directly is the security disclosure process. If you find a security issue, you should email security@count.ly and not open a GitHub issue. For an SDK that runs inside every build of a mobile application, that is the channel that matters. ## MIT licensed code, commercial data destination The licence is MIT, with the licence file at the root of the repository. For a client library that you link into your own application, that means you can read it, modify it and ship it without the copyleft obligation that would come with a shared library approach. The client code is not the part that carries the licensing weight. The weight sits with the data destination. The SDK is intended to be used with Countly Lite, which is the self hosted edition whose server is in a separate repository, or with Countly Enterprise, which is a commercial product. Choosing between them is a hosting and support decision, and it is the decision that determines whether your analytics data stays inside your own infrastructure. The topic tags on the repository list analytics, crash-dump, crash-reporting, push-notifications, view-tracking, product-analytics and telemetry collection, which is an accurate summary of what the SDK does on the device. The consent manager and the location manager in the class list are the two places where that collection becomes a policy question rather than an engineering one, and the vendor points at its privacy by design page for the wider stance. On cadence, the release line is dated and regular. Version 26.1.2 was tagged on 2026-06-24, 26.1.3 on 2026-07-10, and 26.1.4 on 2026-08-11, and the last push was on 2026-10-20, so work has continued on the default branch `master` for about two months after the last tag. ## Badges are the only snippet in the repository The readme asks users who like Countly to use one of their badges and link back, and the badge snippet is the one piece of literal code the repository contains: ```JS Countly - Product Analytics ``` There is a dark and a light variant of that markup. Including it in an application README is a link back to the vendor, which is the stated reason for the request, and it is worth deciding as a team whether your product documentation should carry a third party analytics badge. That snippet is also a useful summary of this repository. The client SDK is the thing you integrate, the server is a separate codebase and a separate licensing decision, and the instructions for using it live in the vendor's support documentation rather than in the tree. Anyone evaluating the SDK should budget time for reading that documentation, and for deciding where the telemetry your app collects is going to be stored. ## Conclusion The Countly iOS SDK fits an Apple platform team that wants product analytics, crash reporting and push in one MIT licensed client and is ready to run or license a Countly server. It does not fit a team that needs a standalone open source analytics backend, because this repository contains no server, only the client. Before adopting it, read the integration documentation for your target platform, decide between Countly Lite and Countly Enterprise on hosting grounds, and check the CHANGELOG.md because the release line moves with a dated version on each build, with the last one tagged 26.1.4 on 2026-08-11. ## FAQ ### Which Apple platforms does the Countly iOS SDK support? It can be integrated into iOS, watchOS, tvOS and macOS applications, and it is written in Objective-C. The repository pairs each class with a header and an implementation file. ### Do I need a Countly server to use the SDK? Yes. The SDK is intended to be used with Countly Lite or Countly Enterprise, and the Countly server itself lives in a separate repository, the countly-server one. This repository contains only the client. ### What features does the Countly iOS SDK support? Analytics, Push Notifications, User Profiles, Crash Reports, A/B Testing, Performance Monitoring, and Feedback Widgets for surveys, NPS and ratings. Each area has its own class and configuration class in the repository. ### How do I integrate the Countly iOS SDK into a project? The readme does not contain integration code. It points to sections of the Countly support documentation for adding the SDK to a project and for minimal integration, and to the countly-sample-ios repository for a complete example. ### How should I report a security issue in the Countly iOS SDK? The documented process is to email security@count.ly and not to open a GitHub issue. The repository also carries an MIT LICENSE file and a CHANGELOG.md for release history. ## Sources - [Countly/countly-sdk-ios on GitHub](https://github.com/Countly/countly-sdk-ios) - [License: MIT](https://github.com/Countly/countly-sdk-ios/blob/master/LICENSE) - [Project website](https://countly.com/) - [README](https://github.com/Countly/countly-sdk-ios/blob/master/README.md) - [Releases](https://github.com/Countly/countly-sdk-ios/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/countly-countly-sdk-ios