How much does your SDK weigh, mParticle?

In the year 2012 Norberto Lopez Amado and Carlos Carcas directed the documentary How Much Does Your Building Weigh, Mr. Foster? They talk about the life and work of Norman Foster, the many challenges involved in all stages of creating functional structures, and how a disproportional amount of the weight, not only physical but also the work of designing and implementing, is hidden in the solid foundation of the infrastructure.

So, we asked ourselves: how much does the mParticle SDK weigh?

Different from the documentary, the SDK is not a physical object we can behold, but as in the documentary, the SDK has a weight, most of which is hidden beneath the method signatures of its API calls. It has a presence, not in the void space of the hard drive of a mobile device, but inside of a running application, which in itself provides a service to its user (entertainment, transportation, commerce, and more.)

The SDK has features and constraints, therefore, it can be measured by metrics of byte space and execution time. The work we put into crafting the SDK was such that it had to feel effortless from the perspective of integration by a developer and execution of its code by an app. Yet we all know there are tremendous challenges involved in order to accomplish that goal. Its presence had to be small, whereas its value, large.

At mParticle, we put a lot of thought and carefully crafted the muscularity of the SDK. It is incredibly strong, yet malleable to contour itself to the pressures applied by an app. Less code is used by focusing on the essence of the task to be completed, and at the same time, the execution of its code is surrounded with safeguard and integrity mechanisms. There are data type validations of external parameters, assertions active during development time, queueing of commands to guarantee their execution, and more. Last, but not least, there is care for running times, low-cost timers, offloading execution to background threads, and what to keep in memory or persist.

But, How Much does Your SDK Weigh, mParticle?

The answer to this question is divided into parts. To begin, we started by measuring the size of the SDK in Kilobytes. In an age of Terabytes, measuring sizes in Kilobytes almost feels like a rounding error. Nevertheless, it is of vital importance for an app to manage its size in order to run fast in the hands of its users.

Our metric methodology to measure the size of the SDK is the simplest available, within reach to all developers, and is extremely easy to reproduce and verify the results. Let’s create a new, empty, Xcode project, generate a binary, and measure its size. Then we will include the mParticle SDK to the project, generate another binary, and measure its size once again. The difference between the two measurements will give us the Kilobytes of the SDK.

Begin by creating a new Xcode project.

1. Launch Xcode and create a new project: Xcode > File > New > Project
2. From the dialog box select: Single View Application
3. Call it: SDK_Measurement
4. Save the project to a destination of your choice.
5. Make sure bitcode† is enabled: Targets > SDK_Measurement > Build Settings > Enable Bitcode = YES

† Not having bitcode enabled is equivalent to driving a car with a damaged piston, low pressure in the tires, overdue oil change, yet being worried that the grille may not be aerodynamic enough and is generating too much drag.

When bitcode is enabled, the App Store will optimize resources “by tailoring app delivery to the capabilities of the user’s particular device” (See App Thinning Documentation). This way, if your app will run on a iPhone 7, only the 64-bit part of the binary will be downloaded and installed on the device, the 32-bit portion of the binary stays behind.

We will use CocoaPods to include the mParticle SDK to our project. Before we generate the first binary, let’s prepare the environment. Switch to the project’s directory and initialize its pod.

$ cd SDK_Measurement

$ pod init

Now edit your Podfile like the one below:

target 'SDK_Measurement' do
    use_frameworks!
end

Even though there are no pods listed in the Podfile, let’s initialize the environment so CocoaPods can create the Xcode workspace we will be working from. Run:

$ pod install

We are ready to generate the reference binary.

1. Open SDK_Measurement.xcworkspace in Xcode
2. In the upper-left corner select the SDK_Measurement > Generic iOS Device scheme
3. Archive the binary: Xcode > Product > Archive
4. In the Organizer Archives tab select the archive and click the Export… button
5. Select Save for Ad Hoc Deployment
6. In the Device Support: screen, select Export for specific devices: and pick a device of your choice (I chose iPhone 7)
7. Follow the rest of the steps to generate the binary

Once the binary has been generated, switch to the directory where the .ipa is, and list its size using:

$ ls -hl
23K Feb 15 14:15 SDK_Measurement-iPhone 7.ipa

You will find the binary to be something around 23 Kilobytes.

We have our reference point, great! Now let’s add the mParticle SDK and repeat the steps above. The size of the new binary minus the size of the first measurement will give us the size of the SDK.

Edit the Podfile and include the mParticle pod, as shown below:

target 'SDK_Measurement' do
    use_frameworks!
    
    pod 'mParticle-Apple-SDK', '~> 7'
end

Update the Xcode workspace, and CocoaPods’ environment by updating the pods:

$ pod update

Go back to Xcode, clean the project and build to archive a new binary following the same steps above as we did to generate the reference binary.

Once the new binary is generated, list the new size:

$ ls -hl
417K Feb 15 14:48 SDK_Measurement-iPhone 7.ipa

You will find the size to be around 417 Kilobytes. Now we just need to subtract the size of the reference binary to find out the size of the SDK: 417 – 23 = 394 Kilobytes.

How much does it weigh?

Let’s see:

• It allows for 1st party data to be collected in the form of events, commerce events, and other occurrences
• It manages user attributes and user identities
• It understand rules programmed on the server side such as data filters and custom mappings
• It can forward data to partner platforms, encapsulating the complexity of implementing multiple SDKs
• It manages and tracks the lifecycle of applications
• It automatically manages sessions
• It manages when to communicate with the server via a series of criteria: upload interval, application state transition, and trigger events
• It secures the communication with the server by using certificate pinning (avoiding man-in-the-middle attacks), in addition to signing and encoding each batch, and TLS (Transport Layer Security)

By the partial list above we can see that the weight of the benefits of the SDK is phenomenally large. Yet, at the interaction point with an app via its APIs, it feels like the SDK is floating, weightless, in mid-air.

Regarding the size in Kilobytes, it might as well be considered as a rounding error.

PS: In the New Year we made a resolution to trim down the SDK a few bytes, making it smaller, more modularized, and faster wherever possible. After hitting the refactoring gym and sweating the bits away, the SDK has come down 13% in size. If you are running a version of the SDK prior to 7.0.0 and want to take advantage of the slimmer SDK, now is your chance to upgrade.