Alice: an HTTP inspector that lives inside a Flutter app

Catching traffic on the device, not on a proxy

Alice is described in the README as an advanced HTTP Inspector tool for Flutter that helps you debug network requests, catching and storing HTTP requests and responses so you can view detailed network logs inside the app through a simple interface. The point of the approach is the word without. Whether you are hunting down a broken API payload, checking headers or watching timings, the README says Alice gives you the details without requiring a proxy or external desktop tools. That matters on mobile, where setting up a proxy means reconfiguring the device, and on a real handset where the network path you want to inspect is the one the phone actually took. The project says it is inspired by Chuck and Chucker, both of which are proxy-based approaches for other platforms, and it ports that idea into the Flutter ecosystem as an in-process library. The audience is a Flutter developer who debugs a live app on a device, and the package is published on pub.dev as alice.

Why the packages are split the way they are

The Architecture section of the README explains the multi-package layout directly. You install the core alice package and the one adapter you need, for example alice_dio, and the project says it strictly avoids enforcing unnecessary dependencies on your project. The reason given is that many similar inspector packages force you to pull in a massive dependency tree, Dio, HTTP, Chopper and GraphQL together, even when the app only uses one of them, and the README calls that a bad pattern because it bloats app size, slows down build times and causes version conflicts. The published packages follow the same split, with alice_dio, alice_chopper, alice_http, alice_http_client, alice_graphql_client and alice_objectbox each carrying its own badge in the README, and the repository layout matches, with a packages/ directory and an examples/ folder containing one example per integration, including alice_dio, alice_chopper, alice_http, alice_http_client, alice_graphql_client, alice_objectbox and alice_retrofit. If your app uses Retrofit, the example folder names it even though the README's compatibility list does not.

Adding the dependency and creating the inspector

Setup is a pubspec entry and a constructor call. The README has you add the core package and any client plugins you need to your pubspec.yaml.

dependencies:
  alice: ^1.10.0
  # Add plugins as needed, e.g.:
  # alice_dio: ^1.3.1

Then you create an instance, which the README says you should generally keep as a singleton or provide through dependency injection.

import 'package:alice/alice.dart';

Alice alice = Alice(
  showNotification: true,
  showInspectorOnShake: true,
);

Those two flags are the ones shown in the example. showNotification turns on the system notifications on HTTP calls, and showInspectorOnShake enables the shake gesture that opens the inspector instantly. A singleton matters more here than in most libraries, because Alice collects traffic for the whole app rather than for one screen, and a per-widget instance would only see the requests made through that instance's client.

The navigator key and the interceptor, in that order

Alice opens its own screens, so it needs a way to push routes, and that is the navigator key you hand to your app widget. The README passes Alice's navigator key to the MaterialApp or CupertinoApp so she can open the UI.

MaterialApp(
  navigatorKey: alice.getNavigatorKey(),
  home: Scaffold(...),
)

Then the client is attached. Alice works by attaching an interceptor to your HTTP client, and the README's example uses Dio.

import 'package:dio/dio.dart';
import 'package:alice_dio/alice_dio_adapter.dart';

Dio dio = Dio();
dio.interceptors.add(AliceDioAdapter().getInterceptor(alice));

// Now make requests! Alice will automatically record them.
dio.get("https://jsonplaceholder.typicode.com/posts");

The interceptor is the whole integration point. Everything else in the library is downstream of the fact that requests and responses pass through it, which is also why the adapter packages exist as separate ones: each supported client has its own interceptor API, and the adapter wraps it into something uniform. The README points at the full documentation for the Chopper, standard http and GraphQL attachments.

What the inspector shows once traffic is captured

The screenshots listed in the README are a good inventory of the feature set. There is a calls list, a request details view, an interactive tree-based JSON viewer for request and response bodies, a Gantt chart timeline to inspect staggered HTTP calls, a statistics dashboard with bandwidth, success rate, call counts and ratio bars, an advanced search screen with syntax filters, a request replay screen and a dark mode. The key features section adds the details behind those screens: detailed logs for every call including headers, body, query parameters and timestamps, programmatic call tagging such as alice.tag(tag: 'login-flow'), automatic N+1 duplicate request detection, and Flutter and Android native log integration. Two of those are worth singling out. The tagging call is programmatic, so you can mark a request in the code path it belongs to and find it later, and the N+1 detection turns the classic silent performance problem into something visible in the list.

Replay, export and persistent storage

Three capabilities move Alice beyond passive logging. Request replay lets you resend an HTTP call directly from the inspector, which is how you test a fixed payload without re-triggering the screen that produced it. Export and save writes HTTP calls to a file, in TXT or in HAR format, and the HAR option is the one that matters for sharing, since it is a format other tools can open rather than a log a colleague has to read. Persistent storage support comes via ObjectBox, and there is a separate alice_objectbox package for it, which is consistent with the adapter philosophy of keeping storage optional. The combination of HAR export plus request replay is what turns the inspector from a debugging aid into something you can attach to a bug report and reproduce from.

Where an in-app inspector is the wrong choice

There are cases where Alice is the wrong instrument, and the first is a production build. An inspector that records every request and response of your application, with a JSON viewer and a search over the payloads, is a data retention surface, and the README does not describe any redaction of headers such as Authorization. If you ship the inspector to end users, you should make sure it is compiled out or gated behind a build flag, because a customer support attachment of a HAR file is a good way to leak a bearer token. The second case is network-level analysis, where a proxy sits between the app and the server and can see traffic from libraries you did not instrument, including those inside a WebView or a third party SDK. Alice only sees what passes through the interceptor on the client you attached it to. The third is a non-Flutter target, since the package is Flutter and Dart only, and the same applies to any native Android or iOS client in the same product.

Editorial conclusion

Alice fits a Flutter team that debugs network traffic on device, where a desktop proxy is impractical, and that wants to share a HAR file from a bug report rather than a screenshot of a proxy window. It does not fit a team that wants one dependency to cover every HTTP client it uses, because each client needs its own adapter package, and it does not fit a production build where you would rather not ship an inspector at all. Before you adopt it, add the inspector behind a debug-only flag and check the version you pin, since the README still shows alice: ^1.10.0 in pubspec.yaml while the latest published release is 1.11.0 from 2026-09-29, and read the export section before promising HAR output to a colleague.

Frequently asked questions

Official sources

1. Issues
2. jhomlala/alice on GitHub
3. README
4. Releases