About mobile connection modes

Segment defaults to using cloud-based connection mode (“cloud-mode”) for any destination connected to a mobile source, because this can help decrease the size of your final app package. When you use cloud-mode, Segment sends messages to the Segment servers, and then translates and forwards that data on to the downstream tools. This way, you only package the Segment mobile library with your app.

However, many destination tools that specifically deal with mobile interactions require that you use a device-based connection mode (“device-mode”) so that they can collect information directly on the mobile device. (You can check the full list of destinations and which connection modes they support.)

If you plan to use destinations that require device-mode, you must package the Segment-integration version of that tool’s SDK along with the Segment source library in your app. The Segment-integration SDK allows you to still collect the data with Segment, but also enables any device-based features, and still saves you space.

When you package a tool’s device-mode SDK with the Segment SDK, Segment sends the data directly to the tool’s API endpoint. Segment then also adds the tool to the integrations object and sets it to false, so that the data is not sent a second time from Segment servers.

For example, if you bundled the Segment SDK and Segment-Intercom library, you would see this in your payload:

"integrations": {
  "Intercom": false
  },

When you package Segment and the Segment-integration SDKs, you must use a dependency manager (such as Cocoapods or Gradle) to ensure that all SDKs are compatible and all of their dependencies are included. Segment does not support bundling mobile SDKs without a dependency manager.

Packaging Device-mode destination SDKs

You can find the instructions for packging (or bundling) mobile SDKs in the instructions for each library:

• iOS
• Android
• React Native

Bundled SDKs vs. cloud-mode destinations for mobile

When it comes to Mobile SDKs, we know that minimizing size and complexity is a priority for our customers. That’s why our core Mobile SDKs are small and offload as much work as possible in handling destinations to our servers. When you install our lightweight SDK, you have access to our entire suite of server-side destinations.

Why do some destinations require bundling their SDKs?

However, we bundle certain SDKs (instead of just sending your data to them from our servers) so that you have access to their features that require direct client access (A/B testing, user surveys, touch heatmapping, etc) or access to device-data such as CPU usage, network data, or uncaught / raised exceptions. For those types of features, we still need to bundle the destination’s native SDK so you can make the most of them.

We work hard to make our mobile SDKs as modular as possible so you only need to include the SDKs for tools you plan to use.

These lightweight Segment-tool-SDKs allow us to offer the native functionality of all of our destinations without having to include hefty third-party SDKs by default. This gives you control over size and helps prevent method bloat. 

Check out how to use custom builds for both Android and iOS

Which destination’s SDKs can be bundled?

To check if a destination can be bundled or not, look at the connection modes referece page and find the line for that specific destination. 

If a destination has a checkmark in the “Device - Mobile” column, it can be bundled.