Rootconf 2026 Annual Conference

Give Your Entire Team X-Ray Vision Into Your Mobile App

Mobile apps are often treated like black boxes where debugging is gatekept behind complex IDEs and terminal commands. This session explores how embedding a lightweight web server inside your app can provide real-time, browser-based visibility into databases, network calls, global app state and any custom app state to completely eliminate the “It Works on My Machine” problem.

What problem are you addressing? What real engineering challenge, question, or experience is this session about?

We are addressing the classic “It Works on My Machine” problem in mobile development.

The Challenge: When a QA engineer flags a bug, developers often struggle to reproduce it because mobile platforms spread debugging information across different, disconnected tools (system logs, database, n/w logs, in memory state etc).

What made it difficult: Replicating persistent state to reproduce bugs is notoriously complex. Developers typically have to manually extract SQLite or shared preference files via ADB, edit them using a third-party tool, and push them back to the device.

Why this matters to engineering teams: Finding the right context is the hard part of fixing a bug. Solving this saves multiple minutes of tedious file-extraction, empowers non-technical team members to provide perfect bug reports, and drastically shortens the feedback loop.

Who is the intended audience?
Developers (Android/Mobile), QA Engineers, Platform Engineering, and Engineering leaders.

Level: Intermediate

List one or two practical takeaways.
Debugging is hard only if the tool you have to work with are complex, the information you need is not available, simplifying the mechanims to generate context and create state needed for debugging significantly improve the overall productivity

People are really open to do first level of debugging if we can empower them with the right tools that they can use.

What will you share?

• Architecture
• Product experience
• Live demo

What is your experience with this problem? Choose any that apply:

• Internal engineering project
• Hard-earned engineering lesson

What approaches failed, disappointed, or created unexpected problems?
Relying on traditional system logs, which rarely show the useful context needed to diagnose UI state bugs like a blank profile screen.

QA relying entirely on developers to hook up devices via USB and sift through Logcat output.

Relying on backend teams to change data or mock responses to test special UI states (like HTTP 500 errors or missing fields).

Screen recordings that only show what appeared on the screen, but completely fail to show why it happened behind the scenes.

What will you do differently today?
Instead of spending half an investigation trying to rebuild the app’s state, we give the entire team (including QA) a shared web browser view of the requests the app made and the data it saved.

We use a Session Recorder that acts like a timeline scrubber, correlating every touch event with exact database diffs, network calls, and SharedPreferences changes.

We use on-the-fly network mocking directly from the browser to intercept and modify API responses without touching the backend or app code.

What trade-offs did you consider?

Dynamic Extensibility vs. Controlled Architecture: Instead of locking Lens to a fixed set of core SDK features, we built a dynamic runtime registry allowing consumer teams to instantly inject custom tools (like deep-link testers or domain logs). The trade-off was accepting higher API maintenance overhead and needing defensive isolation to ensure an unhandled exception in a consumer’s custom plugin wouldn’t bring down the core debugging server.

How can this help other practitioners?

• A design approach
• A debugging technique
• A pattern to adopt
• A new way of thinking about the problem

Current state - choose one:

• Production experience

#mobileapps, #debugging, #Android, #iOS, @mobile-engineering @demo