OpenFL: a Haxe cross-platform layer that keeps Flash-era APIs alive

What OpenFL is, in the project's own framing

The OpenFL project's stated purpose is to be an open-source answer for game and application developers who want a fast, simple way to ship creative work without depending on a specific implementation such as a browser plugin. That last clause is the whole historical context. Flash needed a plugin; AIR needed an installer; both are gone as distribution mechanisms. OpenFL keeps the programming model and changes the targets.

It is written in Haxe, which is the pivot of the design. One codebase compiles to native C++, Neko, Flash bytecode or JavaScript. The README's claim is that transitioning between target types is simple and keeps the strengths of the target environment, which is a more careful phrasing than most cross-platform libraries use. It is not one binary running everywhere; it is one source tree compiled to whatever the platform wants underneath.

The listed platforms are iOS, Android, HTML5, Windows, macOS, Linux, Flash and AIR. Beyond that, the README describes console support as a community effort and lists Switch, Wii U, PlayStation 4, PlayStation 3, PlayStation Vita and Xbox One as running OpenFL, with the note that additional details on console support will be available in the future. There are also non-obvious deployments in TiVo boxes, Raspberry Pi and Node.js.

OpenFL, Lime and hxcpp: three projects, not one

The core components section names three repositories, and understanding the split explains most of the design. OpenFL is the API layer you program against. Lime is the foundation for cross-platform project development, providing backend support and the command-line tooling. hxcpp comes from the Haxe Foundation and is used automatically by the Lime tools to drive C++ compilation and to provide the Haxe standard library for C++.

So when the README says OpenFL depends on Lime, that is not a casual relationship. Lime owns the platform-specific work, and OpenFL sits above it as a relatively portable layer. If you are debugging something that only happens on Android, the answer is frequently in Lime rather than in the OpenFL repository you cloned.

That also tells you where the boundaries are for reading the code. This repository has `src/` for the library, `tests/`, `assets/` including templates under `assets/templates/bin/`, and `lib/` for the Haxe library metadata with `haxelib.json` and `include.xml` at the root. Build configuration lives in `extraParams.hxml`, `checkstyle.json` and `hxformat.json`. Platform compilation is not in this repository at all; it is in Lime and hxcpp.

Getting a development build or building from source

For ordinary use the README sends you to openfl.org/download. For working on OpenFL itself there are two documented paths, and the first one is a trap worth naming.

Nightly builds exist when there are changes, and the README gives a command for installing one:

haxelib local openfl-haxelib.zip

That installs whatever zip you downloaded into your haxelib set, which means you are responsible for which artefact it is. The builds come from the GitHub Actions runs on the `develop` branch, so a nightly is by definition untagged work.

Building from source is the more controlled path:

git clone https://github.com/openfl/openfl
haxelib dev openfl openfl

The second command is the one people miss. `haxelib dev openfl openfl` tells haxelib where your local checkout lives, so the name appears twice: once as the library, once as the directory. Running `haxelib dev openfl` with no path returns you to release builds. The README also warns that you may need a development build of Lime installed alongside it, which follows from the dependency structure described above.

For context on how the pieces are assembled, the repository's own `Dockerfile` is short and instructive. It builds on an `openfl/lime` image, copies the checkout to `/opt/openfl/`, installs the `openfl.sh` wrapper from `assets/templates/bin/`, points haxelib at the copy, and runs `openfl rebuild tools` before defaulting to the `openfl` command.

Where the Flash heritage shows, and where it does not

OpenFL is designed primarily for 2D development, and the README says so directly. That is the honest limit of the project and worth knowing before you evaluate it for anything else.

For 3D there are two routes. You can use the `OpenGLRenderer` API to write WebGL-style code and mix it with the OpenFL display architecture, or you can use the Stage3D API, which OpenFL supports directly. On top of that sit the ported libraries the README lists, including Starling and Away3D for Stage3D, plus DragonBones, Nape and Box2D for physics, Actuate for tweening, and HaxeFlixel and HaxePunk as Haxe-native engines.

The library list is also the best evidence about the project's actual audience. Starling and Away3D are ports of ActionScript libraries, Nape and Box2D are physics, and HaxeFlixel and HaxePunk were written for Haxe. OpenFL also powers Stencyl, which is worth noting because it means a whole commercial tool depends on this layer working.

On native extensions the README sets expectations too. Targeting a native platform produces real C++, so there is Haxe CFFI for calling C++ libraries directly, plus a purpose-built Android API for Java-based extensions. Extensions can also use the standard Lime project format to control dependencies, extra assets and build output. What OpenFL explicitly does not do is emulate the AIR native extension system, which it describes as more difficult to create and less flexible.

Releases, versioning and how Lime moves with it

OpenFL and Lime are released together, which is a detail that matters more than it sounds. The recent tags show the pairing directly: 9.5.2 shipped on 2026-05-13 alongside Lime 8.3.2, 9.5.1 on 2026-02-17 alongside Lime 8.3.1, and 9.5.0 on 2025-11-11 alongside Lime 8.3.0 and SWF 3.4.0.

So OpenFL sits at 9.5.x and Lime at 8.3.x, roughly two releases in 2026 and three across 2025 and 2026, and you update them as a pair. If you are pinning one, pin both, or let Lime float and accept that your OpenFL version was tested against a specific Lime.

The repository has more governance scaffolding than most Haxe projects, which is a reasonable signal about how it is run. There is a `CONTRIBUTOR_AGREEMENT.md` alongside `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, a `MAINTAINERS.md`, a `RELEASE_POLICY.md` and a `release-checklist.md`. The default branch is `develop`, and the nightly builds are produced from that branch. The last push to the repository was on 2026-09-23.

One number is worth a second look: the repository lists a large number of open issues. For a project at version 9.5 with an active release cadence and a Discord plus forum community, that is a backlog rather than a red flag, but it does tell you the maintainers are carrying a lot of surface area across eight platforms.

Editorial conclusion

OpenFL is a pragmatic answer to a specific problem, which is keeping a Flash and AIR shaped codebase compiling to modern targets after the plugin era ended, and it does that job without asking you to abandon the API surface you already wrote against. The three-part structure of OpenFL, Lime and hxcpp is what makes it work, so read the Lime documentation before you commit, since that is where the real platform knowledge sits. Two practical constraints are worth naming now. The Flash target is one of the officially listed platforms even though that runtime is effectively gone, which tells you the project optimises for compatibility rather than pruning. And console support is described as a community effort whose additional details will be available in the future, so if a console is your target, the console work lives outside this repository and you would be depending on someone else's port.

Frequently asked questions

Official sources

1. License: MIT
2. openfl/openfl on GitHub
3. Project website
4. README
5. Releases