DEV Community: Luis Peixoto

Criei um laboratório de debug open source para emuladores Android e simuladores iOS

Luis Peixoto — Sun, 15 Nov 2026 14:03:21 +0000

Quando depuro um app mobile, acabo com seis ferramentas abertas: o Logcat, a janela do Instruments, os profilers do Android Studio, um proxy como o Charles, um terminal cheio de adb shell e xcrun simctl, e um editor de texto para ler algum banco de dados que puxei do dispositivo. Cada uma conhece uma fatia do que o emulador sabe, e nenhuma conversa com as outras.

Por isso criei o EmuLabZip: um app open source que se conecta aos seus emuladores Android e simuladores iOS em execução e traz tudo isso para uma janela só. Ele é escrito em Rust, vem como app desktop (Tauri + Svelte) e como ferramenta de linha de comando, e nada é instalado no dispositivo.

O que ele faz

Você inicia um emulador ou liga um simulador, e ele aparece. Não há configuração no dispositivo e nada para adicionar ao seu app. A partir daí:

Logs do logcat e do unified log do iOS em uma única tabela que continua fluida com milhares de linhas por segundo, com filtros por nível, tag, texto, regex e por app.
Desempenho e memória: CPU, memória, taxa de quadros, frames travados e bateria do app que você escolher, snapshots de memória que você compara por categoria, e heap dumps do Android com um detector de vazamentos embutido.
Network: um proxy de debug que decifra HTTPS, com mocks, breakpoints, limitação de banda, e decodificação de GraphQL e gRPC.
Storage: navegue pelos arquivos de um app e abra SQLite, SharedPreferences, property lists, MMKV, Realm e mais, ali mesmo.
Crashes: crashes, crashes nativos e ANRs com suas stacks, legíveis quando você fornece o mapping.txt do R8, o source map ou o dSYM.
Sessions: grave uma execução inteira (logs, requisições, crashes, vídeo da tela, toques) em um único arquivo que você pode abrir depois, comparar ou coletar no CI.

Por que Rust, e por que sem agente no dispositivo

O EmuLabZip não injeta nada no seu app. Ele usa as interfaces públicas de cada plataforma: no Android, tem um cliente async próprio para o protocolo host do ADB (sem precisar chamar o adb a cada operação), e no iOS controla o xcrun simctl. O código de Android e o de Apple ficam em crates separados, atrás de uma única trait Backend, então o app desktop e a CLI usam exatamente o mesmo código.

Isso também significa que ele continua funcionando quando o Xcode ou o Android Studio atualizam, porque depende de interfaces que eles precisam manter.

Os mesmos dados no terminal

Tudo o que o app mostra também é um comando. Inicie um dispositivo e rode:

emulabzip devices
emulabzip logs
emulabzip mem com.example.app
emulabzip net --har capture.har
emulabzip crashes --app com.example.app

Cada comando imprime tabelas para pessoas e --json para scripts. O mesmo motor roda no CI: emulabzip ci grava uma sessão em volta do seu comando de teste e sai com o mesmo código de saída dele, então o pipeline se comporta como antes e você ganha um arquivo para abrir quando algo falha. Vou escrever sobre isso em um próximo post.

E conversa com assistentes de IA

O EmuLabZip inclui um servidor MCP (emulabzip mcp). Conecte o Claude, o Cursor ou o VS Code e o assistente consegue ler seus logs e crashes, acompanhar o tráfego ao vivo, controlar a tela e gravar uma sessão. Ele não consegue apagar nem reescrever nada, a menos que você inicie o servidor com --allow-writes, e aí cada alteração pede sua confirmação antes. Também vai ter um post sobre isso.

Experimente

O app desktop tem instaladores para macOS, Windows e Linux. A ferramenta de linha de comando se instala com o Cargo:

cargo install --git https://github.com/LuisPeixoto/EmuLabZip emulabzip-cli

Depois inicie um emulador ou simulador e rode emulabzip devices.

Site e documentação: emulabzip.luispeixoto.dev
Guia de primeiros passos: emulabzip.luispeixoto.dev/pt/docs/getting-started/
Código-fonte e releases (MIT): github.com/LuisPeixoto/EmuLabZip

Se algo quebrar ou estiver faltando, me avise em uma issue. É um projeto de uma pessoa só e o roadmap segue o que as pessoas precisam.

Também em inglês: I built an open-source debugging lab for Android emulators and iOS simulators

I built an open-source debugging lab for Android emulators and iOS simulators

Luis Peixoto — Sun, 15 Nov 2026 14:02:43 +0000

When I debug a mobile app I end up with six tools open: Logcat, the Instruments window, Android Studio's profilers, a proxy like Charles, a terminal full of adb shell and xcrun simctl, and a text editor to read some database I pulled off the device. Every one of them knows a slice of what the emulator knows, and none of them talk to each other.

So I built EmuLabZip: one open-source app that connects to your running Android emulators and iOS simulators and brings all of that into one window. It is written in Rust, ships as a desktop app (Tauri + Svelte) and as a command line tool, and nothing gets installed on the device.

What it does

You start an emulator or boot a simulator, and it shows up. There is no setup on the device and nothing to add to your app. From there:

Logs from logcat and the iOS unified log in one table that stays smooth at thousands of lines per second, with level, tag, text, regex and per-app filters.
Performance and memory: CPU, memory, frame rate, janky frames and battery for the app you pick, memory snapshots you can diff by category, and Android heap dumps with a built-in leak finder.
Network: a debugging proxy that decrypts HTTPS, with mocks, breakpoints, throttling, GraphQL and gRPC decoding.
Storage: browse an app's files and open SQLite, SharedPreferences, property lists, MMKV, Realm and more in place.
Crashes: crashes, native crashes and ANRs with their stacks, readable when you give it your R8 mapping.txt, source map or dSYM.
Sessions: record a whole run (logs, requests, crashes, screen video, touches) into one file you can open later, compare, or collect from CI.

Why Rust, and why no agent on the device

EmuLabZip does not inject anything into your app. It speaks the public interfaces of each platform: for Android it has its own async client for the ADB host protocol (no need to shell out to adb for every call), and for iOS it drives xcrun simctl. The Android and Apple code lives in separate crates behind one Backend trait, so the desktop app and the CLI use exactly the same code.

That also means it keeps working when Xcode or Android Studio update, because it depends on interfaces they have to keep.

The same data in a terminal

Everything the app shows is also a command. Start a device, then:

emulabzip devices
emulabzip logs
emulabzip mem com.example.app
emulabzip net --har capture.har
emulabzip crashes --app com.example.app

Each command prints tables for people and --json for scripts. The same engine runs in CI: emulabzip ci records a session around your test command and exits with its exit code, so a pipeline behaves as before and you get a file to open when something fails. I will write about that in a later post.

And it talks to AI assistants

EmuLabZip includes an MCP server (emulabzip mcp). Connect Claude, Cursor or VS Code and the assistant can read your logs and crashes, follow the traffic live, drive the screen and record a session. It cannot wipe or rewrite anything unless you start the server with --allow-writes, and then each change asks you first. There is a post about that too.

Try it

The desktop app has installers for macOS, Windows and Linux. The command line tool installs with Cargo:

cargo install --git https://github.com/LuisPeixoto/EmuLabZip emulabzip-cli

Then start an emulator or simulator and run emulabzip devices.

Website and documentation: emulabzip.luispeixoto.dev
Getting started guide: emulabzip.luispeixoto.dev/docs/getting-started/
Source code and releases (MIT): github.com/LuisPeixoto/EmuLabZip

If something breaks or is missing, tell me in an issue. It is a one-person project and the roadmap follows what people need.

Also in Portuguese: Criei um laboratório de debug open source para emuladores Android e simuladores iOS

Debug HTTPS traffic with a free, open-source proxy (ProxyZip)

Luis Peixoto — Wed, 21 Oct 2026 14:13:04 +0000

Your app calls an API, something comes back wrong, and the only thing you can see is a spinner. The request is encrypted, the logs say nothing useful, and you end up guessing.

A debugging proxy fixes that: it sits between your app and the server, decrypts the HTTPS on your own machine and shows you every request and response. I built ProxyZip, a free, open-source HTTP and HTTPS debugging proxy, and this post walks through what it does using a small example.

TL;DR

Capture and inspect HTTPS traffic from any app on macOS, Windows and Linux
Pause a request, edit it and send it on
Mock an API that does not exist yet, or validate real traffic against an OpenAPI file
Turn captured requests into tests and run them in CI
MIT licensed, written in Rust, no account and no telemetry

What is ProxyZip?

ProxyZip is an HTTP and HTTPS debugging proxy with a desktop app and a command line. The engine is Rust (tokio, hyper, rustls); the app is Tauri and Svelte. The app and the proxyzip command run the same engine, so what you learn in one works in the other.

The example below uses a fictional shop API at api.shopwave.dev.

Install it

# macOS
brew install --cask luispeixoto/proxyzip/proxyzip

# Windows
scoop bucket add proxyzip https://github.com/LuisPeixoto/scoop-proxyzip

Installers for macOS, Windows and Linux (.dmg, .msi, .exe, .AppImage, .deb, .rpm) are on the releases page. The command line alone installs with cargo install --git https://github.com/LuisPeixoto/ProxyZip proxyzip-cli.

Inspect HTTPS traffic

HTTPS needs one extra step. ProxyZip creates a local certificate authority on your machine; once you trust it, the proxy can show you what your apps send. The private key never leaves your disk, and you can exclude any host from decryption.

proxyzip ca install
eval "$(proxyzip env)"
proxyzip start --port 19191

proxyzip env points the current terminal at the proxy and makes curl, Node.js, Python, Go, Git, Cargo and others trust the certificate. Every finished request prints as it happens:

200 GET     https://api.shopwave.dev/v1/products 469B 1ms [mock]
200 GET     https://api.shopwave.dev/v1/products/sku_1042 142B 70ms [mock]

In the app you get the same requests as a list, with headers, cookies, timing, TLS details and the body as a JSON tree. Use jq filters on a body, or compare two requests side by side.

Binary protocols are covered too. gRPC, gRPC-Web and plain Protobuf messages are decoded even without the .proto files, which makes gRPC debugging a lot less painful.

Change traffic instead of only reading it

Right-click a request to set a breakpoint: the next matching request stops before it leaves, and you can edit the method, URL, headers or body. Map Local answers with a file from your disk, Map Remote sends the request to another host, and rewrite rules change headers, bodies and status codes. You can also throttle to a slow network or block a host to see how your app copes.

Mock an API that does not exist yet

When the backend is not ready, or has to fail in a specific way, a mock server answers for it: routes with status codes, headers, bodies and delays, plus a small template language. Right-click a captured response and choose Create a mock from this response, or import an OpenAPI 3 file.

proxyzip mock petstore.yaml --port 4010 --delay 200
proxyzip validate petstore.yaml capture.pzsession

proxyzip validate checks captured traffic against the specification and exits with 1 if anything does not conform, so it works as a CI step.

Turn requests into API tests

Select the requests of a flow, right-click and choose Add to a suite. A suite is a single .pzsuite file with checks on status and body, variables and environments, and values passed between steps with jq. It belongs in version control, and it runs headless:

proxyzip run checkout.pzsuite --env staging --junit report.xml

The command exits with 1 when a request fails and writes a JUnit report that CI systems can display. Postman collections run the same way.

Phones, emulators and AI assistants

To debug an iPhone or Android device, point its Wi-Fi proxy at your computer and open http://proxyzip.cert to install the certificate. The Devices window shows the address and a QR code, and has one-click setup for simulators and emulators. See the mobile debugging guide.

ProxyZip also has a built-in Model Context Protocol server, so assistants such as Claude Code, Cursor and VS Code can read your captured traffic. It is off by default, listens on localhost only, needs an access token and redacts secrets unless you ask otherwise. The MCP guide has the details.

Private and open

There is no account to create and nothing phones home; the only extra request is an optional, signed update check. The code is MIT licensed, so you can read it, fork it and ship it. Use it only on traffic you are allowed to inspect.

Try it

Website and docs: luispeixoto.github.io/ProxyZip
Source: github.com/LuisPeixoto/ProxyZip
Downloads: latest release

If it saves you an afternoon of guessing, a star on GitHub helps other developers find it, and issues and pull requests are welcome. What would you want from a debugging proxy that the tools you use today do not do?