ddc is a fast APK index before it is a source recovery tool
A full decompile is only one of ddc's jobs. Fifteen query subcommands can list classes, find strings and references, inspect a hierarchy, extract manifest facts, or decompile one method. That matters when the question is "where is this hostname used?" rather than "show me the whole application." Output can be text, tables, Markdown, JSON, or JSONL, so the same command works at a terminal and inside a larger analysis pipeline.
The distinction protects buyers from the wrong expectation. ddc emits Java that passes a syntax check across the project's corpus, but its README does not claim perfect source reconstruction. A separate full-classpath battery over 0.91 million files leaves about 7,500 errors attributable to ddc, with jadx at roughly half that number. The gap is concentrated in type recovery. Fast triage is the strong case; a final human reading may still belong in jadx.
DEX 035 through 041 and APK containers are covered
The parser handles the standard DEX versions from 035 to 041, multi-dex APKs, and XAPK, APKS, and APKM containers. It recovers useful Java forms such as lambdas, method references, and string concatenation from newer bytecode patterns. Kotlin null-check noise is removed, synthetic access bridges can be folded into call sites, and Android constants can replace opaque integers. Those changes make emitted code easier to scan without claiming it matches the original source.
Architecture is split across 3 crates. One reads DEX containers and instructions, another lifts registers into an intermediate form and emits Java, and the CLI handles containers, resources, localization, and queries. The shared jdc-core crate also powers a JVM class-file decompiler. The 44,848 source lines in our checkout are substantial for a project created in September 2026, yet the documentation maps the major passes closely enough to debug a wrong result.
What happened when we ran it
Our sandbox installed commit 121e198 in 12 seconds, bringing in 29 packages. A release build completed in 45 seconds. cargo test then finished in 18 seconds with 152 passed and 0 failed. The checkout occupied 6.5 MB and contained 69 files. These are repository checks, not an independent decompilation speed or accuracy benchmark.
The run used an unprivileged container with 3 CPUs and 12 GB of RAM. We found 2 CI workflow files, no Dockerfile, and no separate tests directory. Rust commonly keeps unit tests next to the code, and the 152 passing results show that tests were present despite that directory signal. We did not feed ddc the project's 39-APK corpus, compare its Java to source, or reproduce the performance tables in the README.
REST and MCP expose the same typed reports
Release v0.1.26 added HTTP REST and MCP frontends around the query commands. ddc serve publishes both an OpenAPI document and a streamable MCP endpoint, while dedicated modes can run REST alone or MCP over standard input or HTTP. Structured reports avoid scraping terminal tables. That makes ddc unusually easy to place behind an internal analysis service or give to an MCP client as a bounded set of APK tools.
Serving a reverse-engineering tool deserves more care than running one command. The help includes bearer authentication, TLS, and CORS examples, but an operator still chooses the bind address and access policy. APK contents may be proprietary or hostile. Keep uploads isolated and do not expose the service anonymously. A local binary needs none of this, and our 18-second test run did not exercise a live HTTP or MCP endpoint.
Syntax-clean Java can still be semantically wrong
The README says all emitted files in its 7-app headline set parse with javac, covering 909,689 files. It immediately qualifies that result: missing Android classpaths cause normal diagnostics, and rare register-heavy methods can produce a local with the wrong type. A few large methods fall back under a deadline and may vary between runs. These are the sorts of limits a decompiler should state plainly.
Open issue 2 supplies a sharper warning from an older v0.1.4 comparison. On one small APK, the reporter found undeclared variables, wrong types, an invalid return, and a missing nested class, while jadx produced much cleaner source. The maintainer shipped a newer version in response, but the issue remains open. That report does not describe v0.1.26 as a whole. It does support the README's current advice that type recovery still trails jadx.
October activity shows quick maintenance on a young project
Version v0.1.26 was published on October 6, 2026, the same date as the latest push. GitHub showed 360 stars and 1 open issue on October 7. Recent work added structured output and the server frontends, fixed stale field reads and lost exception-path values, and closed a filename collision that could overwrite non-ASCII classes. Two CI workflows give those frequent changes an automated check.
ddc is easiest to recommend as the front desk for APK investigation. Ask it cheap, narrow questions first, save JSON when a script needs the answer, and open the hardest classes in jadx when type reconstruction matters. Our 152 passing tests back the command layer. The project's own 0.91-million-file comparison explains why it should complement a mature decompiler rather than replace one.