Why is the Oral-B iOS app almost 300 MB? And why is Colgate's app even bigger..?

Original Article ↗ Hacker News Discussion ↗

App Size and Technical Causes

  • Main discovery: Oral-B iOS app ~300 MB; Colgate’s even larger. Much of Oral-B’s size is attributed to bundled PDFs and many large image assets for product models.
  • Several commenters argue these images could be far smaller (hundreds of KB each, better formats like AVIF, vector graphics) or fetched on demand.
  • Others say shipping assets locally avoids mandatory internet dependency and CDN costs, but even then call the packaging “lazy” or “unoptimized.”
  • Comparison: Android version of Oral-B app is ~67 MB, suggesting platform/tooling and team differences.
  • Broader point: many iOS apps are large due to Swift, third‑party libraries, and lack of aggressive dead‑code removal; Android’s modern app format is cited as more size‑efficient.

“Why Does a Toothbrush Need an App?”

  • Skeptical view: apps exist primarily to collect data, enable marketing/upselling, and create another push‑notification/channel to the user.
  • Some see it as emblematic of “late-stage tech” and IoT excess; a $2 manual or simple electric toothbrush is considered sufficient.
  • Supportive view: apps can:
    • Track brushing duration, frequency, and pressure.
    • Provide quadrant/coverage guidance and pressure feedback.
    • Gamify brushing, especially for kids (animations, avatars, streaks).
    • Help habit‑formation for users who respond well to quantified feedback.

Privacy, Data, and Monetization Concerns

  • Many worry about:
    • Health and device IDs being collected and correlated via data brokers.
    • Potential future ties to insurance pricing or targeted advertising.
    • Overbroad permissions (contacts, location, media) and dark patterns.
  • Others note much of this tracking logic is small; the bloat is mostly assets and generic ad/analytics SDKs.

Design, Ethics, and Regulation

  • Some argue a toothbrush app should not embed AI/ML models or require an app for core functions (e.g., changing modes).
  • Proposed principle: if a feature can be done on‑device without an app, it should not require one.
  • Debate on whether regulation/consumer‑protection should restrict “defective by design” products vs. letting the market reject them.

Developer and Industry Reflections

  • Agency‑built brand apps are portrayed as driven by marketing whims, analytics, and library stacking, not efficiency.
  • Observed correlation: organizations with better internal security/engineering culture tend to ship smaller, cleaner apps.
  • Some developers admit their own apps have grown large due to piling on features, libraries, and media, even when core functionality is simple.