Rawdrawandroid – Build Android apps without any Java, in C and Make

Original Article ↗ Hacker News Discussion ↗

Overall reaction to rawdrawandroid

  • Many are enthusiastic about bypassing Java/Kotlin and Gradle, writing Android apps in C with Make and simple CLI tooling.
  • It’s seen as “liberating” and philosophically appealing: directly targeting bits and system APIs instead of heavy frameworks.
  • Others are wary, noting that most Android libraries (SSO, Material, Google services) are Java/Kotlin, so a pure‑C approach limits what you can “reasonably” build.

Android tooling frustration

  • Strong and repeated complaints about Android Studio, Gradle, and dependency “rot”: opening a project after months often forces upgrades that break builds.
  • Some claim things have stabilized; others report recent painful upgrades and inscrutable multi‑GB build artifacts.
  • Similar frustrations exist for Xcode; some want a fully scriptable pipeline using editors like VS Code.

Scope and limitations of the NDK/C approach

  • This approach is described as ideal for OpenGL‑style, full‑screen, relatively self‑contained apps (games, visualizers, media players).
  • It leans on NativeActivity/NDK patterns that already exist; rawdrawandroid is a thin, cross‑platform framework on top.
  • It does not reimplement Android frameworks in C, and NDK access to higher‑level Android features is limited; accessibility is largely unaddressed.

Alternative stacks and cross‑platform options

  • PWAs are suggested as the first option; if Play Store presence or missing APIs block you, wrap the PWA in a thin native shell.
  • People report Play Store still enforcing API‑level updates even for PWA wrappers, which is burdensome for hobby projects.
  • Other options mentioned: Flutter (with mostly hidden Gradle/Xcode), React Native + Expo, game engines (Unity, Unreal, Godot, LibGDX), SDL, Love2D, Defold, Kivy.
  • CLIs and Makefiles using sdkmanager and NDK tools can avoid Android Studio, but still require JDK and large SDK installs.

Build tools: Make vs Gradle/Maven

  • Some celebrate Make’s simplicity and universality despite its clunky syntax.
  • Others argue Gradle/Maven are natural evolutions that handle complex graphs, caching, and parallelization, though Gradle is criticized for API churn and complexity.
  • There is debate over Maven vs Gradle performance, correctness, and configurability, with no clear consensus.

Language and safety debates

  • C is criticized for memory‑safety issues; Rust and Zig are suggested as better long‑term choices, possibly via C FFI.
  • Some argue moving from Java to C is a regression; others note C ABI makes it easier to support many languages (Rust, Zig, Lua, Janet, etc.).
  • Heated side debate about Java’s suitability for low‑level work (object overhead, bounds checks, lack of unsigned types, SIMD APIs still evolving).