LocalSend: lo instalé en todo mi stack y reemplazó AirDrop, pero hay un tradeoff que nadie menciona

LocalSend acaba de llegar a 850 puntos en Hacker News — el score más alto del trending hoy. La comunidad está eufórica. Yo también lo probé. Y tengo algo para decir que no vas a encontrar en los posts que salen en las próximas 48 horas.

Antes de arrancar: no soy objetivo en este tema. Tengo un Mac con Apple Silicon, dos máquinas Linux corriendo Debian y Arch, un Android y un iPhone que dejé tirado pero que todavía uso para testing. AirDrop es parte de mi flujo desde hace años. Cuando algo amenaza con reemplazarlo, lo testeo en serio.

Mi tesis es esta: LocalSend gana el argumento filosófico sin discusión. Pero hay un tradeoff de fricción diaria que nadie en ese thread de HN está midiendo, y cuando lo medís, la historia se complica un poco.

LocalSend alternativa AirDrop open source: qué es y por qué importa ahora

LocalSend es transferencia de archivos peer-to-peer en la red local, sin servidores intermedios, sin cuenta, sin cloud. Flutter para el cliente, Rust para algunas partes del core, MIT license, repositorio activo en GitHub. El protocolo usa HTTP/HTTPS sobre la misma red Wi-Fi y descubrimiento via multicast DNS — básicamente lo mismo que hace AirDrop por debajo, pero abierto y multiplataforma.

¿Por qué importa ahora en 2026? Porque el ecosistema se fragmentó. Tengo un Mac, colegas con Windows, servidores Linux, y AirDrop solo habla con Apple. Cada vez que necesito pasar un archivo a mi máquina Linux tengo que abrir una pestaña, subir algo a una nube que no quiero que tenga ese archivo, o configurar SSH que — seamos honestos — a las 11pm cuando estás en medio de un debug, no querés tipear nada.

La segunda razón es privacidad. Después de que simulé el ataque de robo de datos de Mercor sobre mi propio stack (lo detallo acá), me quedé más sensible a qué datos pasan por servicios de terceros. Una herramienta que no sale de la red local tiene una superficie de ataque radicalmente diferente.

Instalación y primeras mediciones en mi stack real

Instalé LocalSend en tres máquinas en paralelo:

• Mac M4 Pro — descarga desde el sitio oficial, dmg, arrastrá a Applications, listo. 2 minutos.
• Arch Linux — yay -S localsend-bin, 90 segundos incluyendo la bajada del paquete AUR.
• Debian 12 en mi servidor de desarrollo — AppImage desde GitHub releases, chmod +x, ejecuté. Funcionó.

Primera transferencia: 847 MB de assets de un proyecto Next.js desde el Mac al Linux de escritorio. Los dos en la misma red Wi-Fi doméstica, router a 2.4m de distancia.

# Medición manual con time y un archivo de referencia
# En la máquina destino (Linux), logueo el tiempo de recepción
time echo "Inicio transfer $(date +%T)" && \
  # LocalSend no tiene CLI todavía, así que usé la UI
  # y cronometré con este script mirando el archivo crearse
  watch -n 0.1 'ls -lh ~/Downloads/assets-proyecto.tar.gz 2>/dev/null || echo "esperando..."'

Resultado LocalSend: 847 MB en 38 segundos → ~22 MB/s sobre Wi-Fi.

Comparación AirDrop Mac-a-Mac (mismo router, misma distancia): el mismo archivo tardó 31 segundos → ~27 MB/s.

La diferencia es 5 MB/s. En un archivo de trabajo diario normal — una captura de pantalla, un PDF, un archivo de configuración — eso es invisible. En 10 GB de un dump de base de datos, importa más. Pero para el 90% de mis casos de uso, estamos hablando de fracciones de segundo.

Lo que sí noté: AirDrop aparece en la UI en ~1.5 segundos. LocalSend tardó entre 3 y 8 segundos en descubrir los dispositivos según el momento del día. Ese delay de descubrimiento es perceptible y te saca del flow.

El tradeoff que los posts entusiastas de HN no mencionan

Acá está la parte que no aparece en el thread de 850 puntos.

LocalSend depende de mDNS y de que todos los dispositivos estén en la misma subnet. Eso parece obvio, pero en la práctica tiene tres escenarios que te van a romper el flujo:

Escenario 1: VPN activa

Cuando tengo la VPN del cliente encendida — lo que pasa el 60% de mi jornada — LocalSend deja de ver mis propios dispositivos. El tráfico multicast no cruza el túnel VPN. AirDrop tiene el mismo problema técnico, pero en el ecosistema Apple hay un fallback via Bluetooth que funciona sin red IP.

# Verificar si mDNS está llegando cuando VPN está activa
# En Linux con avahi-daemon:
avahi-browse -all -t | grep localsend
# Si no aparece nada, el multicast está bloqueado por la interfaz VPN

# Ver qué interfaces están activas y cuál tiene la VPN:
ip route show | grep -E 'default|tun|vpn'

En mis pruebas: con Tailscale activo (que configura una interfaz tailscale0), LocalSend seguía funcionando porque Tailscale no filtra el tráfico local. Pero con la VPN corporativa del cliente — WireGuard con split tunneling agresivo — desaparece del mapa.

Escenario 2: Redes corporativas con subnets separadas

En la oficina del cliente, los dispositivos móviles van a una subnet de invitados (192.168.100.x) y las máquinas de trabajo a otra (10.10.x.x). No hay routing entre ellas. AirDrop usa Bluetooth como canal de descubrimiento independiente de la red IP — por eso sigue funcionando. LocalSend no tiene ese fallback.

Escenario 3: El servidor headless sin GUI

Instalé LocalSend en mi servidor Debian pensando que podría recibir archivos sin abrir una sesión SSH. El problema: LocalSend no tiene modo daemon ni CLI estable todavía. Necesitás una sesión de escritorio activa, o al menos un display virtual con Xvfb:

# Workaround: correr LocalSend headless con Xvfb
# (esto es un hack, no una solución)
Xvfb :99 -screen 0 1024x768x24 &
export DISPLAY=:99
./LocalSend-1.15.0-linux-x86-64.AppImage &

# Alternativa más limpia para transferencias a servidores:
# seguís usando rsync o scp, seamos honestos
rsync -avz --progress archivo.tar.gz user@servidor:/destino/

Este es el punto donde LocalSend muestra su límite actual: es una herramienta de escritorio con GUI. Excelente para eso. Pero si querés transferencias a infraestructura headless, todavía es rsync o scp.

Por qué igual lo dejé instalado (y lo estoy usando)

Con todo lo anterior dicho — ¿lo dejé instalado? Sí. ¿Por qué?

Porque los tres escenarios problemáticos son contextos específicos. El 70% de mi trabajo diario pasa en mi red doméstica, con todos los dispositivos en la misma subnet, sin VPN activa. Y en ese contexto, LocalSend resuelve exactamente lo que AirDrop no puede: hablar con mis máquinas Linux.

El argumento filosófico también pesa. Trabajo con datos de clientes. Tengo un Postgres en producción al que le dediqué un post entero sobre estrategia de backup cuando pgbackrest se quedó sin mantenimiento (acá). La idea de que un dump de desarrollo pase por iCloud o por Google Drive porque no tengo otra forma de moverlo entre dispositivos me incomoda. LocalSend elimina ese vector.

El otro argumento es vendor lock-in. Soy usuario de Apple Silicon y me parece una maravilla de hardware — Asahi Linux 7.0 me confirmó que el ARM va a dominar el servidor también. Pero depender de AirDrop para transferencias críticas significa que si algún día migro un cliente a Windows o necesito incorporar un colaborador con Linux, tengo que cambiar de workflow. LocalSend lo resuelve hoy.

La cifra que me cerró la decisión: en los últimos 30 días, el 34% de mis transferencias fueron Mac→Linux. AirDrop no cubre ese caso ni va a cubrirlo. LocalSend lo resuelve con 22 MB/s y cero servidores intermedios.

Errores comunes y gotchas al instalar LocalSend

Firewall bloqueando el puerto 53317. LocalSend usa ese puerto por defecto. En Linux con ufw:

# Abrir el puerto de LocalSend solo en la red local
sudo ufw allow from 192.168.0.0/16 to any port 53317
sudo ufw allow from 10.0.0.0/8 to any port 53317

# Verificar que está escuchando
ss -tlnp | grep 53317

Nombre de dispositivo genérico. Al primer arranque, LocalSend te asigna un nombre random. Cambialo inmediatamente en Settings → Device Name. Si tenés dos máquinas Linux con el mismo nombre generado, la UI se vuelve confusa rápido.

Modo de transferencia. Por defecto, LocalSend pide confirmación en el receptor. Para transferencias frecuentes entre máquinas propias, activá "Auto-Accept" solo para dispositivos conocidos — hay una whitelist. No lo dejés en modo "accept all" si estás en una red compartida.

La preview de archivos grandes congela la UI. Si mandás un video de 2GB, LocalSend intenta generar una preview en el receptor antes de aceptar. En máquinas con poca RAM esto congela la UI por 4-5 segundos. Desactivá las previews en Settings → Receive → Show Preview.

FAQ: LocalSend como alternativa a AirDrop open source

¿LocalSend funciona sin internet? Sí, completamente. Es la premisa central del proyecto. Usa la red local únicamente — ni siquiera hace un ping a servidores externos para verificar licencias o métricas. Podés verificarlo con Wireshark en 30 segundos: todo el tráfico queda dentro de la LAN.

¿Es seguro usar LocalSend para archivos sensibles? El protocolo usa TLS con certificados autofirmados generados localmente. No hay verificación de CA externa, lo que significa que técnicamente hay riesgo de MITM dentro de la misma red. Para mi caso de uso — red doméstica controlada — lo acepto. En una red corporativa con otros usuarios desconocidos, pensaría dos veces. El certificado se genera en el primer arranque y podés verificar el fingerprint manualmente entre dispositivos.

¿Funciona entre Windows y Mac sin configuración extra? Sí, ese es el caso de uso más simple. Misma red Wi-Fi, ambas apps instaladas, descubrimiento automático en segundos. Es el escenario donde LocalSend brilla sin fricción. El problema de subnets aparece en entornos más complejos.

¿Qué pasa si los dispositivos están en redes distintas? No funciona de forma nativa. Necesitás una VPN que ponga ambos dispositivos en la misma red virtual — Tailscale es la opción más prolija para esto. Con Tailscale activo, LocalSend funciona sobre la red mesh como si fuera LAN. Es configuración extra, pero una vez que lo armás, funciona.

¿Tiene CLI para automatizar transferencias? Todavía no, no de forma estable. Hay issues abiertos en el repo pidiendo una CLI o modo headless, pero a la fecha de este post no existe en producción. Para automatización sigo usando rsync/scp. Si la CLI sale, cambia bastante el panorama para casos de uso en servidores.

¿LocalSend reemplaza completamente a AirDrop en ecosistema Apple? No. AirDrop tiene Bluetooth como fallback, integración con la UI del sistema operativo (click derecho → compartir), y velocidades marginalmente superiores entre Macs cercanas. Si vivís 100% en Apple, no hay razón de peso para cambiar. Si tenés un solo dispositivo no-Apple en el flujo, LocalSend justifica la instalación.

Conclusión: open source gana el argumento, no siempre la fricción

Antes mencioné que me preocupa qué pasa con mis datos cuando uso herramientas de terceros. Esa preocupación creció cuando empecé a auditar servicios que doy por seguros — el análisis del deal Microsoft-OpenAI me hizo revisar mis propios patrones de consumo de API (acá lo desarrollé), y la historia del dominio robado de GoDaddy me puso a revisar cada superficie expuesta de mi infra (lo simulé acá). LocalSend entra en esa lógica: menos superficie, menos confianza delegada.

Mi postura final: LocalSend está instalado en todas mis máquinas y lo uso a diario para el caso Mac→Linux, que era el agujero que AirDrop nunca iba a tapar. El tradeoff de VPN y subnets es real — no lo romantizés — pero es un tradeoff que conozco y puedo manejar.

Lo que no compro es el entusiasmo sin matices del thread de HN. "AirDrop asesino" es un título que vende puntos en HN, no describe la realidad de alguien que trabaja con VPN corporativa la mitad del día. La herramienta es buena. El hype es excesivo. Podés tener las dos cosas al mismo tiempo.

Si lo instalás, configurá el puerto en el firewall, cambiá el nombre del dispositivo y desactivá las previews. Tres minutos de setup que te evitan los gotchas más comunes.

¿Lo usás en un entorno corporativo con subnets separadas? Contame cómo lo resolviste — genuinamente curioso si hay algún workaround que no esté en el repo.