Lime: the cross-platform layer under Haxe and OpenFL

One layer under every Haxe target

Lime describes itself as a flexible, lightweight layer for Haxe cross-platform developers, and the list of what it unifies is the whole pitch: windowing, input, events, audio, render contexts, network access and assets.

The supported targets are native, Flash and HTML5. That combination is a snapshot of the Haxe ecosystem's reach, and it explains who the audience is. A Haxe developer in 2026 might be shipping a desktop game with HashLink or Neko, a browser build with the same source, and a mobile build, and the point of Lime is that the window handling, the input events and the asset loading are the same code in all of them.

The repository makes the same point structurally. The top level contains src and tools directories, a templates directory for generated projects, externs, assets, a project directory with the native build configuration, an ndll directory for the native libraries, tests, and a docs directory. There is also a Dockerfile, a CHANGELOG, a release checklist, a maintainers file and a notice file, which is the shape of a project with an established process rather than a weekend experiment.

Lime is the foundation that OpenFL is built on, so the practical audience is developers who either want to use OpenFL directly or want the lower level platform access without the higher level framework.

A context, not a renderer

The README is explicit on the most important design decision in the project: Lime does not include a renderer, but exposes the current context.

The contexts listed are Cairo, Canvas, DOM, Flash, GL and Vulkan. Read that list carefully, because it defines the scope of the library. On an HTML5 target the context is the browser Canvas or the DOM; on Flash it is the Flash context; on a native target it is Cairo, OpenGL or Vulkan.

Drawing is your problem. Lime gives you a surface to draw into and a window to draw it in, and a game framework such as OpenFL sits on top and does the sprite batching, the scene graph and the game loop. If you are writing your own renderer, this is the layer you want, because it hands you the native window and swapchain integration without deciding what to draw with.

The GL context follows the WebGL standard, and the README notes that it is implemented for both OpenGL and OpenGL ES as needed, which is what allows the same code path to work on a desktop GPU and on a phone.

Audio works the same way. Lime provides a unified audio API across targets, and on native targets it also gives access to OpenAL for advanced audio work, so a project that needs spatial audio or low latency decoding can drop below the abstraction without leaving the platform layer.

Vulkan support and the Apple caveat

Vulkan is the newest capability in Lime and the one with the most interesting caveats, so it deserves reading closely.

The README states that native Vulkan support exposes an explicit Vulkan API layer for renderer backends, including native window and swapchain integration and resource and command primitives. That is a real commitment: it means Lime owns the surface creation and the swapchain, not just a wrapper around an existing library.

Requesting a Vulkan window is done through the standard RenderContextType.VULKAN context selection, or by setting a window renderer attribute in the project XML, for example a window element with renderer set to vulkan.

The platform coverage is uneven, and the README is clear about where the gap is. Native Vulkan support is included in the standard Windows and Linux C++ Lime builds, together with the matching Haxe API define. Apple targets still require an explicit Vulkan-enabled build and MoltenVK packaging. In practice that means a macOS or iOS build with Vulkan is not a default configuration but something you assemble yourself.

The repository also names the test that keeps the feature honest: the in-repo tests/vulkan-smoke project is described as the current Vulkan CI smoke application, which is a minimal check that the context can be created and used in continuous integration.

Installing Lime and running its setup

The installation path assumes you already have Haxe, and the README says to install the latest version of Haxe first. Then Lime itself comes from Haxelib and needs a setup step.

    haxelib install lime
    haxelib run lime setup

The setup command is the part that surprises people. Lime ships native libraries for its targets, and the setup run is what places them where the Haxe compiler expects them to find them. A Lime install that skips setup tends to fail at the point where the native library is loaded, which is an unhelpful error to debug if you do not know the step exists.

That is the whole installation for users. Everything else in the README concerns working on Lime itself.

For developers, there are nightly builds. The README says that when there are changes, Lime is built nightly, with the artefacts available from the workflow runs on the develop branch, and that a development build is installed with the haxelib local command pointing at the downloaded archive.

The project also documents a home for questions: a Discourse forum on community.openfl.org with a Lime category, and a Discord server, both linked from the README.

Building Lime from source

The source build is a five step procedure in the README, and step three is the one that catches people out.

First you install the library as a git checkout with haxelib git, pointing at the Lime repository. Then you install the required dependencies, which are the format and hxp libraries plus native-desktop pinned to version 1.0.0.

        haxelib install format
        haxelib install hxp
        haxelib install native-desktop 1.0.0

Third, you copy the ndll directory from the latest Haxelib release, or you follow the instructions in project/README.md to build the native binaries yourself. The README presents this as a choice, but in practice it is the step that decides how long your first build takes.

Fourth, after any change to the tools directory or to the tools inside src/lime/tools, you rebuild with lime rebuild tools. The rebuild is needed because the tooling that drives the build is itself generated, and a change to it does not take effect until it is regenerated.

Fifth, to move away from a source build and back to a released version, you set the version explicitly with haxelib set lime and the version number.

The last step is the one to remember if you are working on Lime and then need to get back to a clean state, because a haxelib dev checkout otherwise shadows the released library indefinitely.

Targets, samples and the same-host rule

The target list in the README is the practical scope of the framework.

    lime test windows
    lime test mac
    lime test linux
    lime test android
    lime test ios
    lime test html5
    lime test flash
    lime test air
    lime test neko
    lime test hl

Neko and hl are the two Haxe virtual machine targets, and their presence is a reminder that Lime is not only about native binaries. Flash and AIR are also still listed, which tells you about the project's history and about how conservative the maintainers are about removing targets.

One constraint is stated in a single line and is easy to miss: desktop builds are currently designed to be built on the same host OS. If you are on Linux and want a Windows build, Lime is not the tool for that, and a CI machine per target is the arrangement this implies.

The sample workflow is short. You create a project with lime create, which also lists the other project templates available, then move into it and run lime test neko to try it without setting up a native target.

    lime create HelloWorld
    cd HelloWorld
    lime test neko

The test target doubles as a quick check that your Haxe installation and the native libraries are wired up correctly, before you commit to a full platform build.

The container image and the release cadence

The Dockerfile in the repository shows what a Lime build needs on a Linux machine, and it doubles as a list of the native dependencies of the desktop target.

The image starts from an Ubuntu base and installs the OpenGL and GLU development packages, a C and C++ toolchain with multilib support, the ALSA development headers for audio, and the X11 development packages for windowing, along with git and vim. It then copies the Haxe, Neko and haxelib installations out of a Haxe image, runs haxelib setup, installs hxcpp, format, munit and hxp, copies the source, and finally runs lime rebuild linux and lime rebuild tools. The container ends with lime as its command, and a comment notes that the Android SDK and the Emscripten SDK are not part of it.

That image is old in one respect. The Haxe version argument defaults to 3.4.3 and the Ubuntu base to 16.04, both of which predate the versions the README asks users to install, so treat it as a reference for the dependency list rather than as a current environment.

On releases, the tags are Lime 8.3.2 from 2026-05-13, Lime 8.3.1 from 2026-02-17 and Lime 8.3.0 from 2025-11-11, with the default branch being develop and the last push dated 2026-10-20. The pattern of a patch release every few months, with nightly builds in between, matches a project that has to react to changes in the native libraries and in the Haxe toolchain.

Lime is MIT licensed, with the licence file in the repository root. That is permissive enough for commercial use and for embedding in a larger framework, with attribution and no warranty attached.

Editorial conclusion

Lime is the right foundation for a Haxe team that has to ship the same codebase to a desktop native build, an HTML5 build and a mobile target, because the platform differences are absorbed below the game or app layer rather than inside it. It is the wrong choice for a project that only needs one platform, where Haxe plus a native library is simpler, and it is the wrong choice if you expect a renderer, since Lime exposes a context and leaves drawing to you. Verify first that the target you need is in the supported list, note that desktop builds are designed to be built on the same host operating system, and check the Haxe version your Haxelib release expects before you change anything in the tools directory.

Frequently asked questions

Official sources

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