mixpanel-iphone: the Objective-C analytics SDK for iOS
Official iOS (Objective-C) Tracking Library for Mixpanel Analytics
At a glance
- What is it?
- mixpanel-iphone is Mixpanel's official Objective-C tracking library for iOS, distributed through CocoaPods, Carthage and Swift Package Manager. It suits teams maintaining an Objective-C codebase that need event tracking with automatic mobile event collection, and its newer Swift library is the recommended path for Swift projects.
- Who is it for?
- Adopt mixpanel-iphone when your app is written in Objective-C and you want Mixpanel event tracking with a single shared instance and automatic collection of common mobile events, since the library is the vendor's own SDK for that platform and supports all three major iOS dependency managers.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 94 days ago.
- What is it written in?
- Mainly Objective-C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 21, 2026, and from our analysis. They are not legal advice.
Editorial analysis
An Objective-C SDK with a Swift sibling and a macOS reach
mixpanel-iphone is the official Mixpanel tracking library for iOS, written in Objective-C and published as an open source project under the Apache 2.0 licence. The README opens with an invitation to contribute and to apply to work at Mixpanel, which tells you the maintenance situation plainly: this is a vendor's own SDK, not a community project that happens to have a vendor attached.
The first practical point is the platform recommendation. If you are using Swift, the README recommends Mixpanel's separate Swift library, and points to an Advanced iOS Objective-C guide for configurations beyond the quick start, including setting up a project with European Union data storage. So the Objective-C library is not deprecated in the README's language, it is positioned as the right choice for a specific language, and there is a documented alternative for the other one.
The repository is wider than iOS. The top level entries include Mixpanel-macOS-Info.plist, Mixpanel-tvOS-Info.plist and Mixpanel-watchOS-Info.plist next to Info.plist, which means the same codebase ships platform information for four targets, along with a Package.swift for Swift Package Manager, a Mixpanel.podspec for CocoaPods, an Xcode project, a HelloMixpanel sample, a CHANGELOG.md, a SECURITY.md and a docs directory.
The topic tags name the distribution channels explicitly, carthage, cocoapods and sdk, which is a reminder that this library is consumed by build tooling rather than only by source.
Three installation paths, and a project token you need first
Before any of the installation options, the README asks for your project token, which you get from the project settings page. You cannot initialise the library without it, so that is the first thing to fetch.
CocoaPods is the first option. If you have never used CocoaPods you install it with `gem install cocoapods`, otherwise you skip to step three. Then you run `pod setup` to create a local CocoaPods spec mirror, run `pod init` in your Xcode project directory to generate a Podfile, add `pod 'Mixpanel'` to it, and run `pod install`. That last command downloads the library and creates a new Xcode workspace, which you open in Xcode or with `open *.xcworkspace` in the terminal. The detail that trips people up is that you must open the workspace, not the project, after installing a pod.
Carthage is the second option and it is a one line Cartfile entry:
github "mixpanel/mixpanel-iphone"Swift Package Manager is the third. In Xcode you select File > Add Packages, enter the package URL for the repository, and must select a version greater than or equal to v4.0.0. That version floor is a hard requirement stated in the README, not a recommendation.
The README also carries a caution for the CocoaPods route: from v4.0.0.beta.3 to v4.1.0 there was a bug where events with an ampersand would be rejected by the server, and it recommends updating to v4.1.1 or above. It is a narrow but real data loss bug, and it is the kind of thing that only shows up when a customer name contains an ampersand.
Initialising a shared instance and tracking an event
The API is small and the shape is conventional Objective-C. You import the header and call sharedInstanceWithToken: in application:didFinishLaunchingWithOptions:, and the README's example passes trackAutomaticEvents:NO to turn off automatic collection at init time.
#import "Mixpanel/Mixpanel.h"
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
...
[Mixpanel sharedInstanceWithToken:@"YOUR_API_TOKEN" trackAutomaticEvents:NO];
...
}Tracking an event is a message send with a properties dictionary. The README's example carries a string and a boolean, which is the usual mix, and the properties are described as the details specific to that event that help you understand user behaviour.
Mixpanel *mixpanel = [Mixpanel sharedInstance];
[mixpanel track:@"Sign Up" properties:@{
@"source": @"Pat's affiliate site",
@"Opted out of email": @YES
}];The complete example at the end of the README combines the two, creating the instance with automatic events off and then tracking a sign up, so you can copy one block and have a working start.
Two behaviours come for free once initialised. Mixpanel automatically collects common mobile events, and the README links to the list of which ones, and it automatically tracks some properties by default. Both are controlled from the project settings, so the choice of what leaves the device is a configuration decision rather than a code decision.
Events take about a minute to become queryable
The check for success step in the README is short, and the reason it is short is worth understanding. You open the Events view in Mixpanel to see incoming events, and the README states that once data hits the API it generally takes about 60 seconds to be processed, stored and queryable in your project.
That delay is the practical constraint for anyone integrating this SDK. Verification is not immediate, so a test that asserts an event has arrived will need to wait rather than query straight away, and debugging a missing event has a built in window where absence means nothing yet.
The FAQ adds a second dimension to the same problem, since it asks why events are not showing up and answers in terms of battery life and conditions on the device. The answer frames the delay in terms of battery life: the SDK is conservative about when it transmits, and a device that has not sent yet is not the same as a device that will not send.
For a team, the practical response to both facts is to plan the instrumentation timeline before writing the code, since a verification loop that assumes immediate delivery will look like a failure on day one.
Opting out, and dropping data server side
Two of the FAQ entries describe controls over what gets collected, and they work at different ends of the pipeline.
The first is client side. The optOutTracking method sets the user's local opt-out state to true and prevents data from being sent from that user's device, with detailed instructions in the section on opting users out of tracking. The word local matters, because this is a device level switch, and it is the mechanism an app would use to honour a preference the user has already expressed elsewhere.
The second is server side. The README states that in Lexicon you can intercept and drop incoming events or properties, and that Mixpanel will not store any new data for the event or property you select to drop. This is a useful property for a privacy response: if a property is collected by mistake, or an event is sent that should not have been, you can stop storing it going forward without shipping a new build. What it does not do is erase what has already been stored, so it is a forward-looking control rather than a deletion tool.
Neither mechanism is a substitute for deciding what to collect in the first place. The library collects common mobile events and default properties automatically, which means the default posture is a broad one, and narrowing it is a deliberate act.
Release cadence, platforms, and what the version numbers tell you
The release history is slow by the standards of a mobile SDK. The tags are v5.0.9 on 2026-01-21, v5.0.8 on 2025-02-26 and v5.0.7 on 2024-03-27, so the current 5.0.x line has produced about one release a year. The last push to the master branch was on 2026-07-21, so the code is still being touched even though the tagged releases are infrequent.
The 5.x line matters for the Swift Package Manager route, since the README requires a version of at least v4.0.0, and the CocoaPods badge and the Carthage badge in the header show that both channels are still published for it.
The platform reach is broader than the name suggests. The presence of macOS, tvOS and watchOS information property lists alongside the iOS one means the same library is packaged for four platforms, and the Swift library for the Swift variant is a separate repository in the same organisation.
The licence is Apache 2.0, with a LICENSE file in the repository root and a SECURITY.md for reporting security issues. The build badge points at a Travis CI configuration on a yolo-travis-ci branch, and there are issue maintenance badges for the average time to resolve an issue and the percentage of open issues, which is the project's own way of showing how it handles its backlog. This article does not give legal advice, and the practical question for a commercial app is simply whether the Apache 2.0 terms fit your distribution model.
Editorial conclusion
Adopt mixpanel-iphone when your app is written in Objective-C and you want Mixpanel event tracking with a single shared instance and automatic collection of common mobile events, since the library is the vendor's own SDK for that platform and supports all three major iOS dependency managers. Do not adopt it in a new Swift codebase, because the README recommends the Swift library instead, and note that an Objective-C SDK ties you to the vendor's analytics model rather than a neutral event pipeline. Before you upgrade, read the CHANGELOG.md, since the README records a past server side rejection of events containing an ampersand between v4.0.0.beta.3 and v4.1.0, and pin a version at or above v4.1.1.
Frequently asked questions
How do I install the Mixpanel iOS Objective-C library?
You can use CocoaPods by adding `pod 'Mixpanel'` to a Podfile and running `pod install`, Carthage by putting `github "mixpanel/mixpanel-iphone"` in a Cartfile, or Swift Package Manager by adding the repository in Xcode and selecting a version of at least v4.0.0. You need your project token from the Mixpanel project settings to initialise it.
How do I stop tracking an event or a property in Mixpanel?
On the client side the optOutTracking method sets the local opt-out state and prevents data being sent from that device. On the server side, the README says that in Lexicon you can intercept and drop incoming events or properties, and Mixpanel will not store any new data for what you select to drop.
Why are my Mixpanel events not showing up?
The README says that once data hits the API it generally takes about 60 seconds to be processed, stored and queryable, so absence right after sending means little. The FAQ also covers the case where events are not appearing because the client library is conservative about sending in order to preserve battery life.
Should I use mixpanel-iphone or the Mixpanel Swift library?
The README recommends the separate Swift library if you are using Swift. The Objective-C library here is the official iOS SDK for Objective-C projects and ships platform builds for macOS, tvOS and watchOS as well.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mixpanel-mixpanel-iphone)