Post cover image

May 5, 2026

This One pubspec.yaml Change Cut My Flutter App Size by 40%

The platform-specific asset syntax shipped in Flutter 3.41 and every existing tutorial still shows the old workaround. Here’s the actual…

By Mohit Gupta

4 min read

The platform-specific asset syntax shipped in Flutter 3.41 and every existing tutorial still shows the old workaround. Here's the actual fix, in about 10 lines of YAML.

My Flutter app was shipping a folder full of Windows-specific icons to every Android user who downloaded it.

They'd never see those icons. They didn't need them. But the app was dragging them around anyway — like packing a snow shovel for a trip to Chennai.

And the worst part? I thought I'd already fixed this. I had the Platform.isAndroid checks. I had the conditional loading logic. I'd done the thing every tutorial told me to do.

Turns out that whole approach was a workaround for a feature that didn't exist yet.

Flutter 3.41 shipped that feature. And almost nobody is talking about it correctly.

What Was Happening Before (And Why It Was Painful)

Before 3.41, Flutter had no way to tell the build system: "this asset is only for web." You declared assets in pubspec.yaml and they went into every build. Android, iOS, Windows, web — didn't matter. Every platform got everything.

So developers got creative. The most common pattern was runtime filtering — check the platform at runtime and just… not use the asset on platforms that don't need it.

// The old way: load the asset only if we're on the right platform
import 'dart:io' show Platform;

Widget buildLogo() {
  if (Platform.isWindows) {
    return Image.asset('assets/windows/logo_high_res.png');
  }
  return Image.asset('assets/shared/logo.png');
}

Here's the problem with this: the asset is still bundled. It's still sitting in your APK or IPA taking up space. You're just choosing not to display it. The runtime check doesn't touch what got packed into your app — it only controls what gets rendered.

So your Android users were downloading your Windows hi-res icons. Your web users were getting your iOS-specific SF Symbol replacements. Nobody needed any of it.

None

I discovered this at about 11pm on a Tuesday, doing a size analysis before a Play Store release. The assets/ folder in the APK was 6.2MB. The app itself didn't feel like it had 6.2MB of images. So I cracked open the APK — you can literally unzip one — and started digging.

Windows-specific folder: 1.1MB. Web SVG assets: 800KB. macOS icons: 600KB.

On Android. In an APK that would never, ever use them.

What Flutter 3.41 Actually Changed

Flutter 3.41 added a platforms key directly in your asset declarations inside pubspec.yaml.

This isn't a runtime check. It's a build-time declaration. You're telling the Flutter build system: "don't even include this in builds that aren't for this platform." The file never makes it into the bundle for other platforms.

That's a fundamentally different thing.

None 
# pubspec.yaml — Flutter 3.41+ platform-aware asset bundling
flutter:
  assets:
    # Shared assets — go into every build as before
    - assets/shared/logo.png

    # Windows-only assets — never touch Android, iOS, or web builds
    - path: assets/windows/
      platforms:
        - windows

    # Web-only SVGs — excluded from all native builds
    - path: assets/web/
      platforms:
        - web

    # Desktop-only (multiple platforms, one declaration)
    - path: assets/desktop/splash.png
      platforms:
        - windows
        - linux
        - macos

That's it. No Dart code. No conditional imports. No runtime checks. You declare intent in YAML and the build system handles the rest.

When you flutter build apk, the assets/windows/ directory simply doesn't exist in the output. When you flutter build web, assets/desktop/splash.png is never touched.

The Platforms You Can Target

The platforms key accepts: android, ios, web, windows, linux, macos. You can combine them freely.

flutter:
  assets:
    # Mobile-only — shared between Android and iOS
    - path: assets/mobile/
      platforms:
        - android
        - ios

    # All desktop platforms in one go
    - path: assets/desktop/
      platforms:
        - windows
        - linux
        - macos

One thing I tripped over: the path key. When you use platform-specific declarations, you need to switch from the flat string format (- assets/logo.png) to the object format (- path: assets/logo.png). Mix them up and you'll get a YAML parse error that won't immediately tell you what went wrong.

I spent 20 minutes on that. You're welcome.

None

What the Size Impact Looks Like in Practice

"40%" sounds like I made it up. Here's where it actually comes from.

If your app targets desktop and mobile and web, you probably have platform-specific assets in each bucket — different icon sets, different splash screens, different resolution variants optimized for each platform's display densities.

An app with:

  • 2MB of Android/iOS-only assets
  • 1.5MB of Windows/macOS-only assets
  • 800KB of web-only SVG assets

…was previously shipping the full 4.3MB to every platform. With 3.41's declarations, each platform gets only its slice.

Android users get ~2MB. Windows users get ~2MB. Web users get ~1.5MB. The cross-platform bloat disappears.

Your number will depend on how many platform-specific assets you have. If your app is truly cross-platform with rich per-platform visual assets, 30–50% download size reduction is realistic. If you mostly use shared assets, the impact is smaller — but even cleaning up a few folders adds up.

One Gotcha Before You Ship

If you're loading assets at runtime with rootBundle.load() or Image.asset(), your existing Platform checks won't cause crashes after this change. They'll just be redundant.

But if you had code that expected a platform-specific asset to exist on every platform (unlikely, but possible in some plugin setups), that will now throw at runtime on platforms where the asset wasn't bundled.

Run flutter build for each of your target platforms after making these changes. Don't just test on the platform you develop on.

// Safe asset loading with a fallback — good habit regardless
Future<void> loadPlatformAsset() async {
  try {
    final data = await rootBundle.load('assets/windows/icon.png');
    // use data
  } catch (e) {
    // Asset wasn't bundled for this platform — handle gracefully
    debugPrint('Platform asset not available: $e');
  }
}

This is mostly defensive programming. If your YAML declarations are correct, you won't hit this. But it's worth having during a migration.

GitHub issue #65065 sat open for six years. The request was simple: let developers declare which platforms need which assets, at build time, in the project config.

Flutter 3.41 closed it.

The old Platform.isAndroid tutorials aren't wrong — they just never actually solved the problem they were trying to solve. They controlled rendering. The new YAML syntax controls bundling. Those are different problems.

Check your current pubspec.yaml. Look at your asset folders. If you've got anything organized by platform, add the platforms key this week. Your users' download metrics will show it.

If this saved you from shipping a snow shovel to Chennai, give it a clap — I write about Flutter and mobile dev every week.