Intilery for iOS makes it simple to send your data to Intilery.
All of Intilery;s libraries are open-source, so you can view Intilery for iOS on GitHub
Want to stay updated on releases? Subscribe to the release feed.
Note: Intilery does not currently support tracking of watchkit extensions for the Apple Watch. Email us if you’re interested in a Watchkit SDK. For now we recommend tracking watch interactions using the iPhone app code.
One of the most important parts of any analytics platform is the ability to consistently and accurately identify users. To do this, the platform must assign and persist some form of identification on the device, so you can analyze user actions effectively.
Naturally the Intilery SDK needs a unique ID for each user. To protect end-users’ privacy, Apple places restrictions on how these IDs can be generated and used. This section explains Apple’s policies, and how Intilery generates IDs in compliance with these policies.
Before iOS 5 developers had access to
uniqueIdentifier, which was a hardware-specific serial number that was consistent across different apps, vendors and installs. Starting with iOS 5, however, Apple deprecated access to this identifier. In iOS 6 Apple introduced the
identifierForVendor which protects end-users from cross-app identification. In iOS 7 Apple restricted access to the device’s MAC address, which many developers used as a workaround to get a similar device-specific serial number to replace
Intilery's iOS library supports iOS 7+ by generating a UUID and storing it on disk. This complies with Apple’s required privacy policies, maintains compatibility, and also enables correct tracking in situations where multiple people use the same device, since the UUID can be regenerated.
The Intilery SDK queues API calls rather than making a network request for each event tracked, to help improve the user’s battery life.
Batches are sent either:
- when there are 20 or more events in the queue
- on a scheduled timer, every 30 seconds
- when the app goes to the background
To limit memory and disk usage, Intilery only queues up to 1000 events. When the app is terminated, Intilery saves the queue to disk, and loads that data again at app launch so there is no data loss.
The recommended way to install Intilery for iOS is using Cocoapods, since it means you can create a build with specific destinations, and because it makes it simple to install and upgrade.
First, add the
Analytics dependency to your
Podfile, like so:
Then in your application delegate’s
- application:didFinishLaunchingWithOptions: method, set up the SDK like so:
Note: Automatically tracking lifecycle events (
Application Updated) and screen views is optional using initialization config parameters, but highly recommended to hit the ground running with core events!
And of course, import the SDK in the files that you use it with:
SEGAnalyticsConfiguration class provides a set of properties that control various policies of the
SEGAnalytics instance. You initialize it with a
writeKey as in the examples below:
|Your Intilery Write Key.|
The Intilery-iOS SDK can automatically instrument common application lifecycle events such as “Application Installed”, “Application Updated” and “Application Opened”. Simply enable this option when you initialize the SDK.
The Intilery-iOS SDK can automatically instrument screen calls. It uses method swizzling to detect when
ViewControllers are loaded, and uses the label of the view controller (or the class name if a label is not available) as the screen name. It removes the string “ViewController” from the name if one is present.
When you set
YES, the SDK automatically sends a Track event for
Push Notification Received and
Push Notification Tapped.
When you set
YES, the SDK automatically sends a Track event for
Deep Link Opened.
You can set the number of events that should queue before flushing. Setting this to
1 will send events as they come in (i.e. not send batched events) and will use more battery.
20 by default.
You can also manually
flush the queue:
Now that the Intilery SDK and is installed, you’re ready to collect some data!
Good to know: For any of the methods described in this doc, you can replace the properties and traits in the code samples with variables that represent the data collected.
Intilery's Identify method lets you tie a user to their actions and record traits about them. It includes a unique User ID and any optional traits you know about them.
Intilery recommends that you call Identify once when you first create the user’s account, and only call it again later when they update their traits or you change them.
Note: Intilery automatically assigns an
anonymousId to users before you identify them. The
userId is what connects anonymous activities across devices (for example, iPhone and iPad).
|The database ID for this user. If you don’t know who the user is yet, you can omit the |
|A dictionary of traits you know about the user, like their |
Intilery for iOS works on its own background thread, so it will never block the main thread for the UI or the calling thread.
- identify: with a
userId will write that ID to disk to be used in subsequent calls. That ID can be removed either by uninstalling the app or by calling
Find details on the identify method payload in the Identify Schema documentation.
Intilery's Track method lets you record the actions your users perform. Every action triggers what we call an “event”, which can also have associated properties.
To get started, the Intilery iOS SDK can automatically track a few key common events with the Intilery Native Mobile Schema, such as the
Application Updated and
Application Opened. Enable this option during initialization.
You might also want to track events that are indicators of success for your mobile app, like Signed Up, Item Purchased or Article Bookmarked. Intilery recommends tracking just a few important events to start out. You can always add more later! An example Track call might look like this:
This example Track call above tells you that your user just triggered the Item Purchased event, and records the
item name of “Sword of Heracles” and
revenue of 2.95.
Track event properties can be anything you want to record. In this case, item and revenue.
The Track call has the following fields:
|The name of the event. We recommend human-readable names like Song Played or Status Updated.|
|A dictionary of properties for the event. If the event was |
The Screen method lets you you record whenever a user sees a screen of your mobile app, along with optional extra information about the page being viewed.
You’ll want to record a screen event an event whenever the user opens a screen in your app. This could be a view, fragment, dialog or activity depending on your app.
Example Screen call:
screen call has the following fields:
|The name of the screen, for example Signup or Home.|
|A dictionary of properties for the screen. A screen Photo Feed might have properties like |
Find details on the Screen payload in the Screen Schema documentation.
You can retrieve the
anonymousId set by the library by using:
- reset method clears the SDK’s internal stores for the current
user. This is useful for apps where users can log in and out with different identities over time.
The example code below clears all information about the user.
Reset does not clear events in the queue, and any remaining events in the queue are sent the next time the app starts. You might want to call Flush before you call Reset.
Note: Each time you call
reset, a new AnonymousId is generated, therefore only recommended when a user logs out or similair
Depending on the audience for your app (for example, children) or the countries where you sell your app (for example, the EU), you might need to offer the ability for users to opt-out of analytics data collection from inside your app. You can turn off forwarding to ALL destinations including Intilery itself using the following code:
Or if the user opts back in, you can re-enable data collection:
If you disable the Intilery SDK in response to user opt-out, all Intilery method invocations (Track, Screen, Identify, etc) are ignored.
To see a trace of your data going through the SDK, you can enable debug logging with
Or disable it like this:
By default debug logging is disabled.
Starting iOS 14, applications must prompt users if that app needs to collect their Identifier for Advertisers (IDFA). Going forward with analytics-ios-4.1 and later, Intilery doesn’t auto-collect IDFA. If your app or any integrations require the use of IDFA, you need to:
- import the AdSupport and App Tracking Transparency Frameworks by Apple
- pass the below code snippet to Intilery config and start tracking events
- prompt the user for consent and collect the IDFA
You can use the following closure snippet to pass the value to
intilery-ios as configurations:
The same value for IDFA will used across all (device and cloud-mode) integrations.
Note: intilery-ios can continue to collect events without the IDFA until user is prompted and only upon user consent the
advertisingId field is added to the event payload
Ad-tracking affects two keys under the
context object of every event:
If your use cases don’t require the need for IDFA collection you can skip this setup and under your event context you will see not see the
device.advertisingId key/value in your event payload.
Add this line in your