Debug Mode
activeTurn on verbose diagnostics to see exactly what an SDK is doing.
Web SDK
Call debug() on the global Binoban object to turn on console logging:
Binoban.debug(true); // enable
Binoban.debug(false); // disable
Once enabled, subsequent identify/track/page calls log messages to the
browser console. It's a runtime toggle — no separate build or flag — so you can
call it from the browser console during a live session too.
Native SDK (Android & iOS)
The Native SDK exposes a static, KMP-shared switch:
// Android (Kotlin)
Binoban.debugLogsEnabled = true
// iOS (Swift)
Binoban.companion.debugLogsEnabled = true
It's false by default and applies to every Binoban instance in the process —
set it once, before or after you construct your client.
Routing logs elsewhere
By default the SDK logs to the console (ConsoleLogger). To capture log output
yourself — for example, to forward it into your own diagnostics pipeline —
implement the Logger interface and register it once:
class MyLogger : Logger {
override fun parseLog(log: LogMessage) {
// log.kind: ERROR | WARNING | DEBUG
// log.message, log.dateTime
}
}
Binoban.setLogger(MyLogger())
React Native
The React Native bridge's debug-mode surface (whether it exposes its own toggle
or forwards to the native debugLogsEnabled switch) hasn't been verified against
source yet. Confirm with Binoban support before relying on it.
Reading the output
Debug logging is a development aid, not a documented log-line schema — treat
message text as informational rather than a stable format to parse against.
There's currently no published catalog of exact log messages (a fixed "event
queued" / "event sent" vocabulary, for example); what you'll see is whatever the
active Logger implementation prints for LogKind.DEBUG entries (Native), or
the browser console output emitted after Binoban.debug(true) (Web).
Leave debug mode off (false) in production builds — see the
Go-live checklist.