How ABI Splits Reduce Flutter APK Size

Understand why “split-per-abi” reduces APK size, how it works internally, benefits, limitations, and best workflow for production apps.

Introduction

When developing Android applications with Flutter, the final APK often becomes large because it includes native binaries for multiple CPU architectures. This creates a “universal APK,” which increases the app size even though a device only needs binaries for its own CPU. Flutter offers a clean solution to this through --split-per-abi, which generates separate APKs for each architecture.

This article explains exactly what ABI splits are, how they reduce app size, when to use them, the disadvantages, and the recommended approach for real production workflows.

What Is ABI? (CPU Architecture Explained)

ABI stands for Application Binary Interface. It defines how machine code is executed on a CPU. Android devices commonly use:

armeabi-v7a – 32-bit ARM
arm64-v8a – 64-bit ARM (most modern phones)
x86 / x86_64 – Emulator + some tablets

A universal APK contains native libraries for all architectures. This is unnecessary and increases size.

What Are Split APKs (ABI Splits)?

When you build using:

flutter build apk --release --split-per-abi

Flutter produces multiple APK files:

app-arm64-v8a.apk
app-armeabi-v7a.apk
app-x86_64.apk

Each file contains native binaries for only one CPU type. This means a user downloads only what their device needs.

How ABI Splits Reduce APK Size

In many real-world cases, a universal APK of 45–50 MB becomes:

arm64-v8a → 18–22 MB
armeabi-v7a → 22–25 MB

This is often a reduction of 30% to 60%, which makes app installation faster and improves user retention, especially in low-bandwidth countries.

Why Split APKs Improve User Experience

1. Smaller Download

Users download only required machine code → faster, lighter, and more accessible.

2. Faster Installation

With fewer binaries to unpack, the install process becomes noticeably quicker.

3. Less Storage Usage

Devices do not store unnecessary architecture binaries.

4. Better Ratings & Lower Uninstalls

Users often uninstall “heavy apps.” A smaller footprint improves long-term retention.

Downsides of Using ABI Splits

Although useful, there are some limitations you must consider.

1. Multiple APK Files

You end up with 2–3 APKs instead of one, which can confuse non-technical testers.

2. Manual Sharing Becomes Hard

If you send the app via WhatsApp or email, the other person may not know which file to install.

3. Not Ideal for Offline Distribution

In corporate environments or for .apk-only clients, universal APK is more convenient.

4. More Work for QA

Each ABI version should ideally be tested at least once.

Tip: If your app goes to Play Store, use an AAB instead of manually creating split APKs. Google Play automatically generates ABI-optimized APKs for each device.

When Should You Use ABI Splits?

Your app will be uploaded to Google Play Store
You want to minimize storage use
You want faster installation for end users
You target global markets with low network speeds

When You Should NOT Use Them

You distribute APKs manually to many clients
Your testers are non-technical
You need a single portable APK for business users

Recommended Best Practice for Production Apps

Always use App Bundles (AAB)

For Play Store releases, this is the best command:

flutter build appbundle --release

The Play Store will automatically create separate APKs for each user’s architecture.

Conclusion

ABI splits are a powerful way to reduce Flutter APK size and improve installation time. They are especially useful for global markets where users prefer lighter apps. While they introduce the inconvenience of multiple APK files, this is resolved when using AABs with Google Play. For production, using AAB + Play Store optimization is the most efficient and professional workflow.

Search This Blog

FlutterForest