spine-runtimes: the twenty engines that read Spine animation data, and the licence attached to them

One repository, twenty runtime directories

The repository exists because Spine animation data is not portable on its own. Exporting a skeleton from the Spine editor produces a data file, and something has to read it, apply the animations, and drive the result from your engine of choice. This repository is that something, in as many forms as Esoteric Software supports.

The directory list is the honest measure of the scope. There is `spine-android`, `spine-c`, `spine-cpp`, `spine-csharp`, `spine-flutter`, `spine-glfw`, `spine-godot`, `spine-haxe`, `spine-ios`, `spine-libgdx`, `spine-monogame`, `spine-sdl`, `spine-sfml`, `spine-ts`, `spine-ue`, `spine-unity`, and `spine-xna`, alongside a shared `tests/` directory and a `formatters/` directory.

That last pairing tells you something about how the project is organised. The runtimes are separate implementations, but they are held in one repository with shared tests and shared formatting tooling, which is how you keep twenty parsers of the same data format from drifting apart.

The primary language is C++, which fits the shape of the thing. `spine-c` and `spine-cpp` are the low-level implementations that the higher-level bindings sit on top of, and `spine-ue`, `spine-unity`, and `spine-libgdx` are the engine integrations most people end up using. The last push was on 2026-09-21 and the repository is not archived.

The licensing arrangement that catches teams out

This is the part of the README that deserves to be read twice, because the permissions are granted and the obligation is placed on somebody other than you.

You may evaluate the runtimes and the examples free of charge. You may integrate the runtimes into your software free of charge. But users of your software must have their own Spine licence, and the README asks you to make your users aware of that requirement. It notes this option is often chosen by people making development tools such as an SDK, a game toolkit, or a software library.

Distribution changes the picture. To distribute software containing the runtimes to people who do not have a Spine licence, you need a Spine licence at the time of integration. Once you have one you can distribute as you like, provided others do not modify the runtime or use it to create new software. If they want to do either of those things, they need their own Spine licence.

The licence field in the repository metadata reads NOASSERTION, which is consistent with what the README describes: this is not a standard open source licence, it is a set of specific commercial terms with the legal documents hosted on the vendor's site. The README points at the Spine Runtimes License Agreement and Section 2 of the Spine Editor License Agreement for the official terms. Anyone evaluating this should read those rather than treating the repository as permissively licensed because the code is visible.

Branches and editor versions have to move in lock step

The versioning section is short and carries the most practical warning in the README. The default branch on GitHub is stable and works with data exported from the latest non-beta version of the Spine editor. New development happens on an `X.X-beta` branch, which may be a work in progress.

The metadata records the default branch as `4.3`, so that is the branch matching the current stable line. The repository publishes no GitHub releases, though the README notes that the runtimes are occasionally tagged with the specific Spine editor version they work with.

Then comes the advice, and it is unusually direct: it is highly suggested to freeze the Spine editor version to match the runtime source being used, and to update them in lock step.

That is a real operational constraint rather than a formality. A skeleton exported by one editor version is a data format that the runtime for a different version may not read, and because the failure would surface as missing or broken animations at load time rather than a compile error, the cost of an unlocked pairing is discovered late. Pinning both is the mitigation, and the versioning section of the Spine Runtimes Guide is where the detail lives.

For teams already on Spine this is mostly a process rule. For teams evaluating it, it belongs in the decision, because it constrains how your art pipeline upgrades.

The examples directory doubles as animation documentation

Twenty-five example directories are listed, and they are not all interchangeable demos. The numbered ones teach animation principles one at a time: weight and mass, the twelve principles, timing and spacing, the wave principle, squash and stretch, arcs, anticipation, and follow through. Those names are the classic animation fundamentals, and shipping them as runnable examples is a more useful reference than a prose chapter would be.

The rest are built products. There is alien, celestial-circus, chibi-stickers, cloud-pot, coin, diamond, dragon, goblins, hero, mix-and-match, owl, powerup, raptor, snowglobe, and food-app, which is a mobile-style example rather than a game. There is also an export directory, which is the one to look at first when you want to know how the data leaves the editor, and `readme.txt` at the examples root.

Two of these are worth calling out for what they imply. mix-and-match is the pattern for composing characters from shared parts at runtime, and food-app shows the runtimes inside a product UI rather than a game scene, which is a reminder that the same runtime serves both.

There is also a `todos/` directory and a `CHANGELOG.md` in the tree, and the README says important changes to the runtimes can be reviewed in the changelog file. That is the file to watch when you upgrade an editor version, more than the directory listing.

Build tooling and bindings across the tree

The repository carries a small amount of build infrastructure that reveals how the pieces fit. There is `SpineConfig.cmake.in` and a `flags.cmake`, so the C and C++ runtimes build through CMake. There is `generate-bindings.sh`, which is how higher-level language bindings get produced rather than written by hand.

A Swift package manifest sits at the root as `Package.swift`, covering the Apple platform targets alongside `spine-ios`. `spine-glfw`, `spine-sdl`, and `spine-sfml` are the windowing-library integrations, which puts them in the same category as the `examples/` apps rather than with the engine runtimes.

Two files in the tree are unusual enough to notice. There is a `.pi/` directory, and there is a file named corrections-of-fable5.1.md. The latter appears to be a correction note tied to a specific version of another asset or specification, which is the sort of thing a project accumulates when it is large enough to need to correct the record about something external.

There is also a `.git-blame-ignore-revs` file, which is the standard mechanism for hiding large mechanical reformatting commits from blame. Combined with the `formatters/` directory, it says the project enforces consistent formatting across twenty runtime implementations and does not want a formatting-only diff to appear as the reason a line changed.

What the README does not cover, and where to go instead

The documentation section is three links. The Spine Runtimes Guide is named as the place for detailed information about using the runtimes. The Spine documentation page carries further information about tools and data formats. And for anything runtime-specific, the README tells you to refer to the README.md file in each runtime directory.

That last instruction is the practical one. There is no single reference manual in this repository because there are twenty runtimes with twenty APIs, and a document trying to cover all of them would be worse than twenty documents that are accurate about one thing.

The issue trackers are split in two, which is also worth knowing: bugs, enhancements, and tasks are reviewed in the spine-runtimes tracker and the spine-editor tracker, and a roadmap page gives a more convenient view of the same information. A bug about how data is exported belongs in the editor tracker rather than the runtimes one, and knowing that in advance saves a round trip.

Contributions require a signed contributor licence agreement, with a copy sent to an email address given in the README, and the project asks that contributions be based on the current beta branch where possible, following the style and formatting found in the runtime being changed. The default branch is `4.3`, the last push was on 2026-09-21, and the practical starting point for anyone adopting these runtimes is the guide's versioning page rather than this README.

Editorial conclusion

This repository is not a library you drop into a game and forget, because the runtimes are coupled to the editor version that produced your data and to a commercial licence that your users, not you, have to hold. The right reader is a studio already committed to Spine who needs to confirm that a target platform has a runtime and that the branch matching their editor version exists. The default branch is the stable one and works with data from the latest non-beta editor, which is the fact to check before you upgrade anything. Read the Spine Runtimes License Agreement and the versioning section of the Runtimes Guide first, because those two documents settle the questions this README only points at.

Frequently asked questions

Official sources

1. EsotericSoftware/spine-runtimes on GitHub
2. Issues
3. Project website
4. README