Evidence note: This article rests on what each project publishes about itself — repository summaries, project home pages, and one encyclopedia entry — not on builds, benchmarks, or independent testing. Where a statement comes from a project’s own description, that is said plainly: the fact established is that the project describes itself that way. No framework discussed here was compiled, packaged, or run for this article, and no third party has been found that confirms any of the platform lists below actually produce working artifacts. Individual claims carry their own evidence marking where it matters.
Key finding: Across a cluster of Java and Haxe game frameworks and the small projects built on them, the platform list is a self-published field. It is a statement of intent — the targets a project was set up to build for — and it is not, on its own, evidence that any of those targets currently builds. The most interesting pattern in the cluster is the gap between what a framework advertises and what the projects downstream of it advertise.
libGDX and the Four Platforms It Names
libGDX is commonly described as a cross-platform Java development framework, with third-party projects using it to reach HTML5, desktop, and Android (project repository). Evidence level: uncorroborated. This description appears in and around the project’s own materials and in the summaries of projects built on it; no independent verification of the platform set has been found for this article, and the exact composition of the target list — in particular whether iOS belongs alongside the other three in the framework’s current form — should be treated as an open question rather than a settled one.
A related detail sits in the same category. The project’s website is often given as libgdx.badlogicgames.com (listed home page). Evidence level: uncorroborated. Whether that host is still the canonical home, a redirect, or a historical address is not established by the sources available here, and the article makes no claim about which it is.
For a longer treatment of the framework itself, see this site’s earlier piece on libGDX and its platform list.
The Projects Built on It: An Adventure Game Interpreter, a VIC 20 Emulator, a Word-Search Game, an Engine
Four downstream projects make the pattern visible.
AGILE is described as an AGI — Adventure Game Interpreter — engine written in Java and JavaScript, using libGDX and targeting HTML5, desktop, and Android (project repository). Evidence level: uncorroborated. The engine’s relationship to libGDX and its three named targets rest on the project’s summary alone.
jvic describes itself as a VIC 20 emulator written in Java using libGDX, targeting HTML5, desktop, and Android (project repository). The project states this in its own listing; independent confirmation that all three targets build is open.
sopistan describes itself as a word-search game coded in Java with libGDX, for desktop, Android, iOS, and HTML5 (project repository). Four targets, stated by the project itself — the only one of this group to name the full four.
c2d-engine describes itself as an Android, HTML5, and desktop game engine based on libGDX (project repository). Again, the source is the project’s own description, and whether those targets are currently maintained is not something these sources settle.
Counting the Targets: Where the Downstream List Is Shorter Than the Framework’s
The arithmetic is small and worth doing explicitly. If the framework’s advertised set is four platforms — desktop, Android, iOS, HTML5 — then of the four projects above, three name three targets and one names four. AGILE, jvic, and c2d-engine each omit iOS from their self-descriptions; sopistan includes it. This is a derived count, computed by reading the four self-descriptions against the framework’s advertised set; it is arithmetic on published text, not a measurement of anything.
The honest reading of that gap is narrow. A shorter downstream list is not evidence that the framework’s iOS path is broken. Dropping a target is the cheapest decision a small project makes: iOS packaging historically carries a paid developer account, a macOS build host, and a review process, none of which a hobby emulator or a word-search game needs. The count tells you what these maintainers chose to support, not what the framework can do.
A Fork That Advertises the Same Four: libgdx-alter
libgdx-alter is a fork or variant project, described in its own listing as a desktop, Android, HTML5, and iOS Java game development framework (project repository). The fork advertises the full four-platform set — the same reach the upstream framework is said to claim. What distinguishes the fork from its upstream, and whether the fork is actively maintained, is not answered by the sources available here and remains open.
Two Java Frameworks That Are Not libGDX: SilenceEngine and libfdx
Not every Java game framework in this space is downstream of libGDX.
SilenceEngine describes itself as a cross-platform 2D and 3D Java game engine targeting desktop, HTML5, and Android (project repository). Three platforms, named by the project itself — and notably, the same three that the libGDX-derived projects converge on.
libfdx describes itself as a modular Java game framework for web, mobile, and desktop (project repository). The relationship between these two projects and libGDX — whether either shares code, lineage, or only a problem domain — is not established by these sources.
When a Project Names Categories Instead of Platforms
libfdx is the interesting case in the set, for a reason unrelated to its code. Its reach is stated as web, mobile, desktop — categories, not platforms. Every other project here names concrete targets you could go and test: Android, iOS, HTML5.
That difference matters to anyone reading platform lists as a planning input. "Android" is falsifiable; a build either produces an APK or it does not. "Mobile" is not: it is satisfied by Android alone, and it leaves open whether iOS was ever a target. A category label is a weaker promise wearing the same clothes as a strong one. This is an observation about how the claims are worded, not a judgment about the project — libfdx may well cover both, and nothing in these sources says otherwise.
Outside Java: OpenFL’s Four Targets, Stencyl’s Codeless Haxe Engine, Construct’s Single Target
The same pattern appears outside the Java ecosystem.
OpenFL is described as a high-performance framework for desktop, iOS, Android, and HTML5 (project home page). Evidence level: uncorroborated. The word "high-performance" is a vendor characterization with no benchmark attached in these sources, and it should be read as marketing language rather than a measured result.
Stencyl’s engine is described as Haxe-based, letting users create Flash, HTML5, iOS, Android, and desktop games without writing code (engine repository). Evidence level: uncorroborated. The Flash entry in that list is itself a useful signal about the age of the claim — Adobe’s Flash Player reached end of life at the end of 2020, and browser support was removed after that. Whether Stencyl’s current tooling still emits Flash output, or whether the description simply predates the platform’s retirement, is open and is not answered here.
Construct is described as a visual, HTML5-based 2D game editor (encyclopedia entry). Evidence level: uncorroborated. One target, not four — though "HTML5-based" describes the editor’s own technology as much as its output, and the two are easy to conflate when scanning a list.
A Platform List Is a Record of What Was Promised, Not a Capability Check
Taken together, ten projects and one clear conclusion: the platform list is metadata, written once by the person who set the project up, and rarely revisited. Stencyl’s Flash entry is the cleanest demonstration — a target that the wider world retired years ago can sit in a description indefinitely, because nothing in a repository summary expires on its own.
Nothing in this makes the lists dishonest. They record what a project was built to do at the moment someone wrote the sentence. The failure mode is on the reading side: treating a comma-separated list of platforms as a compatibility matrix, when it is closer to a mission statement. The same caution applies to platform claims generally — this site’s look at where Xbox Cloud Gaming actually runs found a comparable gap between an official platform list and the ecosystem that had grown around it.
What to Ask of a Framework’s Platform Claim Before You Commit to It
Four questions turn a platform list back into usable information:
- Is there a build artifact for the target you need? A release with a packaged APK, an IPA, or a deployed HTML5 demo is evidence; a line in a description is not.
- When did the target last change? Commit activity touching the platform-specific backend tells you more than the summary line at the top of the page.
- Are the targets named as platforms or as categories? "Mobile" and "web" are satisfied by one platform each; "iOS" and "Android" are not interchangeable with them.
- Does the list contain a retired platform? Flash in a current description dates the description, and suggests the rest of the list may be equally old.
None of these require running the framework. They require reading a repository the way one reads a résumé: as a claim by an interested party, checked against artifacts.
A follow-up worth running, and not attempted here: take the four libGDX-derived projects above and attempt a clean build of each named target on a current toolchain, recording which targets succeed, which fail, and with what errors. That would convert this article’s reading of self-descriptions into a measurement. It has not been done, and until it is, every platform list on this page remains what its author typed — nothing more, and nothing less.