Ask HN: Am I crazy or is Android development awful?

Hacker News Discussion ↗

Many developers describe native Android development as slow, fragile, and overly complex, citing Android Studio’s performance, Gradle’s opacity, constant API churn, and tangled legacy design as major pain points. While some note it has improved since the Eclipse/Ant era and praise Kotlin and Jetpack Compose, others argue the ecosystem still suffers from poor documentation, architecture fatigue, and tricky compatibility issues, especially when dealing with native code or unusual hardware like USB webcams. As a result, a significant number of programmers prefer alternatives such as Flutter, React Native, web-based UIs, or even Linux-based phones, especially for rapid prototyping or “hacker-friendly” projects.

Overall sentiment on Android development

  • Many describe native Android dev as frustrating, bloated, and fragile, especially for beginners and for anything “off the happy path.”
  • Several long-time Android devs say it has improved since the Eclipse/Ant days, but still “sucks,” just slightly less.
  • Some argue it’s mainly a steep learning curve comparable to modern web or Python ecosystems; others insist Android is qualitatively worse.

Tooling: Android Studio, Gradle, build systems

  • Android Studio is widely called slow and resource‑hungry, even on modern machines; just creating projects can feel sluggish.
  • Gradle is labeled the “single worst thing” by several: complex, hard to debug, yet unavoidable. Kotlin DSL is seen as only a minor improvement and still “just Gradle.”
  • A minority prefer Bazel or custom setups; others reminisce about Ant/Maven while acknowledging those were also painful.

APIs, architecture, and technical debt

  • Android is framed as burdened with deep, “baked‑in” technical debt from early rushed design and backwards‑compat decisions.
  • Complaints about inconsistent APIs, hostile or missing events (e.g., soft keyboard appearance), and esoteric, version‑dependent edge cases.
  • Deprecation churn and OS fragmentation force conditional code paths and tricky support for older devices.

Languages and UI frameworks

  • Kotlin is praised as pleasant and powerful, especially with Jetpack Compose, but some find it feature‑heavy and hard to learn.
  • XML‑based UI and data binding are considered legacy and slow; Compose is seen as a big improvement and roughly on par with React‑style declarative UIs.
  • Some prefer Flutter or React Native/Expo for faster iteration and cross‑platform support, though there’s skepticism about Google’s long‑term commitment to Flutter.

Native code, hardware access, and niche use cases

  • Accessing USB devices (e.g., UVC webcams) via libusb/libuvc inside Android apps is described as possible but painful and poorly supported.
  • Using NDK and native libraries can work but has sharp edges: build complexity, ABI quirks, page-size changes (Android 15), dependency hell.
  • For specialized hardware projects, several suggest small Linux SBCs instead of phones.

Comparisons with other platforms

  • iOS dev is portrayed as more coherent and consistent at the API level but with its own tooling and SwiftUI rough edges.
  • Web development is seen as easier for prototyping, especially via the browser’s camera APIs.
  • Some use WebView wrappers, Ionic/Capacitor, or Termux to escape parts of the native stack or to get a more “Linux‑like” environment.