Flutter: Droido 1.2.0 es un inspector de red solo en debug con cero impacto en release

Droido 1.2.0 se entregó hoy (8 de febrero de 2026) como un inspector de red solo en debug para Flutter 3.x. Afirma soporte para Dio, el paquete http, y clientes estilo Retrofit, además de una notificación persistente de debug y una UI moderna.

La parte que vale la pena escribir es la restricción: hacer la depuración más fácil sin pagarlo en los builds de release. Si estás distribuyendo apps Flutter a escala, “es solo una herramienta de dev” no es excusa para dependencias accidentales en producción, inicialización extra, o binarios más grandes.

El único contrato aceptable: el tooling de debug debe desaparecer en release

En Flutter, el patrón más limpio es inicializar código solo de dev dentro de un bloque assert. assert se elimina en modo release, así que la ruta de código (y usualmente los imports transitivos) se vuelve irrelevante para el build de release.

Aquí hay una plantilla mínima que puedes usar en cualquier app de Flutter 3.x, sin importar qué inspector enchufas:

import 'package:dio/dio.dart';

// Keep this in a separate file if you want even stronger separation.
void _enableDebugNetworkInspector(Dio dio) {
  // Add your debug-only interceptors or inspector initialization here.
  // Example (generic):
  // dio.interceptors.add(LogInterceptor(requestBody: true, responseBody: true));
  //
  // For Droido specifically, replace this comment with the package's setup call.
}

Dio createDio() {
  final dio = Dio();

  assert(() {
    _enableDebugNetworkInspector(dio);
    return true;
  }());

  return dio;
}

Esto te compra tres cosas:

• Sin efectos secundarios en producción: el inspector no se inicializa en release.
• Menos riesgo durante refactorizaciones: es difícil mantener accidentalmente un hook solo de dev habilitado.
• Un lugar predecible para conectar clientes: puedes aplicar esto a Dio, http.Client, o un wrapper Retrofit generado, mientras tú seas dueño de la factory.

Qué verificaría antes de adoptar Droido

La promesa “cero impacto en builds de release” es lo suficientemente específica para que puedas validarla:

• Salida del build: compara el tamaño de flutter build apk --release y el árbol de dependencias antes y después.
• Runtime: confirma que el código del inspector nunca se referencia cuando kReleaseMode es true (el patrón assert fuerza esto).
• Puntos de intercepción: verifica que se engancha donde tu app realmente envía tráfico (Dio vs http vs clientes generados).

Si Droido se sostiene, este es el tipo de herramienta que mejora la depuración del día a día sin convertirse en un impuesto de mantenimiento a largo plazo.

Fuentes:

• Droido en pub.dev
• Repositorio de Droido
• Hilo de Reddit