Crash Reporting for Solar2D Games

Solar2D is a Lua-based engine focused on building 2D games for mobile, primarily iOS and Android. A Solar2D game crashes through Lua runtime errors in your game logic and through native-level failures in the engine and platform layers, and because it targets mobile, it faces the device fragmentation and memory constraints that all mobile games do. Setting up crash reporting for a Solar2D game means capturing both the Lua errors and the native crashes, with the device and memory context that mobile failures demand, so you can keep a Lua game stable across the diverse phones players run.

Solar2D is Lua on mobile

Solar2D lets you build mobile games in Lua, with the engine handling the native layer beneath your Lua scripts. This means a Solar2D game has two crash sources: Lua runtime errors in the game logic you write, and native-level failures in the engine, plugins, or platform layer. Capturing both is necessary, because a Lua error and a native crash are different kinds of failures that need different handling.

Because Solar2D targets mobile, primarily iOS and Android, it inherits all the realities of mobile development: device fragmentation across many phone models, memory ceilings that kill apps, and OS-specific behavior. A Solar2D crash report needs the mobile device context to be diagnosable, since crashes cluster by device and a memory kill looks different from a code crash. The combination of Lua and native crash sources on a fragmented mobile platform shapes how you capture Solar2D crashes.

Capture Lua runtime errors

Your game logic in Solar2D is Lua, so Lua runtime errors, a nil access, a wrong type, an index error, are a primary crash source. Capture these through Solar2D error handling, which lets you intercept runtime errors with their message and traceback rather than letting them disrupt the game uncaught. Lua tracebacks point at your source, making these errors readable and actionable.

Capture the Lua error message, the traceback, and the context, the current scene or game state, so you can localize the error to a part of your game logic. This script-level capture handles the bulk of the bugs in the code you actually wrote, and because Lua errors are readable, these reports are immediately useful, pointing directly at the line in your Lua that failed across both the iOS and Android builds.

Capture native crashes

Beneath your Lua is the Solar2D native runtime, and crashes can occur there, in the engine, in a native plugin, or in the platform layer, that do not surface as clean Lua errors. These native crashes, common on mobile where memory pressure and device-specific issues abound, need to be captured at the native level with whatever crash information the platform provides.

On iOS and Android, native crashes arrive as platform-level crash signals or reports, and capturing them, typically reading the crash information on the next launch after a crash took the app down, ensures a native runtime or plugin failure does not vanish silently. This complements the Lua-level capture: the Lua handling catches your script bugs, and the native capture catches the lower-level failures, giving complete crash visibility for a Solar2D game on both mobile platforms.

Capture the mobile device context

Because Solar2D games run on a fragmented range of iOS and Android devices, capture the device model, OS version, and available memory with every crash, since crashes cluster by device and many mobile crashes are really out-of-memory kills. A crash that concentrates on one device family or low-memory phones is telling you the cause, which is invisible without the device context.

Memory deserves particular attention on mobile, where the OS kills apps that exceed the budget without a clean crash log, so recording available memory at crash time helps distinguish a code crash from a memory kill, which need different fixes, one in your logic and one in your asset and memory budget. The device and memory context is what makes Solar2D crashes diagnosable across the diverse, constrained mobile hardware players use, just as it is for any mobile game.

Setting it up with Bugnet

Bugnet captures Solar2D crashes at both layers, hooking the Lua error handling for script errors and capturing native crashes on iOS and Android, with the device model, OS, and memory context attached automatically for the mobile target. Reports flow into one dashboard tagged by platform and device, so you see your whole mobile game stability in one place.

Add custom fields for your game state, like the current scene, and group identical crashes into occurrence counts. Because Solar2D games face mobile fragmentation, the ability to filter crashes by device and memory tier is especially valuable, instantly telling you whether a crash is a universal Lua bug, a device-specific native issue, or a memory kill on constrained phones, which determines how you fix it across the range of devices your Solar2D game runs on.

Test on real devices across tiers

Mobile fragmentation means testing on real devices across performance tiers, not just a flagship, is the most valuable proactive step for a Solar2D game, since a game that runs on the best phone may crash or run out of memory on a budget one. Test on at least one lower-end Android device and one iOS device, because the memory and device-specific issues that dominate mobile crashes show up there.

Pair that device testing with your captured crash data for the long tail of devices you cannot own. You cannot test every phone, so your players collectively exercise the device matrix, and the captured crashes, tagged with device and memory context, tell you which devices and memory tiers are failing. For a Solar2D game on fragmented mobile hardware, this combination of representative device testing and device-tagged capture is what lets you keep the game stable across the phones players actually use.

Solar2D is Lua on fragmented phones. Capture both Lua and native crashes, with the device and memory.