Understanding the Corona SDK / Solar2D Origin Story
If you're just getting into mobile app development and you stumble across references to Corona, you're probably wondering where it actually comes from and whether it's still worth your time. Corona SDK was originally built by a small team at Royal Skies LLC, released back in 2009. It was a Lua-based cross-platform framework that let you build native iOS and Android apps and games from a single codebase. The idea was simple enough — write your game once in Lua, compile it for whichever platforms you needed, and not deal with Objective-C or Java scaffolding. I used Corona heavily between 2012 and 2016. I shipped about seven indie games on it, some of which did moderately well on the App Store and Google Play. What people don't always realize is that Corona was never just a game engine. You could build utility apps, dashboards, anything really — but the community and the documentation were overwhelmingly game-focused, which shaped how the platform evolved.
Where Is Corona From and Why Does It Matter Today?
The short answer to "Where Is Corona From" is: it originated in Silicon Valley, specifically tied to Royal Skies LLC, and was later relaunched as an open-source project called Solar2D after Corona Labs (the company behind it) closed its doors around 2019. The core framework, the physics engine (Box2D), the display layer, and the build pipeline all moved into the open. That's why you'll see two names floating around — Corona and Solar2D — and they're essentially the same thing at the engine level, just different branding and community structure. One thing that trips people up is assuming Corona is dead. It isn't dead, but it's not actively sold or supported by a commercial entity anymore. The Solar2D community maintains the code, releases updates, and handles forums. If you're starting a greenfield project today, you'd download Solar2D, not Corona. The API is backwards-compatible enough that legacy Corona projects still compile, which is useful if you're maintaining old code. Here's a practical tip most tutorials skip: the build process for Corona/Solar2D requires you to register with Apple and Google developer accounts separately, and the provisioning profiles are where things get messy. I spent roughly three days in 2014 wrestling with an expired iOS distribution certificate right before a launch. The workaround was fairly straightforward — I had to regenerate the provisioning profile through the Apple Developer Portal, make sure the bundle identifier in corona.config matched exactly what was registered in that profile, and then set the correct certificate in the build settings. If the bundle ID doesn't match character-for-character, the build fails silently and gives you an error that doesn't point to the real problem. Keep a text file with your bundle IDs and certificate names handy. It saves hours.
Another counter-intuitive thing about Corona: the physics simulation is actually one of its strongest features, but it runs on the main thread by default unless you explicitly offload it. Box2D inside Corona is single-threaded, which means if you have more than about 50–60 active physics bodies interacting, your framerate drops noticeably on older devices. I ran into this on a project with a lot of particle physics. The fix was to split my scene into separate physics worlds and only activate them when needed, rather than having everything live in one big loop. The Lua runtime is also not the full Lua 5.4 spec. It's a modified version, sometimes referred to as CoronaLua, and it's closer to Lua 5.2 in behavior. Several standard library functions behave slightly differently, and some metatables don't work the way you'd expect from pure Lua. If you've ever written a Lua library outside of Corona and then pasted it in, something broke — that's usually why.
Get the Full Details

Current State and Alternatives
Solar2D still has an active community. The download is free at solar2d.org, and there are official docs, a forum, and a reasonable amount of third-party content. But the ecosystem is a fraction of what it was at peak. Marketplace plugins, tutorials, and sample code from the Corona era mostly sit on archived sites or Wayback Machine links. If you're evaluating Corona/Solar2D today against other options, here's where it stands honestly. It's solid for 2D games and straightforward UI apps. It's not ideal for anything that needs heavy 3D rendering, complex networking, or native module integration beyond what the community has already built. For those cases, you'd be better off looking at Unity, Godot, or even a React Native / Flutter approach depending on whether you're building a game or a utility app. The biggest bottleneck with Solar2D right now is community size. When you hit a bug, the odds of finding a solution on Stack Overflow or the forums are lower than they were in 2015. I've personally had to dig into the C++ source code for Solar2D itself to figure out edge-case crashes — something no one should have to do for a framework they're using in production.
That said, for simple 2D projects where you want rapid iteration and don't need a massive team, it still works fine. The build times are fast, the Lua syntax is quick to learn, and the debugging experience is adequate if you're comfortable with print-based debugging and the Corona Simulator's event viewer.