Evidence note: This article rests on two kinds of material, and the difference matters throughout. The first is self-description: what each project states about itself in its own repository listing or on its own site. Those statements are quoted as facts about what the project claims, with the claimant named — not as independently verified capability. The second is a derived count, arithmetic performed on those self-descriptions and labelled as derived where it appears. No project discussed here was built, run, or benchmarked for this piece. The repository and site descriptions referenced were the ones on record on 16 September 2026; project descriptions change, and a reader checking later may find different wording.
libGDX in one line
libGDX is a Java game development framework whose stated reach covers Desktop, Android, HTML5 and iOS — four targets from one codebase. The framework is commonly described as a cross-platform development framework, though that particular phrasing is not independently corroborated by the sources available here and should be read as the description in circulation rather than a verified technical summary. For a broader introduction to the framework and the ecosystem around it, see our earlier overview of libGDX as the Java framework behind cross-platform games, emulators and third-party engines.
The four-target list is the interesting part, and it is the part this article tests against reality — not by compiling anything, but by reading what the projects built on libGDX say they actually target.
Two front doors
libGDX presents two entry points, and they are not interchangeable.
The source lives on GitHub, at the libgdx/libgdx repository — the project’s own listing identifies this as the official home of the framework (self-description on the repository itself; not independently confirmed against any third-party registry).
A separate project website is also on record at libgdx.badlogicgames.com. Sources available here do not confirm the current status, freshness, or canonical standing of that site relative to the repository, and no claim is made about which one a newcomer should treat as authoritative. The distinction is worth noticing because the two doors tend to carry different things — code and issue history on one side, narrative documentation on the other — and a developer chasing an API detail and a developer chasing a getting-started guide are rarely helped by the same one. The same split shows up elsewhere in game development tooling; our piece on where the SFML Game Development Book’s source code actually lives covers a case where confusing the two costs real time.
What people actually build on it
Four projects make useful test cases precisely because they are so unalike. libGDX is described as the underlying framework for a set of third-party engines and games that includes agile-gdx, jvic, sopistan and c2d-engine — a grouping recorded in those projects’ own listings rather than assembled by any independent survey.
- An adventure-game interpreter. AGILE is described as an AGI (Adventure Game Interpreter) engine written in Java and JS, using libGDX to target HTML5, Desktop and Android. This description is uncorroborated here; it reflects the project’s stated scope, not a tested one.
- A home-computer emulator. jvic states that it is a VIC 20 emulator written in Java, using libGDX to target HTML5, Desktop and Android (the project’s own repository description).
- A word-search game. sopistan states that it is a word-search game coded in Java using libGDX for Desktop, Android, iOS and HTML5 (the project’s own repository description).
- An engine. c2d-engine states that it is an Android/HTML5/desktop game engine based on libGDX (the project’s own repository description).
An interpreter, an emulator, a small word game and a general-purpose engine is a wide spread of ambition. That is what makes the next step worth doing.
Reading the four target lists side by side
Set the four stated lists against the framework’s four platforms:
| Project | Desktop | Android | HTML5 | iOS | Targets named |
|---|---|---|---|---|---|
| AGILE | yes | yes | yes | — | 3 |
| jvic | yes | yes | yes | — | 3 |
| sopistan | yes | yes | yes | yes | 4 |
| c2d-engine | yes | yes | yes | — | 3 |
Every cell above is transcribed from the project’s own description as quoted in the previous section. Nothing here was determined by building the projects.
The derived tally, and the one target that does not survive
Read down the columns rather than across the rows and a pattern appears that no single project’s page states.
Desktop appears in 4 of 4 stated lists. Android appears in 4 of 4. HTML5 appears in 4 of 4. iOS appears in 1 of 4 — only sopistan names it. Three of the four projects name exactly three targets; one names four. (Derived calculation, performed on the four self-descriptions above on 16 September 2026; sample size n=4, which is far too small to support any general claim about the libGDX ecosystem.)
So the framework’s fourth platform is the one that thins out. Desktop, Android and HTML5 form a stable core across this small sample, while iOS is the target that does not survive the count.
What that does not establish is why. A stated target list is a statement of intent and configuration, not evidence of a working build; a project that omits iOS may lack the toolchain, the hardware, the developer account, the interest, or simply an up-to-date README. Equally, sopistan naming iOS is evidence that it names iOS — not that an iOS artefact exists. The honest reading of the tally is narrow: among these four, the framework’s full platform promise is repeated in full by one project out of four.
What that changes when a project calls itself a libGDX variant
libgdx-alter, maintained by Java-Game-Engine-Merger, describes itself as a variant of the Desktop/Android/HTML5/iOS Java game development framework (the repository’s own description).
Note what it restates: the complete four-platform list, iOS included. That is consistent with what a fork or variant of a framework would be expected to say — it inherits the framework’s stated surface rather than a particular application’s subset. It is a different kind of claim from the four project claims above, and it should be read differently. A framework variant naming four platforms describes what the framework exposes. An application naming three describes what that application was actually configured to produce. Conflating the two is exactly the error this article is about.
Lookalike, not lineage
libfdx describes itself as a modular Java game framework for Web, Mobile and Desktop (the project’s own repository description). The name is one character from libGDX, and the category — a modular Java game framework — is adjacent. Nothing in the record consulted here establishes that libfdx is a libGDX derivative, fork, or variant, and no such relationship should be inferred from the name.
Its target list is also structured differently, which is worth a moment. "Web, Mobile and Desktop" is three items, but "Mobile" is unsplit. Mapping it onto the Android/iOS division used above would require assuming what "Mobile" covers, and that assumption is not supported by the description. libfdx is therefore excluded from the tally rather than counted as three.
The same question asked of the neighbours
The natural follow-up is whether the four-platform promise holds up better outside libGDX’s immediate orbit. The available descriptions suggest the picture is mixed, but the evidence quality varies sharply from one to the next.
SilenceEngine states that it is a cross-platform 2D/3D Java game engine targeting Desktop, HTML5 and Android (the project’s own repository description). That is the same three-target shape seen in three of the four libGDX projects — Desktop, web and Android, no iOS.
OpenFL is described as a high-performance framework for desktop, iOS, Android and HTML5. This description is uncorroborated here, and the performance characterisation in particular is marketing language rather than a measured result; it should not be read as a benchmark claim.
Stencyl is described as a Haxe-based engine that lets users create Flash, HTML5, iOS, Android and desktop games without code. That description is likewise uncorroborated here, and the inclusion of Flash in the list is a strong signal that the description may predate the platform’s deprecation — a reminder that stated target lists age badly and carry no timestamp.
Construct is described as a visual HTML5-based 2D game editor. This is uncorroborated here, and note that it is a different kind of statement altogether: HTML5 is named as the technical basis of the editor, not necessarily as an export target list. It cannot be placed in the same column as the entries above without conflating two different things.
Developer takeaway: read the project’s own target list
The practical conclusion is narrow and useful: a framework’s platform list tells a developer what is possible, not what any given project on it has done. When evaluating a libGDX-based project — as a dependency, as a reference implementation, or as a codebase to fork — the framework’s four platforms are the wrong figure to plan against. The project’s own stated targets are closer, and among the four examined here, three of the four stated three.
Three concrete habits follow:
- Check the project’s stated targets before the framework’s. In this sample, that difference was one platform in three out of four cases.
- Treat iOS as the target to verify first. It is the one that thinned out here, and it is also the one with the heaviest external requirements — toolchain, hardware, signing. (Based on n=4; this is a prompt to check, not a finding about libGDX projects generally.)
- Check the age of the claim. A description listing Flash is a description that has not been revisited recently, and the same staleness can hide in any target list without being so obvious.
A follow-up worth running — proposed, not performed
The tally above counts claims. The question it cannot answer is whether the claims hold, and that question is answerable.
A clean test would be: clone each of the four named projects at a pinned commit, attempt a build for every target each one names, and record which invocations actually produce an artefact — with the toolchain versions, the host OS, the date, and every failure written down rather than discarded. The gap between "targets named" and "targets that produce an artefact" is the real number, and it is not in any of the sources cited here.
That experiment has not been run for this article, and nothing above should be read as if it had. It is recorded here as a proposed follow-up, with the method stated in advance so that the result — including a null result, or a build environment that defeats the attempt entirely — can be reported honestly either way.