Evidence note: This article rests almost entirely on primary self-descriptions — the words each project publishes about itself in its own repository or website — plus one encyclopedia entry. Self-descriptions are evidence that a claim was made, by whom and where; they are not independent confirmation that the claim holds in practice. Nothing here was build-tested. No figures in this article come from measurements taken on this site, and the one test that would settle the central question is named at the end as a proposal, not as something that has been run.
The record libGDX publishes about itself: one codebase, four named targets
The short version of libGDX’s own pitch is a platform list. Its published description presents it as a Java game-development framework whose single codebase is meant to target desktop, Android, HTML5 and iOS — a cross-platform claim rather than a desktop-plus-mobile one (project repository; claim level: the framework’s own self-description, not independently corroborated here).
That sentence is doing a lot of work for a reader who has to choose a stack this week. Four platforms in one line reads as a promise about scope: write the game once, ship it four ways. Whether the fourth name on that list carries the same weight as the first three is exactly the question this article is about, and the public record — read carefully — turns out to answer it only partially.
Where that record lives: a repository, a website, and an encyclopedia entry
Three places carry the description, and they are not equivalent kinds of evidence.
- The source repository. The code is published on GitHub under the libgdx organization’s main repository (libgdx/libgdx) — stated by the project itself, which is the appropriate authority for where its own code lives.
- A project website. Available records point to a project site at libgdx.badlogicgames.com (project site); this is first-party marketing and documentation, and its historical status and current availability are not confirmed here (claim level: uncorroborated).
- An encyclopedia entry. A Wikipedia article describes libGDX as a game-development Java framework (entry). This is third-party in form but not an independent technical audit, and the specific wording is not corroborated here (claim level: uncorroborated).
The useful distinction for a reader is that the repository and the website are the project describing itself, while an encyclopedia entry is someone else summarising — usually from the same self-description. Three sources that all trace back to one author are closer to one source than to three.
Why a platform list is an adoption decision, not a feature list
For a team of one to three people with no budget for a parallel port, the platform list is not a feature comparison row. It is the thing that decides whether the project can reach its intended audience at all.
The asymmetry matters. Desktop, Android and HTML5 are all platforms a small team can usually build and test from the machine it already owns. iOS is the one target that typically imports an entire separate pipeline: Apple developer enrolment, a macOS build host, code signing, provisioning, and a review process that has to be budgeted in days, not minutes. So the fourth name on the list is also the most expensive one to discover is harder than advertised — and the one whose failure arrives latest, after the game is already written against the framework.
That is why "four platforms" deserves to be read as four separate claims with four separate levels of support, rather than one claim with a number attached. The rest of this article is an attempt to find out what support the public record actually offers for each.
Counting the targets four downstream projects name for themselves
One way to probe a framework’s platform list without building anything is to read what projects built on it claim for themselves. A downstream project has no incentive to advertise a target it has not shipped, and its description is written by someone who has actually run the toolchain.
Four libGDX-based projects are open to read. Their self-stated targets:
| Project | What it is | Platforms it names |
|---|---|---|
| AGILE (agile-gdx) | An Adventure Game Interpreter engine in Java and JavaScript, letting Sierra AGI games run on the web | HTML5, desktop, Android |
| jvic | A VIC 20 emulator written in Java | HTML5, desktop, Android |
| c2d-engine | A game engine built on top of libGDX | Android, HTML5, desktop |
| sopistan | A word-search game coded in Java | Desktop, Android, iOS, HTML5 |
Each row is that project’s own description of itself, in its own repository: AGILE, jvic, c2d-engine, sopistan. Claim level for the whole table: self-descriptions, not independently corroborated, and not build-verified here. The c2d-engine characterisation in particular — an Android/HTML5/desktop engine layered on libGDX — is uncorroborated beyond that repository’s own framing.
A broader reading sometimes offered of this cluster — that libGDX serves as a foundation for third-party engines, emulators and games, and therefore has a real downstream ecosystem — is plausible on the face of these four projects but remains an open question at this sample size. Four repositories are an illustration, not an ecosystem census. (This site has previously walked the same four projects as a set; see the earlier piece on libGDX as a Java framework for cross-platform games.)
Three of the four name desktop, Android and HTML5
The pattern in that table is the finding, and it is a modest one. Three of the four downstream projects — an Adventure Game Interpreter engine, a 1980s home-computer emulator, and an engine layered on libGDX — name exactly desktop, Android and HTML5. None of the three names iOS.
What that supports is a reasonable confidence in the first three targets: three independently authored projects, doing three unrelated kinds of work, all claim the same trio. That is the closest thing to corroboration this record contains, and it is still corroboration of a claim, not of a working build.
What it does not support is any conclusion about iOS. An unnamed platform is an unverified platform, not a broken one. A project that does not mention iOS may have tried and failed, may have had no reason to ship there, may lack a Mac, or may simply have written a short description. The record does not distinguish these, and reading silence as evidence of failure would be an error in the opposite direction from reading the framework’s list as a guarantee.
The only downstream project that names iOS is a word-search game
Among the four, one names the full set. According to its own repository description, sopistan is a word-search game written in Java that uses libGDX for desktop, Android, iOS and HTML5 (repository; claim level: self-description, not independently corroborated and not build-verified here).
This is the single most load-bearing claim in the article, so it is worth being precise about what it is worth. It is one data point. It is a project’s own description rather than a verified build artefact. And the project is a word-search game — a genre that is unlikely to stress a cross-platform framework’s hardest edges, such as heavy 3D rendering, native plugin bridges, or platform-specific input and audio paths.
So the honest summary is: the public record contains one downstream self-report that the iOS target was used, from a comparatively simple game. That is meaningfully better than zero reports, and considerably weaker than the three-project agreement behind desktop, Android and HTML5.
A second repository carrying the same description
There is one more wrinkle, and it changes how a platform sentence should be read in general. A separate repository, libgdx-alter, maintained by an organization called Java-Game-Engine-Merger, is published as a derivative or fork-style project and is described with the same Desktop/Android/HTML5/iOS Java game-development framework scope as libGDX itself (repository; claim level: the fork’s own published description, not independently corroborated, and the extent of divergence from upstream is not established here).
A fork can inherit a description for free. Copying a repository copies the sentence about four platforms; it does not copy the testing, the maintenance, or the release process that made the sentence true upstream — nor does it confirm the fork has diverged in ways that would make it false. The point is not that libgdx-alter overstates anything. It is that a reader looking at that description cannot tell, from the description alone, whether it was earned by this project or inherited from its parent. This site has looked at near-identical published one-liners before, in a case where only the contents of two repositories told them apart.
Reading a self-authored, narrower claim: SilenceEngine’s three targets
Once the inheritance problem is visible, a narrower claim starts to look like a stronger one.
SilenceEngine is described as a separate cross-platform 2D and 3D Java game engine targeting desktop, HTML5 and Android — not a libGDX-based project but an alternative to it, and with no iOS target named (repository; claim level: uncorroborated, and the absence of an iOS mention is an absence in a description, not a tested limitation).
A three-platform list from an independent engine is a sentence someone had to write deliberately about their own project. It is not a copy. It names less, and in doing so it tells a reader more about where the author believed the engine actually worked. For the intended reader here — who needs mobile and desktop and browser — that trio may well be sufficient, and the narrower claim is the easier one to evaluate.
Four checks to run on a Java framework’s platform list before you commit
These are reading criteria, derived from the pattern above rather than from any test performed here.
- Separate the framework’s self-stated reach from a downstream project’s self-stated reach. The framework’s list is an intention statement by the maintainers. A shipped downstream project’s list is a report from someone who ran the toolchain. Weight the second more heavily, and count how many such reports exist per platform.
- Check whether the description was authored or inherited. If a repository is a fork, assume its platform sentence came with the copy until something else — recent commits touching platform backends, a platform-specific release artefact, platform-specific CI configuration — shows otherwise.
- Treat an unnamed platform as unverified, not broken. Silence in a short description is weak evidence. Convert it into a question to ask in the project’s issue tracker or discussions, not a conclusion.
- Count the expensive target separately. For a small team, the iOS path carries costs the other three do not: a macOS build host, developer-program enrolment, signing and review. Ask for evidence specific to that target — a store listing, an iOS build in CI, a release note — rather than accepting its presence in a four-item list.
Applied to the record here, those checks produce an uneven but usable picture: desktop, Android and HTML5 are backed by three independently authored downstream claims; iOS is backed by one, from a simple game; and at least one repository carrying the identical four-platform sentence is a fork whose own exercise of those targets is not established.
What this public record cannot tell you, and the build test that would settle it
Several things remain genuinely open, and should not be asserted either way.
- Whether libGDX’s single-codebase, four-platform claim holds in current practice. Nothing here was built or run.
- The present state of the project website, and the exact wording of its encyclopedia entry.
- Whether libgdx-alter maintains working parity with upstream on any of the four targets, or has diverged.
- Whether the three projects that omit iOS omit it by choice, by constraint, or by brevity.
- How far four repositories generalise to the wider set of projects built on this framework.
Proposed follow-up (not performed). The test that would convert the weakest part of this record into something firmer is narrow and cheap to specify: take the framework’s own starter project generator, produce one minimal project, and attempt a build for each of the four named targets on a single machine configuration — recording the framework version, the toolchain versions, the host OS, the date, every failure, and the point at which a macOS host becomes mandatory. The same procedure, run against libgdx-alter and against SilenceEngine, would show which platform sentences survive contact with a build. Until that run exists and its raw output is published, the four-platform promise in this article’s title remains a well-attested claim, corroborated unevenly across its four parts — which is a different thing from a verified capability, and worth knowing before a small team writes a year of game code against it.