How I Kept a 4K Media Client Under 1 MB (When Every Player App Weighs 100 MB+)

I build small software. My latest project, RKMovies, is a 4K-capable media client for Android and Windows that ships as a 0.91 MB APK. Not 91 MB — 0.91 MB. The average video player on the Play Store is 50–200 MB, and I wanted to understand exactly where that weight comes from, so I made an app with none of it.

Here's the build diary: what I cut, what I kept, and what the trade-offs actually cost.

Where the 100 MB goes in a typical player

Strip a mainstream player APK open and the bulk is almost never the playback logic:

• Bundled codecs — shipping ffmpeg or libmpv adds 30–70 MB on its own
• UI frameworks — React Native/Flutter runtimes, webviews, animation libs
• Analytics SDKs — crash reporters, A/B flags, attribution trackers, each pulling in dependencies
• Onboarding assets — illustrations, Lottie files, intro videos

None of that is video playback. All of it is product surface.

What I did instead

System codecs only. Android's MediaCodec and Windows' Media Foundation are already on the device, hardware-accelerated, and maintained by the OS vendor for free. NVDEC/QuickSync/MediaCodec paths give you 4K decode without shipping a single codec byte. The app is a thin orchestration layer: demux the container, hand streams to the system decoder, composite the surface.

Canvas-rendered UI. The player HUD is drawn on a Canvas — dual-zone gestures (left = brightness/volume, right = seek/speed/track cycling), no DOM, no widget tree. It costs hundreds of KB, not tens of MB.

No accounts, no telemetry. No Firebase, no analytics, no login. This is as much a size decision as a privacy stance — tracking SDKs are transitive-dependency factories.

Subtitles via WebVTT. SRT parsing converted to WebVTT keeps the subtitle pipeline inside the browser/platform primitives.

The result: 0.91 MB APK, 27 MB Windows installer, under 15 MB RAM at 4K playback, and it runs on 2 GB RAM phones that choke on mainstream players.

What that size budget buys you

Smaller binaries are not just an engineering flex — they change who can use the app:

• 2 GB RAM phones (still a huge installed base in India and SEA) stay smooth
• Downloads fit in a few seconds on 2G/3G data plans
• No "insufficient storage" install failures
• Zero background services, so battery drain tracks actual playback, not ad SDK housekeeping

The honest trade-offs

System codecs mean codec availability varies by device — an old Android build might lack HEVC 10-bit, where a bundled-codec app plays everything. Multi-track audio (Hindi/Tamil/Telugu/English switching is a core feature for my users) works fine through system paths, but exotic containers can need a fallback. And a Canvas HUD means no accessibility widget tree for screen readers — something I'm still working on.

If you're building for markets where a 150 MB download is a real barrier, the system-codec path is criminally underused. The device already paid for the silicon; your app doesn't need to bring its own.

---

Disclosure: I'm the developer of RKMovies — you can see how the size claims hold up at rkmovies.dpdns.org, with the Android APK at rkmovies.dpdns.org/apk and the Windows installer at the desktop page.