When clients evaluate our SDK at Bureau, one of the most common questions our sales team gets is: “How heavy will the SDK be?” and “Will this bloat our app?”

‍

In this article, we explain why app or framework sizes can differ between iOS and Android, and how understanding these differences helps us at Bureau build a lightweight, modular SDK that’s easy to integrate and doesn’t bloat your app.

‍

The Bottom Line: What You Need to Know About Our SDK

‍

‍

Our team is ready to provide detailed answers about size impact, integration process, and any platform-specific considerations for your app. You can also go through FAQs: 

• Bureau SDK integration for Device Intelligence FAQs
• Bureau SDK integration for Behavior Biometrics FAQs

‍

To continue on why the size impact varies slightly between iOS and Android, there are technical differences that we have highlighted below.

‍

Why Does the Same App Have Different Sizes on iOS and Android?

‍

1. Platform Architecture and Binary Formats

‍

iOS:

Apple uses Ahead-of-Time (AOT) compilation, meaning Swift/Objective-C code is compiled into native machine code before execution.

iOS apps are packaged as .ipa files using the Mach-O format. While it’s optimized for performance, it can increase binary size.

Historically, iOS binaries included multiple architectures (like armv7 and arm64). While Apple has streamlined this with newer devices all using arm64, legacy support can still increase app size.

‍

Android:

Android apps use a combination of Just-in-Time (JIT) and AOT with ART (Android Runtime).

Android apps are compiled into Dalvik Executable (DEX) bytecode, which is then converted to native code at runtime (thanks to ART). This intermediate step can sometimes make Android apps smaller, but it also depends on how resources are managed.

‍

We ensure the Bureau SDK is compiled natively and supports only required architectures, avoiding unnecessary bloat on both platforms.

‍

2. Bundled Libraries & Dependencies

‍

iOS:

Uses pre-built frameworks like UIKit or CoreData, which are part of the OS but still add to the binary size. Third-party libraries (like CocoaPods dependencies) may increase size if not optimized.

‍

Android:

Android apps use libraries like AndroidX, which are modular and can help reduce size. However, including unnecessary dependencies or large third-party libraries (like Google Play Services) can quickly inflate the app size.

‍

We are highly selective with dependencies. Our SDK avoids monolithic libraries and includes only what’s absolutely essential.

‍

3. Asset Handling & Compression

‍

iOS:

iOS requires specific resolution assets for different device types. Your app bundle includes multiple versions of the same image to handle everything from an old iPhone SE to the latest Pro Max models.

‍

Apple uses App Thinning, which delivers only the necessary resources to each device. For example, a 64-bit device won’t download 32-bit binaries. This helps reduce the download size but not the actual app size in the store.

‍

Android:

Android uses a resource qualifier system where resources are organized in folders based on screen density, language, and other factors.

‍

Android uses APK Splits or App Bundles to create device-specific APKs. This means users only download the resources and libraries relevant to their device, which can significantly reduce the download size.

‍

Bureau’s SDK uses minimal assets, and where used, supports App Thinning (iOS) and App Bundles (Android) to avoid unnecessary downloads.

‍

4. ProGuard (Android) vs Bitcode (iOS)

‍

iOS:

Bitcode (originally used for optimization) was deprecated in Xcode 14, but size optimization can still be done via compiler flags and dead code stripping.

‍

Android:

ProGuard and R8 are powerful tools to shrink, optimize, and obfuscate Java/Kotlin code to reduce size.

‍

We ship our Android SDK with ProGuard/R8 rules and ensure unused code is stripped. On iOS, we guide clients on enabling Dead Code Stripping.

‍

5. Programming Languages

‍

iOS:

Swift and Objective-C are the primary languages. Swift binaries can sometimes be larger due to runtime overhead, but Apple has been improving this with each release.

‍

Android:

Java and Kotlin are the primary languages. Kotlin, being more concise, can sometimes result in smaller bytecode, but this depends on how the code is written.

‍

We write clean, modular code optimized for each platform’s build process. 

‍

How Our SDK Optimizes for Both Platforms

We've implemented platform-specific optimizations to ensure our SDK remains lightweight regardless of which platform you're developing for:

1. Modular Design: Only the features you actually use are included in your final build
2. Optimized Assets: We use vector graphics and compressed resources where possible
3. Minimal Dependencies: We avoid unnecessary third-party libraries that would bloat your app

‍

Simple to Integrate  

We understand that integration complexity is a major concern. Our SDK is designed with simplicity in mind:

• Clear Documentation: Step-by-step guides for both platforms
• Sample Apps: Functional examples demonstrating integration patterns
• Support Team: Direct access to our engineering team during implementation
• CI/CD Compatible: Easy to incorporate into your automated build processes

‍

Best Practices We Follow to Keep Our SDK Lightweight

Our engineering team follows these practices to ensure our SDK remains efficient:

• Code Optimization: We use ProGuard/R8 for Android and appropriate compiler optimizations for iOS
• Asset Management: Compressed and optimized resources for all screen densities
• Dead Code Elimination: We strip unused code to minimize footprint
• Continuous Optimization: Regular code audits and dependency reviews

‍

This article was written by our enthusiastic Lead Mobile Developer, experienced in all phases of mobile app development - Suryakant Sharma.
‍

‍