The impact of the App Center SDK for iOS on your app’s binary size

TL;DR

Although the .framework packages of the App Center SDK look big at first glance, they have a minimal impact on your app’s release binary size. If you add all of App Center’s services to your app, your app’s installation size should increase by about 800KB. Your mileage may vary a little.

Background information

Time and again, we get customers who integrate our SDKs and are concerned about the size of our SDK when they integrate the SDK. This is understandable, as the App Center SDK is distributed as .framework packages that range from 1.7MB for App Center Analytics, to 13.4MB for App Center Crashes. The thing is, those sizes are misleading. Our SDK is, in fact, designed to have a minimal footprint when it is integrated into an app. In fact, a minimal footprint is why we created a modular SDK in the first place (I’ve blogged about this in the App Center blog), developers can pick the functionality they want, and don’t have to worry about their app size at all. So why are the .frameworks so big. The answer is really simple, they are “fake” fat frameworks, statically linked frameworks in disguise. The reason for this is rather simple: performance at app launch time. But let’s focus on their impact on an apps binary size. As the term “fat framework” implies, they contain slices for all architectures, meaning all device CPUs as well as the iPhone/iPad simulators. If you build your app for a specific target, the compiler will actually strip the unused ones. In addition to that, depending on your compiler/build settings, the compiler will strip away even more stuff, because it is smart. With Bitcode enabled, things get even more compacted and then, there’s also App Thinning. If your app’s size is important to you, you should check those techniques out.

How I measured

I created a really simple app using Xcode 9.2 and its default template for an app with one single view controller. I added two buttons, one that calls trackEvent: on the App Center Analytics module, and one to crash the app intentionally. You can check out the project on Github.

  • I did not make any changes to Xcode’s default build settings.
  • I created a release build using Xcode and then exported the .ipa manually using Xcode’s Organizer.
  • I did not use Bitcode.
  • I did not use App Thinning.
  • I installed the app on my iPhone 7 that’s running iOS 11.3 using the Apple Configurator app.
  • I launched the app once to make sure the SDK is initialized.
  • I checked Settings > General > iPhone Storage and made sure it refreshed the data for my AppSizeSample app after each install.
  • I removed the app after each install.
  • I installed each variant of the app twice (and deleted it manually before).

Results

Take these with a grain of salt as I didn’t change any of Xcode’s default settings, and because I only measured with 1 app and 1 device. Your mileage may vary but my measurements should give you a pretty good idea of how “big” the impact of the SDK is.

App Center modules used Exported IPA size Installation size
None (blank app) 24KB 132KB
App Center Analytics 120KB 377KB
App Center Crash 239KB 705KB
App Center Analytics & Crash 250KB 741KB
App Center Distribute 163KB 528KB
AppCenter Analytics, Crash & Distribute 307KB 913KB
App Center Push 115KB 377KB
All App Center modules 314KB 930KB

The numbers are interesting as they don’t just “add up” because all modules share the same “core”, a module named “App Center” that contains shared logic for persistence and network i/o plus I suspect the compiler to be pretty smart about even more things.

In addition to that, the App Center SDK will use between 29KB and up to 1.2MB of space for “Documents & Data”. The amount varies depending on your internet connection as App Center buffers up to 300 event logs and 300 crash logs when offline.

Anyway, I hope this answers some questions.

What else?

  1. Check out App Center, it’s awesome. We’re on Twitter, too. Get in touch if you have feedback.
  2. Our SDK is open source on Github. Check that one out, too.
  3. If you’re interested in learning more about static vs dynamic frameworks, Samantha has you covered. You should read her blog anyways. 😉 And send her some money through her Paypal because her blog is awesomesauce.
  4. Do what I did on your device and let me know your numbers!

Final words

Thanks for reading, please get in touch if you have further questions or feedback.

Cheers,

Benjamin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s