Roadmap

EmuLabZip grows in phases. Each phase ends with a release, and every item in it ships working on Android emulators and, where the platform allows, iOS simulators. Items are roughly in priority order within each phase. Ideas and pull requests are welcome; open an issue to discuss anything large first.

✅ Phase 1: Connect and observe (v0.1)#

Automatic discovery of Android emulators and devices (pure-Rust ADB client) and booted iOS simulators (simctl) · device picker with live status · app picker with running process ids · Overview with build, hardware, display, battery, storage, locale and host facts · live screen preview and screenshots · streaming log viewer for logcat and the unified log: level, tag, text and regular-expression filters, per-app filter, pause, virtualized list that handles thousands of lines per second, plain-text and JSON-lines export · emulabzip command line: devices, info, apps, logs, screenshot.

✅ Phase 2: Performance, memory and storage (v0.2)#

Live CPU, memory, frame rate, janky frames and battery charts for the selected app · memory breakdown (Java, native, graphics, code, stack on Android; VM regions on iOS) with snapshots and a diff · heap dumps (.hprof) on Android and memory graphs (.memgraph) on iOS · file browser for the app sandbox (run-as for debuggable Android apps, shared storage, and the data, bundle and app group containers on iOS) · SQLite inspector with paged rows and read-only queries · SharedPreferences, property list, JSON, image, text and hex viewers · emulabzip perf, mem, heapdump, files, pull and db. See Performance, Memory and Storage.

✅ Phase 3: Network (v0.3)#

A standalone HTTP(S) proxy written in Rust (emulabzip-net) that decrypts HTTP/1.1 and HTTP/2 · one-click routing of an Android device (adb reverse and the global proxy setting) or of the iOS Simulator (the Mac's proxy, saved and restored exactly) · certificate installation: the system store on rootable emulators, a guided user certificate elsewhere, simctl keychain on simulators · request list with filters, headers, decoded bodies and timing · hosts that reject the certificate are passed through · WebSocket and other connections tunnelled and listed · HAR export · emulabzip net and emulabzip ca. See Network.

✅ Phase 4: Tracing (v0.4)#

Perfetto system traces with presets (CPU and scheduling, frames and jank, memory, custom) · a summary and a SQL console backed by the official trace_processor, downloaded once, pinned and verified · CPU flame graphs from simpleperf (an app or the whole system) · Instruments recordings with xctrace, with a flame graph for Time Profiler · open traces in the Perfetto UI or in Instruments · a library of recordings · emulabzip trace. See Traces.

✅ Phase 5: Crashes and automation (v0.5)#

Crash, native crash and ANR collection (DropBox on Android, .ips reports on the iOS Simulator) with stacks, the facts the device wrote down, hints for symbolication, and a notification when a new one happens · controls for location, appearance, the status bar, battery, permissions, notifications and links · an MCP server so AI assistants can read devices, logs, crashes and traces and act on them · plugins: your own collectors as programs that print JSON lines, enabled by the user. See Crashes, Controls, MCP server and Plugins.

✅ Phase 6: Network power tools, layout and sessions (v0.6)#

Mocks, delays, blocks and breakpoints on requests and responses · WebSocket messages, including permessage-deflate · packet capture import (emulator -tcpdump, .pcap and .pcapng) with HTTP, TLS server names and DNS · HTTP/3 from the proxy to servers · layout inspection and an accessibility audit (labels, touch targets, contrast) on Android and the iOS Simulator · sessions recorded to a single file, and CI mode that records around a test run · comparing two devices. See Mocks, WebSockets, Capture import, Layout, Sessions, CI mode and Compare.

Phase 7: Performance and quality (v0.7) ✅#

App start time, cold, warm and hot: am start -W and the Displayed lines on Android, simctl launch with the unified log's launch signposts on iOS, repeated N times with the median shown · energy per app: dumpsys batterystats (CPU, wakelocks, radio, GPS) on Android, the thermal state and CPU time on the simulator · a leak finder for .hprof heap dumps: retained sizes, dominators, and destroyed Activities and Fragments that are still reachable, with the path to the GC root · performance budgets in an emulabzip.toml (start time, memory peak, janky frames, request count) that emulabzip ci checks, failing the run when one is broken · baselines: compare a run with the last good one and say what got slower.

Phase 8: Inside the frameworks (v0.8) ✅#

Flutter: the Dart VM service of debug builds (widget tree, frame timings, memory) · React Native: Hermes and the React tree through the debugger protocol · Jetpack Compose and SwiftUI in Layout through their semantics trees, with recomposition counts where Android exposes them · network decoding for gRPC and protobuf (with .proto files, or raw) and GraphQL, with operations named in the list · edit and resend a request · network conditions in the proxy: presets for 3G, slow Wi-Fi, high latency, offline and packet loss.

Left for later from this phase: recomposition counts (Android Studio gets them from an agent loaded into the app, which uses interfaces that are not public), SwiftUI's own view type names (accessibility does not expose them), and recording the network conditions in a session.

Phase 9: Readable stacks and one-click bug reports (v0.9) ✅#

Symbolication of crashes and stacks: R8 and ProGuard retrace from mapping.txt, dSYMs with atos on a Mac, and Hermes and Metro source maps, so React Native JavaScript stacks point at the right file and line · mapping files kept per app and version, and --mapping in the command line · a bug report in one click: the session, a screenshot, the device's details, the filtered logs and the failed requests, packed into one HTML file or opened as an issue on GitHub, GitLab or Jira.

Phase 10: Timeline and replay (v0.10) ✅#

A timeline that lines up touches, log problems, requests, slow frames, garbage collections and crashes on one time axis, on a clock measured against the device · screen video recorded into a session in short pieces (screenrecord on Android, simctl io recordVideo on iOS), in step with the timeline in the desktop app, and the clip around the crash added to bug reports · network replay: a session or a HAR file answers the app's requests, so it runs offline against recorded responses, for bugs whose backend has since changed and for deterministic CI runs (--replay, --fail-on-miss).

Left for later from this phase: touches on iOS (the simulator gives them to nothing outside it), per-frame jank on iOS, replaying WebSockets and gRPC calls (a HAR file does not hold their messages and trailers), and matching a request that carries a timestamp or a random id.

✅ Phase 11: App state as data (v0.11)#

App state snapshots: save the whole sandbox to one .ezstate file and restore it (run-as and tar for debuggable Android apps, the data container on the simulator), with an automatic backup of what a restore replaces · emulator snapshots and the device lifecycle: create, start, stop, wipe and delete AVDs and simulators, and avd snapshot save|load|delete · a write mode in Storage for SQLite rows and SharedPreferences (property lists from the command line), behind a confirmation, with Undo, and read-only staying the default · viewers for DataStore, MMKV, AsyncStorage, Core Data and Realm (with a reader of Realm's file format) · a schema diff between two states, for testing migrations · React Native state: Redux, React Query, context and registered stores, with a Redux action log.

Limits: Realm sets, dictionaries, mixed, decimal and UUID columns are not read; MMKV types are guessed; Core Data attribute names lose their case; AsyncStorage and Core Data from an iOS device were tested on fixture files, not on a simulator; Flutter state is not read.

✅ Phase 12: Quality beyond performance (v0.12)#

A security and privacy audit while the app runs: cleartext traffic, tokens and personal data in logs and preferences, exported components (dumpsys package), the debuggable and allowBackup flags, App Transport Security exceptions in Info.plist and domains missing from the privacy manifest · an APK, AAB and IPA analyzer: size by folder, dex and assets, a diff between two builds, and a size budget in emulabzip.toml · localization checks: pseudo-locales (en-XA, ar-XB), font scale and display size controls, a sweep across languages and sizes, and text that does not fit found through Layout · more accessibility checks: focus order and colour blindness simulation (text scaling through the sweep) · visual regression: screenshots compared with a baseline, with a difference picture and a check in CI · an analytics inspector: Segment, Amplitude, Mixpanel and Firebase events decoded by the proxy, and Firebase's debug log.

Limits: the audit cannot see the exported attribute (dumpsys does not print it) and judges text by pattern; the size analyzer reads sizes, folders and dex headers, not bytecode, and not an installed app yet; cut-off text is a heuristic; Android changes the language per app, not per device; the Firebase decoder was tested on payloads made to Google's layout, not on live traffic; there is no analytics tool over MCP.

✅ Phase 13: Automation and hybrid apps (v0.13)#

WebViews on Android through the Chrome DevTools Protocol, over ADB's localabstract sockets with nothing forwarded: their console, JavaScript and requests inside EmuLabZip (the requests in the Network view, marked WEBVIEW), and a guided shortcut to Safari's Web Inspector on iOS · input on Android (tap, swipe, text, keys and launching an app) in the app, the command line and MCP, and recording a flow from getevent, played again and exported as a Maestro flow or a shell script; iOS has no public interface for touches, so this stays Android only · a deep link tester with history and pins, checking the domain's assetlinks.json or apple-app-site-association, the app's signing key, team id and entitlement, what the device decided (pm get-app-links) and who opens the link · programmable network rules: map local and map remote, rule chaining, responses checked against an OpenAPI 3 file, and rule scripts in sandboxed WebAssembly that run only after their exact bytes are approved. See Web pages in apps, Input and flows, Deep links, Network rules and Rule scripts.

Limits: WebView inspection needs a debuggable app, and iOS is a shortcut to Safari, not an in-app console; flows record the touchscreen only (not injected taps and not typed text) and label a tap only when the screen was read in time; the deep link check on a simulator cannot verify domains the way a device does; OpenAPI checks cover JSON responses, not requests; Map local and Map remote do not apply to gRPC calls; scripts keep nothing between calls; assistants can list WebViews, read their console, check links and play flows, but cannot run JavaScript in a page or approve a script.

✅ Phase 14: AI with context (v0.14)#

The MCP server grew from 67 stateless tools to 118 tools, 8 prompts and 13 resources (130 tools with changes turned on) that keep state while they run: the proxy and captured requests (start, connect a device, filter and read requests, rules, conditions, replay, breakpoints, HAR export, OpenAPI checks), live watches for logs, performance, touches and WebView and React Native streams, recording a session and comparing two, read-only app data (SQLite, Realm, Core Data, preferences, DataStore, MMKV, AsyncStorage), crash reading with stored mappings, device creation, flows, visual baselines, language sweeps and build budgets · every tool has a title and says whether it reads, changes or destroys · prompts for the common jobs (explain a crash, why it is slow, summarize a session, reproduce a bug, debug a request, check a release, check a link, mock a backend) and resources an assistant can read (devices, sessions, flows, the live capture, a guide) · writes are opt-in: emulabzip mcp --allow-writes offers the tools that wipe, delete, restore or rewrite data, and each call asks the person to confirm through the client; approving scripts and plugins, and ci, are never offered · an AI assistants card in Settings with the configuration for Claude Code, Claude Desktop, Cursor and VS Code · a generated MCP reference that a test keeps in step with the server. See MCP server.

Limits: editing rows and preferences, undoing an edit, recording a flow by touch and importing a packet capture are not offered over MCP (they stay in the app and the command line); a long tool does not report progress yet; a session's video frames are not returned as images; a client that cannot ask for confirmation cannot use the write tools unless --no-confirm is given; the watches keep the last 5,000 items and end after ten idle minutes.

Phase 15: Devices and platforms (v0.15)#

Physical iPhones and iPads through the tools Xcode ships (devicectl, usbmuxd): logs, apps, screenshots, crashes and files where iOS allows it, and a plain note where it does not · Android over Wi-Fi, with wireless debugging pairing from the app · Wear OS and Android TV emulators, and watchOS, tvOS and visionOS simulators, with the views that apply to each · several devices at once: logs and requests from two devices in one list, tagged by device.

Phase 16: Team and ecosystem, 1.0 (v1.0)#

Comparing sessions side by side, and a shareable HTML report of a session (one file, no server) · shared rule libraries: a rules file kept in the app's repository, loaded by the app and the command line · a VS Code extension with devices, logs and the MCP server in the editor · a plugin catalog: community plugins listed with checksums, still enabled one by one by the user · an interface in Portuguese and other languages · updates: signed auto-update in the app, and Homebrew, winget and Scoop packages · the 1.0 promise: the command line's options and JSON, the MCP tools and prompts, and the .ezsession format are stable, and change only with a major version.

Ideas#

What is not in a phase yet: layouts for apps that draw their own UI (games, canvases) · HTTP/3 streaming for very large responses · plugins that read sessions · an optional companion SDK (npm, Gradle, SwiftPM) for what only code inside the app can see, such as Redux, Zustand or React Query state, recomposition counts and feature flags, kept apart from the default, which installs nothing on the device.