Solar2D: a Lua 2D game engine that runs your code before you build it

The problem Solar2D solves: one Lua codebase, many screens

Cross-platform 2D publishing usually turns into per-platform work: separate UI code, separate build steps, separate asset pipelines. Solar2D attacks that by keeping the application in Lua and moving the platform differences into the engine. The README states that a project can be created once and published to Apple iPhone and iPad, Android phones and tablets, Amazon Fire, Mac Desktop, Windows Desktop, Linux, HTML5, and connected TVs including Apple TV, Amazon Fire TV and Android TV. It also claims the API covers over 1000 functions.

The intended user is a developer writing 2D games or mobile applications who does not want to touch C++, Objective-C or Java for the common case. The README calls it "the easiest development tool for 2D games and mobile applications" and says it allows creating apps "up to 10 times faster than other frameworks". That is a marketing number with no methodology attached, so treat it as positioning rather than a measurement. The concrete, checkable part of the pitch is narrower and more useful: Lua throughout, a Simulator that runs the app on the desktop, and a plugin system for the platform features the core does not cover.

How the Simulator, live builds and Solar2D Native fit together

The development loop has two halves. On the desktop, the Simulator runs the app directly on PC or Mac, which the README presents as the way to prototype and test ideas quickly. Changes are saved and the Simulator updates instantly, so the edit-run cycle does not require a device build.

The second half is device testing. The README describes building and deploying the app once, after which code and assets update automatically over the local network. That is the live build path: the packaged binary stays put and the Lua and assets are refreshed from the development machine.

When the core API and the plugin directory do not cover something, Solar2D Native is the escape hatch. According to the README it lets you call any native C, C++, Objective-C or Java library or API, and it also allows packaging your own code as a plugin. That is the architectural boundary worth understanding before you commit: the Lua layer is the product, and everything below it is either a first-party plugin, a community plugin, or your own native binding.

The repository layout reflects this. Platform entry points live under platform, with per-platform README files in its subdirectories; the engine is built with CMake, and the tree carries external, modules, plugins, sdk and simulator-extensions directories. Cloning the whole source tree needs git submodules, which the README handles with a recursive clone.

Installing Solar2D and running a first project

The README is explicit that the recommended route is the binary distribution, not a source build: download the latest build from the Releases page. That is the whole install instruction the README gives, and it does not document a package-manager install for any platform.

Source builds are a separate path, aimed at contributors. Because the repository uses git submodules, a plain clone leaves the tree incomplete; the README gives this command:

# clone the whole source code tree, including submodules
git clone --recursive https://github.com/coronalabs/corona.git

Contributors also have to sign a Contributor License Agreement before their code can be part of the ecosystem. CONTRIBUTING.md carries the details, and the entry points for each platform are in the platform directory, whose subdirectories have their own README files.

For day-to-day work you do not need any of that. Install the binary from the releases page, open the Simulator, and point it at a project folder containing a main.lua. The README does not print a hello-world listing, so the first real step is to open the API documentation and getting-started guides on docs.coronalabs.com and follow the project structure described there. If you prefer an editor with Solar2D support, the README points at extensions for Sublime Text, Atom (autocomplete-corona), Visual Studio Code (Solar2d-companion) and ZeroBrane Studio.

Where Solar2D stops being the right tool

The engine is 2D by name and by scope. The README describes it as a 2D game engine and never claims 3D rendering, so a project that needs 3D scenes is outside what the documentation promises. There is no visual scene editor described either: the workflow is code in Lua plus the Simulator, with editor support coming from third-party extensions rather than a first-party IDE.

The plugin situation is the second constraint. The README lists a Solar2D free directory plus third-party stores, Solar2D Marketplace and Solar2D Plugins. That spread means plugin availability and quality are not uniform, and a plugin you depend on may live outside the project's own distribution. Verify the plugin exists and is maintained before you design around it.

The third constraint is governance. The README states that Solar2D is maintained by the community, with shchvova as principal developer. There is no commercial vendor behind the release process, so support comes from Discord and the forums. For a studio that needs a contract and an escalation path, that is a real difference from a commercially backed engine.

Finally, the README's own claims are unverifiable as written. "Up to 10 times faster" and "just like magic" are not measurements, and nothing in the README explains how either was arrived at.

Solar2D versus a component-and-editor engine such as Godot

The clearest contrast is with Godot, which is also free and open source but organises work around scenes, nodes and an editor rather than around a scripting API alone. In Godot you assemble a scene tree in the editor and attach scripts; the editor is the primary interface. In Solar2D, per the README, the primary interface is Lua code plus the Simulator, with the instant-update loop as the main productivity argument.

That difference decides which one fits. If your team thinks in terms of an editor, prefabs and a scene graph, Solar2D will feel like writing an application rather than authoring a game. If your team thinks in terms of code, a fast desktop run loop, and one Lua file tree that also ships to TV and HTML5, Solar2D's shape is the closer match.

The language split matters too. Solar2D is Lua-only for application code, and the README leans on Lua's track record in games, listing Roblox, The Elder Scrolls Online, Don't Starve, World of Warcraft, Angry Birds and Civilization. Godot uses GDScript with C# and C++ options. If your team already writes Lua, that is a hiring and onboarding argument in Solar2D's favour; if not, it is a new language to learn either way.

Releases, licence and what an upgrade actually costs you

Solar2D ships versioned releases on GitHub. The recent ones are 3731 (Solar2D 2026.3731) on 2026-07-17, 3730 (Solar2D 2026.3730) on 2026-05-07, and 3729 (Solar2D 2026.3729) on 2026-03-09. The last push to the repository was on 2026-09-23. The README does not document a rollback procedure, a long-term-support branch, or a deprecation policy, so an upgrade plan has to come from your own testing rather than from a published compatibility guarantee.

On licensing, the README states Solar2D is licensed under MIT, and that this gives you full rights to customise the engine and distribute built apps on your own terms. It also warns that Solar2D incorporates many libraries, both third-party and made by Solar2D developers, and that those may carry different licences; the third-party list is at sdk/dmg/Corona3rdPartyLicenses.txt. If you ship a commercial title, that file is the one to read before you assume a uniform MIT position across everything linked into your binary. This is a description of what the repository says, not legal advice.

Upgrade cost in practice is dominated by two things the README leaves open: whether a plugin you rely on keeps pace with engine releases, and whether your Lua code touches APIs that changed between versions. Neither is answered by the release notes as summarised here.

Editorial conclusion

Solar2D suits developers who want a 2D game or app in Lua and value the instant-update Simulator over a component-based editor. It is the wrong pick if you need 3D, a visual scene editor, or a vendor with a commercial support contract; the README names shchvova as principal developer and describes the project as community maintained. Before committing, install the binary from the releases page, open the Simulator, and confirm that the plugins your design depends on are listed in the Solar2D free directory or on the third-party plugin stores.

Frequently asked questions

Official sources

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