# Get Started  There's a new version available! These pages cover version 1 of our SDK, but a newer version is available. In general, we suggest that you update to the latest version to take advantage of new features and fixes. * Are you new to our SDKs? [Check out the latest docs.](/integrations/sdk/ios/getting-started) * Otherwise, [learn about updating to the latest version](/integrations/sdk/ios/whats-new/) Before you can take advantage of our SDK, you need to install the module(s) you want to use, initialize the SDK, and understand the order of operations. **This page is part of an introductory series** to help you get started with the essential features of our SDK. The highlighted step(s) below are covered on this page. Before you continue, make sure you've implemented previous features—i.e. you can't identify people before you initialize the SDK! ## How it works[](#how-it-works) Our SDKs provide a ready-made integration to identify people who use mobile devices and send them notifications. Before you start using the SDK, you should understand a bit about how the SDK works with Customer.io. **You must identify a person before you can take advantage of most SDK features**. You can send anonymous in-app messages in our latest updates, but you can’t send push notifications or capture event activity for anonymous devices/users. That means that you can’t track or respond to anything your audience does in your app until you identify them. In Customer.io, you identify people by `id` or `email`, which typically means that you need someone to log in to your app or service before you can identify them. While someone is “identified”, you can send events representing their activity in your app to Customer.io. You can also send the identified person messages from Customer.io. You send messages to a person through the Customer.io campaign builder, broadcasts, etc. These messages are not stored on the device side. If you want to send an event-triggered campaign to a mobile device, the mobile device user must be identified and have a connection such that it can send an event back to Customer.io and receive a message payload. ### SDK package products[](#sdk-package-products) To minimize our SDK’s impact on your app’s size, we offer multiple, separate SDKs. You should only install the packages that you need for your project. You must install the *Tracking* package. It lets you identify people, which you must do before you can send them messages, track their events, etc. Package Product Required? Description Tracking ✅ `identify` people in Customer.io MessagingPushAPN Receive push notifications over Apple’s Push Notification Service (APNs) MessagingPushFCM Receive push notifications over Google Firebase Cloud Messaging (FCM) MessagingInApp Receive in-app notifications ## Install the SDK[](#install) Follow **[Apple’s instructions](https://developer.apple.com/documentation/swift_packages/adding_package_dependencies_to_your_app)** to add `https://github.com/customerio/customerio-ios.git` as a dependency to your project in Xcode and select the individual [package products](#sdk-package-products) that you want to install. We recommend that you set the *Dependency Rule* to *Up to Next Major Version*. While we encourage you to keep your app up to date with the latest SDK, major versions can include breaking changes or new features that require your attention. [![select up to next major version when installing the sdk](https://docs.customer.io/images/xcode-install-sdk.png)](#fa35c2aacc54920cd1a52e6b21c39b49-lightbox) ### Install with CocoaPods[](#install-cocoapods) We typically recommend that you install the SDK using Swift Package Manager (SPM). However, if your app uses CocoaPods, you can find and install our pods by appending `CustomerIO/` to our packages—e.g. `CustomerIO/Tracking`. Package Product Required? Description CustomerIO/Tracking ✅ `identify` people in Customer.io CustomerIO/MessagingPushAPN Receive push notifications over Apple’s Push Notification Service (APNs) CustomerIO/MessagingPushFCM Receive push notifications over Google Firebase Cloud Messaging (FCM) CustomerIO/MessagingInApp Receive in-app notifications ## Initialize the SDK[](#initialize-the-sdk) Before you can use the Customer.io SDK, you need to initialize it. Any calls that you make to the SDK before you initialize it are ignored. The SDK uses a Singleton. You’ll need Track API credentials to initialize the SDK—your [Site IDEquivalent to the *user name* you’ll use to interface with the Journeys Track API; also used with our JavaScript snippets. You can find your Site ID under *Workspace Settings* > *API Credentials*](https://fly.customer.io/env/last/settings/api_credentials) and [API KeyEquivalent to the *password* you’ll use with a Site ID to interface with the Journeys Track API. You can generate new keys under *Workspace Settings* > *API Credentials*](https://fly.customer.io/env/last/settings/api_credentials), which you can find in Customer.io under [*Settings* > *Workspace Settings* > *API Credentials*](https://fly.customer.io/env/last/settings/api_credentials). 1. To get started, initialize the SDK. You’ll usually do this in the `AppDelegate` `application(_ application: didFinishLaunchingWithOptions)` function. ```swift import CioTracking class AppDelegate: NSObject, UIApplicationDelegate { func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil ) -> Bool { CustomerIO.initialize(siteId: "YOUR SITE ID", apiKey: "YOUR API KEY") // You can optionally provide a Region to set the Region for your Workspace: CustomerIO.initialize(siteId: "YOUR SITE ID", apiKey: "YOUR API KEY", region: Region.EU) return true } } ``` 2. When you want to use any of the SDK features, you use the shared instance of the class. ```swift CustomerIO.shared.track(...) MessagingPush.shared.application(...) ``` ### Configuration options[](#configuration-options) When you initialize the SDK, you can pass configuration options. In most cases, you'll want to stick with the defaults, but you might do things like change the `logLevel` when testing updates to your app or enable `autoTrackScreenViews` to automatically capture screen view events for your audience. Option Type Default Description `disableCustomAttributeSnakeCasing` boolean `false` **New in 1.28** Prior to SDK version 1.2.8, [we inadvertently snake-cased attributes](#attribute-snake-casing) (i.e. `myAttr` became `my_attr`). Set to `true` to preserve custom attributes exactly as you pass them to the SDK. `autoTrackDeviceAttributes` boolean `true` Automatically gathers information about devices, like operating system, device locale, model, app version, etc `autoTrackPushEvents` boolean `true` The SDK automatically generates `delivered` and `opened` metrics for push notifications sent from Customer.io `autoTrackScreenViews` boolean `false` If true, the SDK automatically sends `screen` events for every screen your audience visits. `autoScreenViewBody` strings When `autoTrackScreenViews` is true, use this to override the the body of automatic screen view events. See [automatic screen tracking](/sdk/ios/1.x/track-events/#auto-screenview) for more information. `backgroundQueueMinNumberOfTasks` integer `10` See [the processing queue](/sdk/ios/1.x/getting-started/#the-processing-queue) for more information. This sets the number of tasks that enter the processing queue before sending requests to Customer.io. In general, we recommend that you don't change this setting, because it can impact your audience's battery life. `backgroundQueueSecondsDelay` integer `30` See [the processing queue](/sdk/ios/1.x/getting-started/#the-processing-queue) for more information. The number of seconds after a task is added to the processing queue before the queue executes. In general, we recommend that you don't change this setting, because it can impact your audience's battery life. `logLevel` string `error` Sets the level of logs you can view from the SDK. Set to `debug` to see more logging output. ```swift CustomerIO.config { $0.autoTrackScreenViews = true } ``` #### Attribute snake-casing[](#attribute-snake-casing) In versions of the SDK prior to 1.2.8, functions that let you send custom data—`trackEvent`, `screen`, `identify` and `deviceAttribute` calls—inadvertently converted custom data property names to `snake_case`. This bug is fixed in v2 of the iOS SDK. But, if you’re not ready to update your SDK implementation, you can use the `disableCustomAttributeSnakeCasing` configuration option in version 1.2.8 or later to make sure that the SDK respects your attribute names. ```swift CustomerIO.config { $0.disableCustomAttributeSnakeCasing = true } ``` *This bug didn’t surface with all data; it did not affect you if you already snake-cased your data; and it did not affect our Android SDK.*. ```swift // If you passed in custom attributes using camelCase keys: data = ["firstName": "Dana"] // The SDK < v1.2.8 may have converted this data into: data = ["first_name": "Dana"] // Or, if you used a different format that was not snake_case: data = ["FIRSTNAME": "Dana"] // The SDK < v1.2.8 may have converted this data into: data = ["f_irstname": "Dana"] ```  Check your data index to see if you were impacted The **Data & Integrations** > **Data Index** page shows a list of attributes and events in your workspace. You can check your data index to see if any of your data was misshaped by previous versions of the SDK. See our [iOS 2.0 migration page](/integrations/sdk/ios/migrate-upgrade/#we-fixed-a-bug-with-custom-attributes-that-may-impact-your-data) for some strategies to deal with with misshaped attribute names. ## The Processing Queue[](#the-processing-queue) The SDK automatically adds all calls to a queue system, and waits to perform these calls until certain criteria is met. This queue makes things easier, both for you and your users: it handles errors and retries for you (even when users lose connectivity), and it can save users’ battery life by batching requests. The queue holds requests until any one of the following criteria is met: * There are 20 or more tasks in the queue. * 30 seconds have passed since the SDK performed its last task. * The app is closed and re-opened. For example, when you identify a new person in your app using the SDK, you won’t see the created/updated person immediately. You’ll have to wait for the SDK to meet any of the criteria above before the SDK sends a request to the Customer.io API. Then, if the request is successful, you’ll see your created/updated person in your workspace. ### How the queue organizes tasks[](#how-the-queue-organizes-tasks) The SDK typically runs tasks in the order that they were called—unless one of the tasks in the queue fails. Tasks in the queue are grouped by “type” because some tasks need to run sequentially. For example, you can’t invoke a `track` call if an `identify` call hasn’t succeeded first. So, if a task fails, the SDK chooses the next task in the queue depending on whether or not the failed task is the first task in a group. * **If the failed task is the first in a group**: the SDK skips the remaining tasks in the group, and moves to the next task outside the group. * **If the failed task is 1+n task in a group**: the SDK skips the failed task and moves on to the next task in the group.\*\* The following chart shows how the SDK would process a queue where tasks A, B, and C belong to the same group.