Experiencia · Aplicaciones de escritorio

Aplicaciones que se instalan en el ordenador. En macOS hemos construido dos; para Windows y Linux esta página es una oferta, no un historial.

Construimos aplicaciones nativas para macOS, con el núcleo de lógica separado de la pantalla, para que la misma lógica también funcione en el teléfono. Para Windows y Linux/Ubuntu no tenemos todavía nada entregado y lo escribimos así, con las condiciones en las que aceptaríamos el trabajo. La primera pregunta sigue siendo si realmente necesitas una aplicación instalada.

Habla de un proyecto

Oferta, con condicionesLa regla es mecánica y la aplico mecánicamente. En macOS tenemos dos implementaciones propias, construidas y ejecutables: una aplicación de barra de menú con 25 archivos Swift, que reutiliza 15 archivos del núcleo de un proyecto de iPhone, y una segunda aplicación, más simple, que es un envoltorio WebKit sobre una aplicación web. Ambas tienen binario compilado en esta máquina. Pero el servicio, como se le llama, cubre tres familias de sistemas, y para dos de ellas —Windows y Linux/Ubuntu— he buscado en serio y he encontrado cero: ningún proyecto .NET o Qt propio, ningún `tauri.conf.json`, ningún Electron escrito por nosotros, ningún `.desktop`, ningún paquete deb, rpm o AppImage. Además, ninguna de las dos aplicaciones de macOS se ha empaquetado nunca en un instalador distribuible. Con solo una de tres plataformas cubierta y cero distribuciones, la página se escribe como oferta con condiciones. Cuando entreguemos la primera aplicación de Windows o de Linux, cambia el valor, no el texto.

La primera pregunta que te hacemos no es para qué sistema, sino si realmente necesitas una aplicación instalada. Merece la pena instalarla cuando necesita algo que el navegador no le da: acceso directo a sensores o periféricos, presencia permanente en la barra del sistema, trabajo sin internet, acceso a los archivos del disco sin que la persona los cargue cada vez, o ejecución en segundo plano cuando la ventana está cerrada. Si ninguna de estas cosas se requiere, un sitio que se abre desde un enlace es más barato de construir, actualizar y mantener —y te lo decimos, aunque el trabajo salga más pequeño.

En macOS tenemos dos aplicaciones construidas. La primera es una aplicación de barra de menús: 25 archivos Swift propios, más 15 archivos de núcleo tomados directamente del proyecto de iPhone del mismo producto —los mismos archivos, no una copia. Se construye con un script que llama directamente al compilador Swift, objetivo `arm64-apple-macosx14`, enlazando once marcos del sistema, entre ellos SwiftUI, AppKit, CoreMotion, Vision y UserNotifications. El binario resultante tiene 6.516.128 bytes. La segunda es mucho más simple y es honesto decirlo con precisión: tres archivos Swift, un envoltorio WebKit sobre una aplicación web, con sandbox y runtime reforzado activados, compilado de forma universal para procesadores Intel y Apple. Son dos cosas distintas y las llamamos de forma distinta.

Lo que no tenemos, dicho claramente. Windows: cero. He buscado proyectos .NET, WPF, WinForms, WinUI, archivos `.xaml`, `.appxmanifest`, `.msi`, `.wxs` —todo lo que he encontrado en el disco pertenece a una biblioteca C de terceros, vendorizada en otro proyecto, que no hemos escrito nosotros. Linux de escritorio: cero —ningún archivo `.desktop`, ningún paquete deb o AppImage construido aquí. Electron o Tauri escritos por nosotros: cero. Y, igual de importante: ninguna de las dos aplicaciones de macOS ha sido nunca empaquetada en un instalador. Existen como paquetes `.app` construidos localmente, firmados ad hoc, sin identificador de equipo.

Lo que sí transfiere la experiencia previa, y es la parte que importa para un proyecto nuevo: la disciplina de mantener el núcleo de lógica separado de la interfaz. En el proyecto de macOS, los archivos de cálculo y de políticas no importan la interfaz, así que se compilan y se ejecutan en Mac como un programa normal, sin simulador; su suite de lógica se ejecuta en unos segundos. Esa misma separación hace que portar a otro sistema sea un problema de envoltorio, no de reescritura. En eso nos basamos cuando decimos que podríamos hacer Windows o Linux —no en una experiencia que no tenemos.

Qué incluye

El trabajo, por componentes

Primero decidimos si te hace falta una aplicación instalada

Cinco criterios, verificados uno por uno: acceso a sensores o periféricos, presencia en la barra del sistema, trabajo sin internet, acceso directo a los archivos del disco, ejecución en segundo plano con la ventana cerrada. Si ninguno se aplica, la recomendación es una aplicación web, y el motivo es práctico: una aplicación instalada debe firmarse, distribuirse y actualizarse en cada ordenador, y cada uno de los tres pasos cuesta siempre, no una sola vez.

El núcleo se escribe una vez y no sabe en qué corre

En nuestra aplicación de macOS, el objetivo de escritorio lista 15 archivos del núcleo del proyecto de iPhone como fuentes propias —cálculo, calibración, historial, políticas de notificación y de datos de salud. No están copiados, son los mismos archivos. La consecuencia: una corrección de algoritmo se hace en un solo lugar y aparece en ambos. La segunda consecuencia, más importante para ti: el núcleo se puede probar sin arrancar la aplicación.

El envoltorio de plataforma sigue siendo fino, y te decimos cuán fino

La aplicación de barra de menús usa `MenuBarExtra` sobre un delegado de aplicación AppKit —código nativo, pero poco, porque el resto es el núcleo común. Nuestra otra aplicación de macOS está en el extremo opuesto: tres archivos, un `WKWebView` empaquetado para SwiftUI, es decir, una ventana sobre una aplicación web. Ambas son aplicaciones legítimas de macOS, pero significan cosas distintas en esfuerzo, velocidad y acceso al sistema. Cuál de ellas necesitas se decide al principio, no se descubre en la entrega.

Construimos con un script, no pulsando un botón

La aplicación de barra de menú se construye a partir de un script de menos de cien líneas que llama directamente al compilador Swift, con el objetivo y la lista de marcos escritos explícitamente, luego coloca el paquete `.app` y lo firma. Un build que cabe en un script se ejecuta igual en otra máquina y puede ponerse en una línea automatizada; un build que existe solo en la interfaz de un programa de desarrollo no puede.

Sandbox y runtime reforzado, cuando la aplicación sale a la red

La segunda aplicación de macOS arranca con el sandbox activado y con un solo permiso de red, el de cliente — no servidor, no acceso a los archivos del usuario, no cámara, no micrófono. El runtime reforzado se activa desde la configuración del proyecto. Los permisos se declaran desde el inicio, como una lista corta que se puede leer, no se añaden sobre la marcha cuando algo falla.

La firma es un problema de cuenta, no de código, y lo ponemos sobre la mesa al principio

Nuestras aplicaciones de macOS están firmadas ad-hoc: la verificación pasa localmente, pero no existe identificador de equipo, y en la configuración del proyecto el campo del equipo de desarrollo está vacío. Para la distribución fuera de la tienda, un paquete de macOS necesita firma con un certificado de desarrollador identificable y pasar por la notarización de Apple; de lo contrario, el sistema operativo del que lo recibe lo bloquea. Es un problema de cuenta y de proceso, no de funcionalidad — pero es un problema real y no lo ocultamos en la última reunión.

Windows y Linux: qué pedimos antes de aceptar

Una verificación de compatibilidad pagada como primera etapa, que termina con un esqueleto que arranca en tu computadora, no con un documento. En ella se deciden tres cosas: qué entorno de ejecución usamos y por qué, quién posee el certificado de firma y la cuenta de distribución, y cómo llega una actualización a las computadoras de la gente. Si alguna de las tres no tiene respuesta, el trabajo no empieza. No asumimos una plataforma que no hemos entregado fingiendo que es un formalismo.

Linux server no es Linux desktop, y no confundimos las dos cosas

Nuestros sistemas funcionan día a día en Linux: unidades de sistema con reinicio ante fallo, servidor web delante, registros y su rotación. Esa es experiencia real con Linux, pero es experiencia de servidor. Una aplicación con ventanas para Ubuntu es otra disciplina — empaquetado, integración con el entorno gráfico, distribución mediante repositorio o mediante archivo autocontenido — y ahí no tenemos nada entregado. Esa diferencia la ve un ingeniero en tres segundos; mejor decirla nosotros antes.

Qué no hacemos

No prometemos un instalador que nunca hemos producido sin decir que es la primera vez. No elegimos un entorno de ejecución solo porque está de moda, sin verificar antes qué le pide la aplicación al sistema. Y no asumimos una aplicación de escritorio existente antes de poder construirla desde cero, en nuestra máquina, a partir de las fuentes recibidas — si el build no se reproduce, cualquier estimación posterior es una adivinanza.

Qué aspecto tiene

El recorrido, paso a paso.

Decidimos instalado o web, con cinco criterios

Sensores y periféricos, barra de sistema, trabajo sin internet, acceso a archivos, ejecución en segundo plano. Entregamos la decisión escrita, con el motivo, incluso cuando el motivo es «no necesitas una aplicación instalada». Esta etapa es corta y se puede detener aquí sin pérdida.

Construimos el núcleo y lo probamos sin plataforma

La lógica, los estados, la persistencia, las políticas — escritos para que la interfaz no importe y se puedan compilar y ejecutar como programa de línea de comandos. Entregamos la suite de pruebas y el comando con el que la ejecutas tú. Si después aparece una segunda plataforma, aquí se ve si el trabajo se hizo bien desde el principio.

Ponemos la envoltura de plataforma

En macOS: ventanas o barra de menú, notificaciones, permisos, el paquete `.app`, el script de construcción. En Windows o Linux: después de la verificación de compatibilidad de la primera etapa, con el entorno de ejecución elegido allí. Al final de la etapa la aplicación arranca en tu máquina, no en la nuestra.

Firma, distribución, actualización

La etapa que la mayoría de los proyectos descubre tarde y nosotros la ponemos al final de forma explícita, para que se vea: certificado, cuenta, notarización donde la plataforma la exige, canal de actualización. Aquí también está nuestro bloqueo actual en macOS: las aplicaciones están firmadas ad-hoc, sin identificador de equipo. En un proyecto tuyo, la cuenta es tuya y el bloqueo desaparece.

Un núcleo en el centro — cálculo, calibración, historial, políticas — que no importa ninguna interfaz y por eso se prueba solo. Alrededor, cuatro capas de plataforma: iPhone y macOS, enlazadas y construidas, dibujadas en sólido; Windows y Linux desktop, dibujadas en abierto, porque no existen. El quinto nodo, la distribución, está enlazado a macOS por una línea discontinua: el paquete se construye y se firma ad hoc, pero no pasa la notarización, así que no llega a otro ordenador. El dibujo dice qué está hecho y qué no, en la misma imagen.

Los datos

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Una aplicación instalada ve más que una del navegador: Eso es por lo que la quieres y, al mismo tiempo, su riesgo: tiene acceso al disco, al sistema de archivos del usuario y, si se le dan permisos, a periféricos. Por eso los permisos se declaran explícitamente y se mantienen al mínimo. Nuestra aplicación con sandbox tiene exactamente un permiso, el de cliente de red.
Dónde están los datos cuando la aplicación no tiene servidor: En el ordenador de la persona. En la aplicación de barra de menús, el historial se escribe en un archivo propio, y las preferencias en el almacén de ajustes del sistema, con claves prefijadas por aplicación. No sale nada hacia un servidor por una razón simple: no hay código de red en la aplicación. Cuando lo hay, se escribe en la página de permisos quién recibe qué.
Lo que no recopilamos por defecto: Ninguna telemetría, ningún identificador de dispositivo, ningún informe de uso, si no se solicitan explícitamente y se declaran en la interfaz. Una aplicación de escritorio es un lugar en el que la telemetría pasa desapercibida; por eso, si se pone, se pone visible, con botón de apagado, y se escribe qué campos salen.
Las actualizaciones son una decisión, no un detalle técnico: Hoy no tenemos construido un canal de actualización automática. En un proyecto nuevo esto es una de las tres primeras decisiones, junto con la firma y la distribución: ¿se actualiza manualmente, por la tienda de la plataforma, o por un canal propio? Cada variante tiene otro coste permanente y otra superficie de seguridad, y se elige antes de la primera línea de código, no después.
Lo que queda con nosotros: Las fuentes, mientras trabajamos; después de la entrega, lo acordado en el contrato. Los certificados de firma se quedan, idealmente, en tu cuenta de organización — si se quedan en la nuestra, quedas ligado a nosotros para cada actualización, y eso debe ser una elección consciente, no una consecuencia.

Un caso

Una aplicación de macOS sacada del núcleo de una aplicación de iPhone, sin una segunda implementación

La situación

Teníamos un producto propio para iPhone, que mide la inclinación de la cabeza respecto a una posición calibrada al inicio de la sesión. Las mismas reglas — calibración, umbrales, historial, políticas de notificación — también tenían sentido en Mac, donde la persona está de todos modos frente a la pantalla. La pregunta real no era si se puede, sino cuánto de la lógica habría que reescribir.

Qué construimos

Cero, porque el núcleo se escribió desde el principio sin saber de pantalla. El objetivo de macOS enumera 15 archivos del proyecto de iPhone como fuentes propias, a los que se añaden 25 archivos Swift específicos del escritorio: la ventana, el menú de la barra del sistema mediante un delegado de AppKit, las notificaciones, el servicio de entorno. La construcción no pasa por la interfaz Xcode: un script llama directamente al compilador Swift con el objetivo `arm64-apple-macosx14` y enlaza explícitamente once marcos de sistema, luego coloca el paquete `.app` y lo firma, y al final verifica la firma.

Qué salió

Un binario de 6.516.128 bytes para procesadores Apple, que arranca y se queda en la barra de menús, construido con un solo comando. La misma corrección de algoritmo llega al teléfono y al Mac, porque es el mismo archivo, no una copia sincronizada manualmente.

Qué no dice el caso

La aplicación no se distribuye y no puede serlo, hoy, en esta forma: la firma es ad-hoc, sin identificador de equipo, y el campo del equipo de desarrollo está vacío en la configuración del proyecto. En otro ordenador sería bloqueada por el sistema. Es un problema de cuenta y de notarización, no de funcionalidad — pero sigue siendo un problema no resuelto y lo escribimos como tal, no como detalle.

Preguntas

Lo que nos pregunta la gente antes de llamar

¿Por qué pone «oferta» en esta página, si dicen que tienen dos aplicaciones de Mac?

Porque el servicio se llama «aplicaciones de escritorio» y cubre tres familias de sistemas, y nosotros tenemos entregado en una. La regla que nos aplicamos a nosotros mismos exige un mínimo de dos implementaciones propias, demostrables en código, para cada afirmación de tipo «hemos hecho». En macOS las tenemos. En Windows y en Linux tenemos cero, y ninguna de las dos aplicaciones de Mac se ha empaquetado nunca en un instalador distribuible. Una página que dijera otra cosa caería en la segunda pregunta de un ingeniero.

¿Tienes una aplicación de Mac que pueda descargar ahora?

No. Ambas existen como paquetes `.app` construidos en nuestra máquina: uno compilado para procesadores Apple, el otro universal, para Intel y Apple. Están firmados de forma ad hoc, lo que significa que pasan la verificación local pero no tienen identificador de equipo, así que en otro ordenador el sistema las bloquearía. Lo que podemos hacer delante de ti es arrancarlas, abrir el código y el script de construcción y ejecutar la suite de lógica.

¿Cuál es la diferencia, entre las dos aplicaciones de Mac?

Una es nativa, la otra es una ventana sobre web, y la diferencia es grande. La nativa tiene 25 archivos Swift propios más 15 archivos de núcleo comunes con la versión de iPhone, se ancla en la barra de menús mediante un delegado de aplicación AppKit y enlaza once marcos de sistema, entre ellos sensores de movimiento, notificaciones y procesamiento de imagen. La segunda tiene tres archivos y muestra una aplicación web en un `WKWebView`. La segunda se hace rápido y es una elección correcta cuando tu aplicación ya es web y solo quieres un icono en el Dock. No es una elección correcta cuando necesitas sistema.

¿Hacéis aplicaciones para Windows?

No hemos entregado ninguna y no pretendemos otra cosa. Hemos buscado en nuestros discos cualquier rastro —proyectos .NET, WPF, WinForms, WinUI, archivos de interfaz XAML, manifiestos de aplicación, paquetes MSI o WiX— y todo lo que aparece pertenece a una biblioteca C de terceros que solo usamos en otro proyecto. Si necesitas Windows, la primera etapa es una verificación de compatibilidad que termina con un esqueleto que arranca en tu ordenador, y solo después de eso hablamos del resto.

¿Y para Linux o Ubuntu?

La misma posición, con una precisión que importa. Aplicación con ventanas para Linux: cero entregadas, ningún paquete deb o AppImage construido por nosotros. Servidores Linux: día tras día —unidades de sistema, servidor web delante, registros, reinicio tras fallo. Son dos disciplinas diferentes y sería deshonesto usar la primera como prueba de la segunda.

¿Por qué no Electron, si así es más simple?

Porque no hemos entregado ninguna y no vamos a pretender que tenemos experiencia donde no la tenemos. En nuestros discos existen dos aplicaciones Electron funcionales, pero son repositorios clonados de otros autores, con cero contribuciones nuestras —los hemos verificado en el historial de commits precisamente para que no lleguen a ser «prueba» en esta página. En un proyecto real, la elección entre un entorno web empaquetado y código nativo se toma después de saber qué le exige la aplicación al sistema, cuánto pesa el paquete y quién paga el mantenimiento, no por moda.

¿Qué bloquea, en vuestro caso, la publicación de una aplicación de Mac?

La cuenta, no el código. En la configuración del proyecto, el campo del equipo de desarrollo está vacío, y la firma del paquete construido es ad hoc, sin identificador de equipo. Para la distribución fuera de la tienda, macOS exige un certificado de desarrollador identificable y el paso del paquete por notarización. En un proyecto tuyo, el certificado y la cuenta son de tu organización, así que ese bloqueo simplemente no aparece —pero debe preverse desde el principio, con su coste y su tiempo.

¿No es más simple hacer un sitio web y acabar?

Muchas veces sí, y te lo decimos nosotros antes de que nos lo digas tú. Un sitio web no necesita firma, notarización, instalador, canal de actualización ni una versión para cada sistema operativo. La aplicación instalada gana cuando necesitas sensores, periféricos, trabajo sin internet, presencia permanente en la barra del sistema o acceso directo a los archivos de la persona. Si ninguno de esos está en la lista, el dinero se gasta mejor en otra parte.

¿Podéis asumir una aplicación de escritorio que ya tenemos?

Con una condición verificada antes de cualquier estimación: que podamos construirla desde cero, en nuestra máquina, a partir de las fuentes recibidas. Si el build no se reproduce —faltan dependencias, certificados, pasos no escritos— entonces nadie puede estimar honestamente nada, y el primer trabajo pasa a ser reproducir el build, no la funcionalidad nueva. Lo decimos antes, para que no se descubra a mitad de camino.

En qué se basan las afirmaciones anteriores (14 fuentes)

14 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.

Cómo trabajamos Todos los servicios

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar