UnityIngameDebugConsole: an in-game console for Unity builds

What problem UnityIngameDebugConsole solves

A Unity editor session gives you the Console window, breakpoints and the profiler. A build on a phone or a console does not. The README describes the asset as a way to "see debug messages (logs, warnings, errors, exceptions) runtime in a build (also assertions in editor) and execute commands using its built-in console." That is the whole scope: the messages your code already emits through Debug.Log and its relatives become visible on the device, and a text field lets you call functions you registered ahead of time.

The intended user is a Unity developer who tests on hardware and wants a faster loop than attaching a debugger or rebuilding with extra on-screen text. The README also notes Android logcat support, so native-side messages can be pulled into the same window. The Asset Store listing, the forum thread and a Discord invite are the support channels the README points to; there is no hosted service behind it.

How the console renders and stays cheap

The interface is built with uGUI. The README states it costs 1 SetPass call and 6 to 10 batches when Sprite Packing is enabled. Those numbers are the author's, not a measurement made here, but they matter because an overlay that redraws on every log line can dominate a mobile frame budget.

The list is a customized recycled list view that, in the README's phrasing, calls Instantiate sparingly. Instead of creating a new row object per message, rows are reused as the view scrolls, which is the standard reason such a console can survive a chatty log stream.

The window is resizable and can be hidden during play. When hidden, a small draggable popup takes its place and shows how many logs arrived since it appeared; clicking the popup brings the window back. That is the mechanism for keeping the console out of the way while still knowing something happened.

Commands are not discovered by reflection at runtime. A function becomes a command only after one of the registration paths described below runs, so the exposed surface is exactly what you wrote.

Installing the plugin and running a first command

The README lists five installation routes. The quickest for a Git-based project is the Package Manager path: open the Package Manager, click the + button, and install from the git URL below.

https://github.com/yasirkula/UnityIngameDebugConsole.git

If you prefer OpenUPM, install openupm-cli first and then add the package by its name. The README gives this exact command.

openupm add com.yasirkula.ingamedebugconsole

The other three routes are importing IngameDebugConsole.unitypackage through Assets-Import Package, copying the Plugins folder from a clone or the master zip into Assets, or buying it from the Asset Store. The package manifest identifies the package as com.yasirkula.ingamedebugconsole, version 1.9.0, under the MIT license.

Once the package is in the project, the README says to simply place the IngameDebugConsole prefab into your scene. Inspector tooltips explain the prefab's properties. In the editor, right-clicking a log entry opens the corresponding line in your external script editor, which mirrors double-clicking a log in the Unity Console.

To add a command, the README shows the attribute route. The function must be public static and live in a public class, and the attribute is not supported on the UWP platform.

using UnityEngine;
using IngameDebugConsole;

public class TestScript : MonoBehaviour
{
	[ConsoleMethod( "cube", "Creates a cube at specified position" )]
	public static void CreateCubeAt( Vector3 position )
	{
		GameObject.CreatePrimitive( PrimitiveType.Cube ).transform.position = position;
	}
}

With that compiled, typing help in the console input field lists registered commands. The README's example invocation is cube with a bracketed vector.

cube [0 2.5 0]

The help entry then reads: cube: Creates a cube at specified position -> TestScript.CreateCubeAt(Vector3 position). If the function returns an object, the README says the result is printed to the console.

Registering commands without the attribute

The attribute is only one of four registration methods, and it is the most restrictive: public static only, public class only, no UWP. The other three drop those constraints, which matters when the function you want to expose is an instance method that needs live state.

The strongly typed overloads are the documented alternative. The README shows DebugLogConsole.AddCommand with a plain Action and a generic Vector3 overload.

using UnityEngine;
using IngameDebugConsole;

public class TestScript : MonoBehaviour
{
	void Start()
	{
		DebugLogConsole.AddCommand( "destroy", "Destroys " + name, Destroy );
		DebugLogConsole.AddCommand<Vector3>( "cube", "Creates a cube at specified position", CreateCubeAt );
	}
}

All four methods accept optional trailing string parameters that set custom display names for the function's parameters. That is a small detail with real value: a parameter named position in code can read as the more legible label you choose in help output.

The parser is deliberately simple, and the README is explicit about its restrictions. Wrap strings in quotation marks, single or double. Wrap vectors in brackets or parentheses. Beyond that there is flexibility: an empty vector stands for Vector_.zero, 1 substitutes for true and 0 for false, and null is accepted for null GameObject or Component parameters. Those GameObject and Component arguments are resolved with GameObject.Find, which is worth remembering because Find matches by name and is not a general-purpose reference lookup.

Parameter types, and where the console stops being the right tool

The supported parameter list is long but closed. It covers primitive types, enums, string, Vector2 through Vector4, Color, Color32, the integer vector types, Quaternion, Rect, RectInt, RectOffset, Bounds, BoundsInt, GameObject, any Component type, and arrays or Lists of those. A function with a parameter outside that set cannot be registered as a command.

That is the sharpest limitation. If your debugging routine needs a custom serializable class, an interface, a delegate or a dictionary, the console will not take it. The practical workaround is to write a thin wrapper whose parameters are all supported and let the wrapper do the conversion, which is extra code you maintain.

Two platform notes from the README are also failure modes rather than features. On Unity 2019.2.5 or earlier the New Input System is not supported unless you add the ENABLE_INPUT_SYSTEM compiler directive to Player Settings/Scripting Define Symbols, and those symbols are platform specific, so switching the active platform means adding the directive again. On Unity 2018.4 or earlier the Unity.InputSystem assembly cannot be resolved, and the fix is to remove that assembly from the IngameDebugConsole.Runtime Assembly Definition File's references list. Both are version-bound workarounds, not configuration you set once and forget.

Android has its own traps. A build can fail with "D8: java.lang.NullPointerException Failed to transform IngameDebugConsole-.aar"; the README attributes this to the plugin using Gradle version 7.5.1 and Android Gradle plug-in version 7.4.2, and points to Unity's Android Gradle overview to check compatibility. Separately, if the Receive Logcat Logs In Android option does nothing and logcat reports java.lang.ClassNotFoundException: com.yasirkula.unity.DebugConsoleLogcatLogger, the README says to enable Custom Proguard File in Player Settings and add a keep rule.

-keep class com.yasirkula.unity.* { *; }

None of this makes the plugin fragile in normal desktop use. It does mean the Android path is the one to budget time for.

How it differs from Lunar Console and SRDebugger

The related searches around this project name Lunar Console, SRDebugger, Meta Immersive Debugger and a generic "Unity debugger github". Those are the comparison points a reader will already have in mind, so the difference is worth stating plainly.

Lunar Console and SRDebugger are the two names that come up most often in the same searches. Both appear in the related-searches list for this project, and both are commercial products with their own feature sets; this article does not cover their internals. What can be said from this repository alone is the shape of the trade: UnityIngameDebugConsole is MIT-licensed, its source sits in the Plugins folder of the repository, and the README documents the command parser, the registration APIs and the rendering cost in enough detail that you can read the implementation. A closed product gives you a support contract and a roadmap you do not maintain; this gives you the code and the responsibility.

The other difference is scope. This plugin is a console and a command runner. It is not a crash reporter, not a remote dashboard, and not an analytics pipeline. If you need logs aggregated across many devices with alerting, you are looking at a different category of tool, and the README does not claim otherwise.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-06, which is the same day v1.9.0 was released. The two releases before that, v1.8.9 and v1.8.8, landed on 2026-08-09 and 2026-06-27. That cadence is consistent with a maintainer who ships fixes and small additions rather than a rewrite in progress.

The licence is MIT, declared in LICENSE.txt at the repository root and referenced from package.json through licensesUrl. MIT permits commercial use and modification, and it requires that the copyright notice and permission notice travel with copies. This is a description of the licence text, not legal advice; if your organisation has a policy on third-party assets, route it through that policy.

Upgrade cost is mostly the version-bound items already listed. The Unity.InputSystem assembly reference, the ENABLE_INPUT_SYSTEM define, and the Android Gradle versions are the things that break when the surrounding Unity version moves. The package version in package.json is the value the Package Manager resolves, so pinning it is the straightforward way to keep a working build stable while you evaluate a bump. The README does not document a rollback procedure, so plan the upgrade as a branch you can discard.

Editorial conclusion

Adopt UnityIngameDebugConsole if you ship Unity builds to devices and want logs and a command line inside the running game. Skip it if you need a full remote analytics or crash-reporting pipeline, since it is a local console, not a telemetry service. Before adopting, verify that your Unity version resolves the Unity.InputSystem assembly reference, that the Android Gradle versions match the plugin's 7.5.1 and 7.4.2, and that the command parameter types you plan to expose are in the supported list.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yasirkula/UnityIngameDebugConsole on GitHub