Why is the Gmail app 700 MB?

Original Article ↗ Hacker News Discussion ↗

Technical causes of Gmail’s size

  • External analyses show:
    • ~300 MB main executable.
    • ~130–150 MB localization data.

    • 20k files, ~17k under 4 KB; 4 KB filesystem blocks waste ~50–55% of localization space.

  • Heavy use of shared internal C++/Go/Java libraries, protobuf/gRPC, networking stacks (e.g. QUIC/Cronet), analytics, payments, security, etc., all statically linked because iOS offers no cross‑app shared libs.
  • Gmail is effectively a “super app” bundling Meet/Chat/Spaces, video chat codecs and logic, possibly AI models and auth flows, so all that ships even if you just read mail.
  • AOT compilation and multiple layers of fallback implementations (for reliability) add more compiled code.

Localization and Apple’s role

  • Localization is a major culprit:
    • Tens of thousands of .strings files, many tiny, one table per language; long keys, duplicated translations (e.g. “Cancel” dozens of times).
    • iOS bundles all locales in each app; no built‑in per‑language download like Android App Bundles or Meta’s custom language packs.
  • Some consider this partly Apple’s fault: the default localization system is space‑inefficient and doesn’t deduplicate well.

Wider app bloat and comparisons

  • Many non‑Google apps are similarly huge: drone controllers, robot vacuums, keyboard/mouse configurators, RGB controllers, banking and crypto apps often approach or exceed 1 GB.
  • Common bloat sources: embedded tutorial videos, high‑res assets per device, Flutter/Qt/Python runtimes, massive projections/font datasets, analytics and ad SDKs, and years of dead/legacy code.
  • Android versions of the same apps are usually significantly smaller (Gmail ~150–230 MB), helped by compressed APKs, split APKs, and system WebView.

Organizational and incentive issues

  • Several comments argue the root cause is cultural:
    • Size is rarely a tracked product metric; no promotion or OKR for slimming apps.
    • Refactoring shared/internal libraries is politically risky and technically hard; dead code and unused assets accumulate.
    • Hardware and cloud economics (bigger phones, iCloud/Drive upsells) remove external pressure to optimize.

Reactions and alternatives

  • Some see 700+ MB for an email client as technically shameful, especially compared to tiny native clients or old OS+office stacks fitting in less space.
  • Others argue it barely matters on 128+ GB devices and users can choose lighter clients or PWAs if they care.