Disabling Jahro in Builds and Lifecycle

Understanding how Jahro manages its lifecycle is crucial for maintaining clean production builds while keeping debugging capabilities available during development.

Why this matters

Jahro is a development-time console designed to enhance your debugging workflow. Shipping it in production builds can add runtime overhead, create additional network load if streaming is enabled, expose internal commands or debug data, and slightly increase build size.

How Jahro decides to run

Jahro evaluates multiple conditions at startup to determine if it should be enabled:

  1. Preprocessor define (highest priority): If JAHRO_DISABLE is defined, Jahro is disabled regardless of other settings.
  2. Auto-disable in Release: If "Auto-disable in Release Builds" is ON and the build is not a Development Build (!Debug.isDebugBuild), Jahro disables itself.
  3. Project setting: Otherwise it uses the "Enable Jahro" switch in settings.

This logic ensures Jahro is active during editor and development builds, and disabled in releases by default.

Preprocessor control

You can force-disable Jahro via preprocessor define in Player Settings → Scripting Define Symbols. Add JAHRO_DISABLE to the list, separating multiple defines with semicolons (e.g., JAHRO_DISABLE;MY_DEFINE).

This completely disables Jahro regardless of project settings or build type, giving you absolute control over when Jahro is available.

Project settings control

In Unity Editor → Tools → Jahro Settings → General Settings, you can configure:

  • Enable Jahro: Master switch for Jahro functionality
  • Auto-disable in Release Builds: Automatically disables Jahro in non-development builds

For Development builds: Enable Jahro and keep "Auto-disable in Release Builds" ON to ensure debugging capabilities are available when you need them.

For Release builds: Use "Auto-disable in Release Builds" or add JAHRO_DISABLE preprocessor define to ensure clean production builds.

Validation: You will see Jahro Console: Disabled in this build in the Unity console when Jahro is properly disabled.

Lifecycle overview

Once Jahro is enabled, it runs automatically without requiring additional code or actions. No prefab manipulation or special setup is needed to make Jahro work.

Jahro's runtime lifecycle consists of initialization, UI/view setup, session start, and release/cleanup phases.

Initialization (before splash screen)

Jahro runs automatically using [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]. During this phase, it loads project settings, sets Jahro.Enabled based on preprocessor defines and settings, clears early log buffers, and prepares logging infrastructure.

If Jahro is disabled, initialization exits early to minimize overhead.

Runtime boot and view setup

A second [RuntimeInitializeOnLoadMethod] step runs after engine startup. This phase initializes console storage and the Jahro UI view, verifies the API key, starts a Jahro session and loads runtime context, and injects the UI manager (window, tabs, launch button) while binding hotkeys (Launch key, Alt+1/2/3) and mobile tap activation if enabled.

Release

Jahro's release sequence saves console state to storage (window size/position, favorites, defaults), disposes the logger, destroys the UI view, and ends the Jahro session.

This happens when your app quits, when assemblies are reloaded in the editor, or when you explicitly call Jahro.Release().

Next Steps

Explore more Jahro features to build a complete debugging workflow:

  • API Reference - Learn about programmatic control and integration
  • Getting Started - Set up Jahro in your Unity project
  • Snapshots - Learn how Snapshot Streaming works for team collaboration

For production considerations, check out Jahro Settings configuration and learn about team management in the web console.