Two debuggers, one UI. LingCode wraps lldb-dap for Apple targets and the JDWP-based Kotlin debugger for Android, then exposes both through the same panel. The buttons (Continue / Step Over / Step Into / Step Out / Pause) work the same way regardless of target.
Prerequisites
- For iOS / macOS: Xcode command-line tools installed.
lldb-dapships with them. Runxcode-select --installif missing. - For Android: Android SDK + JDK installed and discoverable. LingCode picks them up via
ANDROID_HOME, the standard SDK paths, or the toolchain banner in the editor that prompts you on first open of an Android project.
Set a breakpoint
Click the gutter
Open any source file (.swift, .m, .kt, .java). Click the line number in the left gutter — a red dot appears. Click again to remove. Same gesture as Xcode and IntelliJ.
Add a condition (optional)
Open the Breakpoint Navigator from the sidebar (the breakpoint icon). Each breakpoint has an editable condition field — type a Swift / Kotlin expression and the debugger only stops when it evaluates to true. Useful for "stop the 100th time" or "stop only when user.id == 42".
Launch under the debugger (Apple)
Pick a destination
Top-right of the editor: the destination dropdown lists every booted simulator and physical device. Pick one. If nothing shows up, open Xcode → Window → Devices and Simulators once to register them.
Hit Debug (⌘⇧Y)
LingCode does what Xcode would do: xcodebuild in Debug config → installs the .app on the destination → launches under lldb-dap → attaches the UI. Build output streams to the Output panel; runtime print() and crashes stream to the Run Console panel; debugger transcript appears in the DAP Debug panel.
Hit a breakpoint
When execution stops, the FloatingDebugToolbar appears over the editor with Continue / Step Over / Step Into / Step Out / Pause buttons. The line is highlighted in the editor; the call stack appears in the DAP panel.
Launch under the debugger (Android)
Boot an emulator or plug in a device
Use the destination dropdown. The Android toolchain banner verifies adb, the SDK, and JDK before letting you launch.
Hit Debug
LingCode builds via Gradle (./gradlew installDebug equivalent), launches the app on the device, and attaches the JDWP debugger. The Kotlin Debug panel shows threads, stack, and variables.
Inspect state while paused
- Variables tree — every scope (locals, parameters, captured, globals) with nested objects expandable to any depth.
- Threads & Stack — list all threads; expand any to see its frames; click a frame to navigate the editor to that source line.
- Evaluate — at the bottom of the Debug panel, type any expression in the current scope and press Enter. Result appears inline. Works for both Swift (
self.user.name,items.count) and Kotlin.
Step / continue / pause
Use the FloatingDebugToolbar that appears over the editor, or the Debug panel buttons. Standard semantics:
- Continue (⌘⌃Y) — run until next breakpoint or program exit.
- Step Over (F6) — execute current line; do not enter function calls.
- Step Into (F7) — enter the next function call.
- Step Out (F8) — finish the current function and stop at the caller.
- Pause — interrupt a running program (e.g. an infinite loop).
Debug Console (the bottom-panel tab)
Separate from the LLDB debugger, the Debug Console tab in the bottom panel is a live NDJSON log viewer. Anything written to ~/Library/Logs/LingCode/diagnostics-*.json or ai-events-*.json streams here in real time, with filter and clear. Use this when:
- Diagnosing crashes after the fact (MetricKit dumps land here).
- Watching agent-loop tool calls fire (LingCode's own AI events).
- Tailing structured logs from your own app — point its logger at the same directory.
Skip the debugger: just ask the AI to fix it
This is what makes LingCode different from Xcode and Android Studio. The agent already has read access to your build state — you don't have to copy-paste anything. Open the chat panel and try one of these:
- Build broken? Type "check my output and fix the bug". The agent calls
get_build_errors, reads the failing files, applies asearch_replace, and (if you ask) re-runsrun_buildto verify. - App crashes at runtime? Type "the app just crashed, check the run console and tell me why". The agent calls
get_run_console_tailon the app's stdout/stderr, reads the relevant source, and proposes a fix. - Stopped at a breakpoint and confused? Right-click the line in the editor → Add to Chat, then ask "why is
itemsempty here?". The agent reads the function and the call sites that reach it. - Got a Swift compiler error you don't recognize? Right-click the error in the Output panel → Explain with AI. A streaming explanation appears right there — no chat round-trip needed.
- Test failure? Type "my tests are failing — fix them". The agent calls
run_tests, parses results, reads the failing test + production code, and patches whichever is wrong.
The agent has the same tools you do — read_file, search_replace, run_build, run_tests, goto_line, plus the build/run-console readers. Tell it the symptom; it finds the cause and proposes the fix. You stay in the editor the whole time.
Best results when you give it scope. "Fix the bug" is vague — the agent might fix the wrong one. "Look at the type-mismatch error in UserView.swift from the last build and fix it" is targeted; the agent goes straight to the issue.
Debug Mode (no debugger required)
The Debug sidebar tab opens a debugging-assistance workspace independent of LLDB. It pairs:
- A live log viewer with regex filter for any file you choose.
- A repro-steps note pad — durable across sessions, bound to the project.
- An issue tracker column where you stash error snapshots and clean them up as you fix them.
Useful when you're debugging a flaky integration, a third-party SDK with bad logging, or anything where you want to think about a bug before stepping through code.
Troubleshooting
- "Could not find lldb-dap": run
xcode-select --install, restart LingCode. - App launches but no breakpoints hit: make sure you built in Debug config, not Release. Release strips debug symbols. Check the destination dropdown is on Debug, not Release.
- Step Into goes into a system framework: normal — Apple's
libdispatch,SwiftUI, etc., have public symbols. Use Step Out to come back to your code, or set "Just My Code" if available. - Android debugger times out attaching: emulator's ADB connection may have stalled.
adb kill-server && adb start-server, then retry. Check the Android toolchain banner for green status. - Breakpoints disappear after rebuild: they shouldn't — they're stored per-project. If they do, file an issue with the project structure (file an issue from support).
What to read next
- Getting Started — install LingCode and connect Claude.
- Collaboration — share a debug session with a teammate live.
- Claude Sessions — ask the AI to explain a stack trace while paused.
- Skills reference — slash commands for /explain, /fix, /review.
Not downloaded yet?
Download for Mac