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

Original Article ↗ Hacker News Discussion ↗

A minimalist Android framework that lets developers write apps in C with Make instead of Java/Kotlin and Gradle is attracting interest from those frustrated with heavyweight, brittle Android tooling. Commenters praise the ability to target Android via a thin OpenGL/NDK layer and standard command‑line tools, but note it’s realistically suited to fullscreen, graphics‑driven apps rather than software needing deep integration with Android’s Java‑based frameworks. The thread broadens into comparisons with PWAs, Flutter, game engines, and alternative languages like Rust and Zig, highlighting a wider desire for lighter, more controllable mobile development stacks without complex IDEs or build systems.

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).