Our Android build was around 180MB.

A large part of it came from Unity's runtime, native libraries and bundled assets. We were shipping almost everything with the application, even though users didn't need all those resources when they first opened it.

We didn't want to compromise the 3D experience just to reduce the app size. So instead of spending more time on basic compression, we decided to revisit the architecture.

We eventually brought the initial application package down from 180MB to 34MB, an approximately 81% reduction.

Here's what we changed.

1. Getting the Architecture Right

We were using Flutter for the main application and Unity for the 3D experience. I wanted to keep both reasonably independent rather than mixing Unity-related logic throughout the Flutter codebase.

We followed Clean Architecture with three main layers:

Presentation: Flutter screens, BLoC, events and states.

Domain: Use cases, repository contracts and business rules.

Data: API integration, local storage, asset downloads and repository implementations.

We used flutter_bloc for state management.

This was particularly useful for workflows like Unity initialization, asset downloads and local synchronization, where multiple asynchronous operations were involved.

The UI only needed to know the current state. It didn't need to know how an asset was downloaded, verified or stored.

2. Integrating Unity with Flutter

We used unity_flutter to integrate the Unity experience into the Flutter application.

One thing we had to be careful about was communication between the two environments.

Flutter was responsible for the application UI, navigation and business logic. Unity handled the 3D rendering and Unity-specific operations.

We also worked with native platform channels to handle communication and lifecycle-related operations.

Our communication layer supported:

Sending commands from Flutter to native/Unity.

Receiving asynchronous events and status updates.

Handling Unity initialization and lifecycle changes.

Keeping communication independent of individual screens.

We used method-based communication for commands and event streams for asynchronous updates.

This helped us keep the integration manageable without coupling the entire Flutter application to Unity.

3. Getting Unity Assets Out of the Initial Download

This was probably the most important change.

Initially, we were shipping too many Unity resources as part of the application package.

We changed that approach and moved towards remote asset delivery using Unity AssetBundles.

Instead of including every resource in the initial build, we hosted assets remotely and downloaded them when required.

The general flow looked like this:

Fetch asset metadata and version information.

Check which assets are already available on the device.

Identify missing or outdated assets.

Download the required bundles.

Verify the downloaded files.

Make the assets available to Unity.

We also used LZ4 compression to manage asset size and loading performance.

Where needed, we handled downloads in smaller chunks rather than treating all resources as one large operation.

This reduced the amount of content that needed to be included in the initial application package.

4. Managing Assets on the Device

Remote downloads introduced another problem. We couldn't download the same assets every time a user opened the Unity experience.

We needed a proper local synchronization mechanism.

We added an asset-management layer that handled local availability, version checks and download status.

The basic idea was simple:

Check local assets first.

Compare their versions with remote metadata.

Download only missing or outdated resources.

Verify downloaded files before accepting them.

Reuse existing assets wherever possible.

This also helped us avoid unnecessary network requests.

We kept this logic outside the UI and exposed the synchronization status through BLoC.

That made it easier to handle loading states, failures and retry operations without adding more complexity to the screens.

5. Asset Integrity

When assets are downloaded remotely, validating them before loading is important.

We added verification to the download workflow so that incomplete or modified files wouldn't be accepted blindly.

We also used HMAC-based verification as part of our asset integrity approach.

The downloaded content was validated before being made available to the application.

This was particularly important because we were no longer shipping all resources inside the original application package.

6. Keeping Flutter and Unity Responsive

Moving assets to remote delivery solved the package-size problem, but it also meant we had to pay more attention to runtime behaviour.

We didn't want asset downloads, file operations or communication between Flutter and Unity to interfere with the rendering experience.

We kept expensive operations away from the UI thread, handled asynchronous work separately and paid attention to Unity's lifecycle and memory management.

Our target was to maintain a smooth 60 FPS experience while keeping asset loading and synchronization under control.

7. The Results

The biggest improvement was in the initial application size.

More importantly, we no longer needed to ship every Unity resource with the initial application.

Assets could be downloaded, verified, cached and synchronized independently.

Final Thoughts

One thing I learned from this implementation is that reducing application size isn't always about removing dependencies or compressing assets.

Sometimes the better solution is to change what you ship in the first place.

Flutter and Unity can work well together, but they need a clear separation of responsibilities. Asset delivery, native communication, local storage and lifecycle management should all be considered when designing the integration.

This was a good reminder that a small architectural change can make a much bigger difference than several rounds of build optimization.

If you're working with Flutter and Unity, I'd love to hear how you're handling similar challenges you can reach me out by - hrushikeshdesai.com