DocumentationAzkar ConsoleUnity API Compliance and Native Console Limitations

Unity integration

Unity API Compliance and Native Console Limitations

Understand which native Unity Console operations Azkar Console intentionally omits, why the Asset Store rules require that boundary, and which supported alternatives remain available.

  • The governing Asset Store rules
  • What Unity's public log callback exposes
  • Native Console operations not included
  • Supported alternatives and expectations

The Governing Unity Asset Store Rules

Unity's current Asset Store Submission Guidelines were last updated May 20, 2026. Two rules are directly relevant:

  • Rule 2.5.g: “Offerings must not use Unity Editor internal APIs discovered through reflection or similar mechanisms.”
  • Rule 3.1.a: unexpected limitations that influence usability must be disclosed transparently in the marketing data; failure to do so can warrant refunds and package deprecation.

Azkar Console follows both rules: it avoids Unity Editor internals and states the resulting behavior here, in the product page, Asset Store listing, and installed offline documentation.

What Unity's Public API Exposes

Unity documents Application.LogCallback with three values: the message (condition), stack trace, and LogType. The callback does not include the original context object, a native Console row identifier, or native selection state.

Compiler warnings and errors use Unity's documented CompilationPipeline.assemblyCompilationFinished event, which supplies structured compiler messages. Optional boundedEditor.log startup recovery can recover eligible startup text when enabled before bootstrap, but it does not reconstruct private native rows or their metadata.

What Azkar Console Intentionally Does Not Do

With Unity's current documented public API surface, implementing the following inside an Asset Store package would require undocumented Unity Editor internals. Azkar Console therefore does not:

  • enumerate or import Unity's existing native Console history;
  • backfill arbitrary native rows produced while capture was disabled or before Azkar Console subscribed;
  • recover the original context object, native row identity, or native selection state from a Unity-originated callback message;
  • promise Ping Context Object for Unity-originated callback rows;
  • select or reveal the exact matching row inside Unity's Console;
  • clear Unity's native Console when Azkar Console is cleared; or
  • invoke Unity's hidden manual-IP PlayerConnection window or internal direct-IP connection method.

Azkar Console also cannot promise capture of an editor-internal message that Unity publishes through neither its public log callback nor its public compilation pipeline. This is different from losing an AzConlog: logs sent directly through the public Azkar API use Azkar's own capture path and structured metadata.

Supported Alternatives

  • Keep Unity's Console available for its original history, exact native row, and native context-object behavior. Azkar Console can open that window through Unity's public menu command, but cannot choose a private row.
  • Pass a Unity object explicitly to AzCon when you need reliablePing Context Object behavior in Azkar Console.
  • Use supported PlayerConnection discovery, enable Autoconnect Profiler for the Development Build, or select the player from Unity's Profiler connection menu.
  • Enable bounded Editor.log startup recovery before bootstrap when eligible startup text matters, understanding that it cannot restore native row identity, selection, or context metadata.

This boundary protects Asset Store eligibility and avoids depending on private implementation details that Unity may change without notice. If Unity publishes supported public APIs for these operations, Azkar Industries can reevaluate them in a future release.