Casi todas las herramientas de escritorio para desarrollo hoy son apps web con disfraz. Un motor de navegador empaquetado, un servicio remoto haciendo el trabajo real y un icono de Mac encima para que parezca que pertenece. Se lanza, funciona, y durante un tiempo no notas lo que esa elección te costó.
Luego lo notas. Se siente ajena de formas pequeñas que no sabes nombrar del todo. Pierde frames en una máquina que nunca debería perder uno. Y te pide entregar tu código fuente a una descarga por la que no puedes responder de verdad. Lo nativo en macOS no es nostalgia ni purismo. Para una herramienta que sostiene tu código y corre en tu máquina todo el día, es una decisión sobre tres cosas: integración, rendimiento y confianza. Esos tres son el caso entero.
Integración: hablar el idioma de la máquina en vez de reinventarlo
El sistema operativo ya resolvió una lista larga de problemas difíciles. Dónde viven los secretos. Cómo se concede y se revoca el acceso a ficheros. Cómo se comportan las ventanas, las notificaciones, el compartir y el trabajo en segundo plano. Una app nativa usa esas soluciones. Guarda las credenciales en el Keychain. Pide permisos de fichero como los pide el sistema, para que los puedas ver y revocar. Se comporta como cualquier otra app de verdad en tu Mac porque usa la misma maquinaria debajo.
Una app web en una carcasa reinventa todo eso dentro de su propio sandbox, normalmente peor. Su idea de dónde van los secretos. Su modelo de permisos que el sistema operativo no puede inspeccionar. Sus medias versiones de cosas que macOS hace bien. Cada reinvención es un sitio donde el comportamiento se aleja de lo que esperas y un sitio donde tus datos quedan donde las protecciones del propio sistema no llegan. La integración no es pulido. Es si la herramienta participa del modelo de seguridad y permisos del que ya dependes, o se sale de él sin hacer ruido.
Rendimiento: un día entero de trabajo no es un benchmark
El rendimiento en una herramienta que tienes abierta todo el día no va de ganar un benchmark. Va del impuesto acumulado de cada interacción, cada render, cada operación en segundo plano, pagado a lo largo de horas, con batería.
Una app nativa compilada para Apple Silicon corre sobre el metal. Usa la memoria y los núcleos como el sistema pretende. Un motor de navegador empaquetado carga el peso de una pila de renderizado entera que no necesitaba, en un runtime pensado para mostrar documentos, no para ser la carcasa de una herramienta que orquesta agentes y mantiene una vista viva de tu trabajo. En una demo rápida no notarás la diferencia. En la cuarta hora, con varias sesiones corriendo, la notas en los ventiladores, en la batería, en el pequeño lag de cada acción que una app nativa simplemente no tiene.
Para una fábrica local de software que se supone que corre en local, esto se acumula. Toda la premisa es que el trabajo real pasa en tu máquina. Si la carcasa alrededor de ese trabajo pesa más que el trabajo, has gastado tu hardware en el envoltorio.
Hay también un coste de segundo orden. Una carcasa más pesada deja menos margen para el trabajo que de verdad te importa. Cuando varios agentes están corriendo y la máquina ya carga un motor de navegador que no necesitaba, el impuesto aparece como contención: el build que debería haber sido rápido, la sesión que da tirones mientras otra renderiza. Lo nativo devuelve ese margen al trabajo en vez de al marco que lo rodea.
Confianza: la app tiene que demostrar de dónde viene
Esta es la que más importa en una herramienta que apuntas a tu código fuente, y es la que el modelo de web-en-una-caja lleva peor.
macOS no deja correr una app nativa solo porque la descargaste. De una app de Mac distribuida se espera que esté firmada con una identidad de desarrollador verificada y notarizada por Apple, lo que significa que Apple la ha revisado en busca de malware y el sistema puede confirmar que no se ha alterado desde entonces. Grapa esa notarización a la app y la máquina puede verificarlo todo antes del primer arranque, sin conexión. Esa es una cadena de procedencia que puedes inspeccionar de verdad. Sabes quién la firmó. Sabes que está inalterada. Sabes que pasó el chequeo de Apple.
Una herramienta que en realidad es una web dentro de un marco no carga ese mismo peso, porque la parte que hace el trabajo real no es lo que instalaste. Es un servicio en otro sitio, y lo que estás confiando es una conexión y una política de privacidad, no un artefacto que el sistema pueda verificar. Para la mayoría del software eso vale. Para el software al que estás a punto de darle tu código privado, “el sistema verificó de dónde viene esto y que nadie lo tocó” no es un formalismo. Es la diferencia entre una decisión de confianza que puedes razonar y otra que tomas por fe.
Nativo y local-first son el mismo compromiso
Fíjate en que los tres argumentos apuntan a lo mismo. Integración significa usar las protecciones de verdad de la máquina. Rendimiento significa correr sobre el hardware de verdad de la máquina. Confianza significa que la máquina puede verificar lo que ejecuta. Los tres son afirmaciones de que la máquina es donde el trabajo vive de verdad.
Por eso lo nativo es la forma coherente del desarrollo con IA local-first. Si toda la promesa de una herramienta es que tu código y tus datos se quedan en tu ordenador, entonces la herramienta que los sostiene debería ser un ciudadano de verdad de ese ordenador, no una carcasa fina alrededor de un servicio corriendo en un sitio que no ves. Un producto local-first entregado como un navegador apuntando a un backend remoto se contradice a sí mismo. La app nativa, firmada e integrada y corriendo sobre tu silicio, es la promesa cumplida.
Voy a ser justo con el otro lado, porque es un trade real y no un espantapájaros. La tecnología web multiplataforma es más barata de construir, más rápida de sacar, y llega a Windows y Linux desde un solo código. Para muchos productos esa es justo la decisión correcta, y no voy a fingir lo contrario. Pero es un trade, y lo que cedes es precisamente integración, rendimiento y confianza verificable. Para una herramienta cuya razón entera de existir es que puedas fiarte de ella con código local, esas no son las partes que ceder. Son el producto.
Dónde encaja PaellaDoc
PaellaDoc es una aplicación nativa de macOS, construida para Apple Silicon, firmada, notarizada y grapada. Eso no es una línea de la ficha técnica. Es la misma decisión que todo lo demás en ella. Tu código, tu memoria de producto, tus decisiones y tu evidencia se quedan en tu máquina, así que la app que los sostiene es una app de verdad en esa máquina, usando las protecciones del sistema, corriendo sobre su propio hardware, verificable antes de arrancar.
Los motores que llama pueden ser remotos, si traes tus claves, o totalmente locales a través de Ollama. Pero la fábrica en sí, lo que sostiene el contexto duradero, es nativa y local por diseño, porque esa es la única versión de la promesa que se cumple de verdad.
La próxima vez que una herramienta de desarrollo te pida tu código, vale la pena preguntar qué es en realidad. Una app de verdad que tu máquina puede verificar, o un navegador apuntando al servidor de otro con un icono de Mac encima.
Preguntas frecuentes
¿Por qué siguen importando las apps nativas de macOS en herramientas de desarrollo?
Para una herramienta que sostiene tu código y corre todo el día, lo nativo se reduce a tres cosas: integración, rendimiento y confianza. Usa las protecciones de verdad de la máquina —Keychain para los secretos, el modelo de permisos del sistema—, corre sobre Apple Silicon en vez de arrastrar un motor de navegador empaquetado, y puede verificarse antes de arrancar. Una app web disfrazada de escritorio reinventa cada una de esas, normalmente peor.
¿Qué significa que una app de Mac esté firmada y notarizada?
Firmada significa que la app carga una identidad de desarrollador verificada, así que sabes quién la construyó. Notarizada significa que Apple la revisó en busca de malware y el sistema puede confirmar que no se ha alterado desde entonces. Grapa la notarización a la app y tu máquina verifica la cadena entera antes del primer arranque, sin conexión. Para software al que estás a punto de darle tu código fuente, esa procedencia es una decisión de confianza que puedes razonar en vez de tomar por fe.
¿Las herramientas Electron o web empaquetadas rinden peor?
En una demo rápida no lo notas. A lo largo de un día entero, un motor de navegador empaquetado carga el peso de una pila de renderizado que no necesitaba, en un runtime pensado para mostrar documentos. En la cuarta hora, con varias sesiones corriendo, el impuesto aparece en los ventiladores, la batería y el pequeño lag de cada acción. Una carcasa más pesada deja menos margen, así que los builds compiten con el marco en vez de con el trabajo.
¿Es seguro darle mi código fuente a una herramienta basada en web?
Es una decisión de confianza distinta. Cuando el trabajo real pasa en un servicio en otro sitio, lo que confías es una conexión y una política de privacidad, no un artefacto que el sistema pueda verificar. Una app nativa que tu máquina ha firmado, notarizado y comprobado es demostrable antes de correr. Para la mayoría del software el modelo web vale; para la herramienta que apuntas a código privado, la procedencia verificable no es un formalismo, es el producto.