Desarrollo de aplicaciones de escritorio: consideraciones clave, tecnologías y costos

La mayoría de las decisiones sobre software de escritorio se toman al revés. Un equipo elige el navegador porque hoy todo vive ahí, y después se topa con la única tarea que este se niega a hacer.

El desarrollo de aplicaciones de escritorio consiste en crear software que se instala y se ejecuta en el propio ordenador, en lugar de cargarse desde la web cada vez. Eso le da uso directo de la máquina: sus archivos, sus equipos conectados y toda su potencia de procesamiento. Es la opción correcta siempre que un programa deba funcionar sin conexión, mover grandes volúmenes de datos o comunicarse con hardware físico.

Esta guía explica cuándo tomar esa decisión, qué herramientas se utilizan, qué determina el costo y cómo evaluar a un socio tecnológico. Todo lo que contiene proviene de un equipo que ofrece servicios de desarrollo de aplicaciones de escritorio para Windows, macOS y Linux.

Qué significa realmente el desarrollo de aplicaciones de escritorio

Toda la diferencia se reduce a dónde vive el programa. El software web se aloja en el servidor de otra persona y llega a usted a través de un navegador. Una aplicación de escritorio se instala en el ordenador que tiene delante.

Esa ubicación no es un detalle menor, ya que determina lo que el software puede hacer. Una aplicación de escritorio se ejecuta en su propio ordenador, por lo que puede controlar el equipo conectado a esa máquina. El programa abre y guarda archivos donde usted lo permita, y aprovecha toda la potencia del procesador. Y lo mejor de todo: el trabajo continúa aunque falle internet.

Los navegadores bloquean casi todo eso de forma deliberada. Cualquier sitio web que visite se ejecuta dentro de un sandbox, una sala sellada sin puertas hacia el resto de su ordenador. Eso es bueno, porque usted no querría que una página cualquiera accediera a sus archivos o a su impresora. El intercambio es simple: renuncia a ese alcance y obtiene software que se abre desde cualquier lugar con un enlace.

Debajo de todo esto hay una decisión que mueve el presupuesto más que ninguna otra. ¿Construye el software una sola vez para todos los sistemas, o por separado para cada uno?

• Nativo, es decir, construido para un sistema a la vez. Cada versión se escribe específicamente para Windows, macOS o Linux. Obtiene la máxima velocidad, todas las funciones que ofrece el sistema y algo que resulta natural para quienes lo usan.
• Multiplataforma, es decir, construido una vez para los tres. Una única versión se adapta para ejecutarse en todas partes. Crearla y mantenerla cuesta menos, aunque se sacrifica algo de velocidad y alguna función puntual que solo ofrece una plataforma.

Ningún enfoque gana en abstracto, así que la respuesta depende de su situación y no de una regla fija. Una herramienta exigente usada por un solo departamento normalmente vale la pena construirla para su propio sistema, donde esa velocidad extra se nota. Sin embargo, el software que debe llegar a cada puesto de una oficina con equipos mixtos es el caso contrario. Una versión adaptable supera a tres versiones perfectas que nadie tiene tiempo de mantener.

Cuándo el escritorio supera a la web o a lo móvil

Tres necesidades apuntan directamente al software instalado. Si reconoce alguna de ellas en sus propios planes, el escritorio merece una consideración seria.

• Tiene que funcionar sin internet. Las herramientas de planta de fábrica, el software de servicio de campo y los sistemas de punto de venta deben seguir funcionando cuando falla la conexión. Un sitio web puede simular esto hasta cierto punto almacenando datos localmente, pero el esfuerzo necesario es considerable y el resultado sigue siendo frágil.
• Tiene que realizar trabajo pesado en la máquina. El software de diseño, la edición de video y las grandes herramientas de datos internas necesitan todo el ordenador: memoria abundante, un procesador rápido y el disco ahí mismo. Una pestaña del navegador funciona dentro de límites que existen por buenas razones y que no van a ceder por usted.
• Tiene que comunicarse con equipos físicos. Esta es la línea más marcada de las tres, porque una página web prácticamente no puede acceder a la mayoría de los dispositivos.

El hardware es donde esa línea se pone a prueba en la práctica. BlueCloud Technologies tenía un producto que marca documentos con marca de agua en pantalla, y querían la misma protección en papel. Les construimos Printer Interceptor, un componente que sella cada página al salir y que puede cancelar un trabajo de impresión por completo. Funciona tanto con hardware físico como con destinos del tipo guardar como PDF. Lograrlo implicó trabajar dentro de la propia cola del sistema operativo, un lugar al que ningún navegador tiene acceso. Es compatible con Windows 8 a 11, tanto en máquinas de 32 bits como de 64 bits.

Ese es el intercambio entre escritorio y aplicación web en una sola vista. El escritorio gana en capacidad, la web en alcance, y lo móvil queda en medio, con sus propias reglas de tienda de aplicaciones. Lea esa tabla en función de su requisito más exigente y no del más común, porque la necesidad más estricta es la que elimina opciones.

Esto también es una cuestión de dinero, no solo técnica. Desarrollar para una sola plataforma es un trabajo mucho menor que cubrir tres. Por eso nuestros servicios de desarrollo de aplicaciones para Windows y nuestro trabajo multisistema producen estimaciones muy diferentes.

Cómo se construyen las aplicaciones de escritorio: herramientas y lenguajes

El lenguaje que elige un equipo sigue al trabajo, no a la moda. Una lista breve cubre la mayor parte del software empresarial de este tipo.

• C# y .NET encajan con software que empieza en Windows y debe integrarse con el entorno Microsoft que ya tiene la empresa. El grupo de talento es amplio, y conectar con sistemas que un negocio ya posee es algo rutinario, no una investigación. Nuestra práctica de empresa de desarrollo en C# usa esta combinación desde 2005, y hoy es lo que más piden los clientes.
• C y C++ entran en juego cuando la memoria o la velocidad realmente determinan el resultado. Nuestra página de empresa de desarrollo en C++ enumera el conjunto más amplio de herramientas detrás de este tipo de proyectos.
• Los frameworks multiplataforma se encargan del enfoque de versión única, y hoy dominan tres. Electron conviene a equipos cómodos con tecnología web, y .NET MAUI encaja con quien ya está volcado en Microsoft. Flutter llega al escritorio desde el mismo código que una app móvil. Qt todavía aparece en productos más antiguos donde el rendimiento es crítico. Elegimos según el proyecto, en lugar de recurrir siempre a uno solo.

La memoria y la velocidad son fáciles de afirmar y más difíciles de demostrar, así que aquí va un dato de un proyecto propio. Al construir los grabadores de Windows para SystemDataRecorder, un producto de monitoreo de rendimiento para SDR Dynamics Oy, escribimos el mismo servicio pequeño dos veces. En C usaba unos 2 MB de memoria. La versión en C# necesitaba un mínimo de 6 MB, más un runtime adicional de Microsoft en cada máquina donde se instalara. Para una herramienta cuyo único trabajo es funcionar en silencio en segundo plano, el triple de memoria fue el factor decisivo. El equipo la entregó en C.

La regla se generaliza. Encuentre la restricción que realmente limita, elija lo que la satisfaga y trate el resto como cuestión de gusto. Nuestra guía sobre cómo elegir el stack tecnológico adecuado aplica la misma lógica a otro tipo de productos. Para proyectos con mucho peso de Microsoft, nuestra página de empresa de desarrollo .NET a medida contiene el detalle.

Cómo llevar una aplicación de escritorio a tres sistemas

Lo que los equipos subestiman es todo lo que ocurre después de escribir el código. Llevar una aplicación a tres sistemas significa tres instaladores distintos. Cada uno necesita su propia firma digital, o el ordenador se negará a confiar en el archivo. Luego llega un método de actualización que la gente realmente tolere. La propia documentación de MSIX de Microsoft repasa certificados, empaquetado y firma, y eso cubre solo uno de los tres sistemas.

Nuestro proyecto Incling muestra la magnitud de ese trabajo. Un applet de Java heredado para grabación de pantalla tenía que convertirse en un programa independiente que funcionara en todas partes. Teníamos menos de tres semanas, porque los navegadores estaban dejando de admitir el plugin del que dependía.

Escribir la aplicación fue la parte más pequeña del trabajo. Revisamos el applet antiguo y no encontramos ningún sistema de compilación. Nadie había llevado registro del resto del software del que dependía, así que la limpieza eliminó unas 15.000 líneas. Después vino el empaquetado, usando NSIS, launch4j, fpm, pkgbuild y packr para construir instaladores para Windows, macOS y Linux. El producto final instala Java por su cuenta si el ordenador todavía no lo tiene. Un enlace en una página web lo inicia directamente. Las actualizaciones llegan discretamente cada vez que alguien empieza una nueva grabación, que es la forma más adecuada de hacerlo.

Costos y plazos del desarrollo de aplicaciones de escritorio

Los proyectos de escritorio varían demasiado como para que un promedio signifique algo. Dos productos con la misma lista de funciones pueden costar cantidades muy distintas. Depende de en cuántos sistemas se ejecutan y de lo profundamente que interactúan con el hardware. Cualquier cifra que se dé antes de conocer esas respuestas lo anclará a un número equivocado. Al menos podemos darle las cinco preguntas que determinan el total, para que pueda dimensionar el trabajo antes de recibir una estimación.

• ¿En cuántos sistemas debe ejecutarse? Uno o tres es el multiplicador más grande de todos, y afecta la construcción, las pruebas, los instaladores, las firmas y cada lanzamiento posterior.
• ¿Qué tan complicadas son las pantallas? Un formulario simple para un equipo y una herramienta de edición profesional con gráficos personalizados están en extremos opuestos de la escala.
• ¿Con qué hardware tiene que comunicarse? Las impresoras, los escáneres, la maquinaria y los equipos especializados suman investigación, casos límite particulares y dispositivos de prueba que hay que poseer físicamente.
• ¿Cómo llega a las personas y se mantiene actualizada? Los instaladores, los certificados, las actualizaciones silenciosas y los informes de fallos son ingeniería real, y este es el punto que más se olvida.
• ¿Cuántos años debe seguir funcionando? El software instalado sobrevive a la mayoría de los sitios web, así que hay que presupuestar nuevas versiones del sistema, cambios de controladores y funciones que se retiran.

Dos de esas cinco no tienen nada que ver con construir el producto en sí, por eso las estimaciones de escritorio sorprenden a la gente. Para conocer cómo abordamos la estimación en general, consulte nuestro análisis sobre cuánto tiempo lleva construir una app.

Cómo elegir un socio de desarrollo de escritorio

Las conversaciones con proveedores tienden hacia lo abstracto, lo cual es cómodo para todos y útil para nadie. Cuatro preguntas obligan a dar respuestas concretas, y esas respuestas distinguen a un equipo que ya ha entregado software instalado de otro al que simplemente le gusta la idea.

• ¿A qué sistemas ha llevado realmente software a producción? Admitir una plataforma en teoría y corregir un fallo de firma en ella a medianoche son cualificaciones muy distintas. Pida el proyecto, la versión y el año.
• ¿Cómo gestionan las actualizaciones? Nadie persigue las descargas, así que el software sin una vía de actualización que funcione se convierte en un dolor de cabeza de soporte antes de dos versiones.
• ¿Qué ocurre cuando falla en el equipo de un cliente? No se puede mirar dentro de un portátil que está a tres husos horarios de distancia, así que el programa tiene que informar de sus propios fallos, y eso se diseña desde el principio.
• ¿Cómo mantienen el software funcionando cuando cambian las plataformas? Aquí es donde los proyectos de escritorio mueren en silencio.

Esa última pregunta merece un ejemplo real. Green Valley es un proveedor líder de administración electrónica en los Países Bajos y Bélgica. Su complemento para Microsoft Word se rompía cada vez que los clientes actualizaban Office, así que mantenían una compilación separada para cada versión en circulación. Lo reconstruimos para que dependiera únicamente de las partes que nunca cambian, y lo llamamos CMSOI. Ahora una sola instalación no necesita permisos especiales, sobrevive a las actualizaciones y funciona en inglés y en neerlandés.

Las pruebas que un socio acepta dicen tanto como cualquier discurso comercial. Los agentes de SystemDataRecorder tenían que funcionar durante 48 horas sin fugas de memoria, y luego reiniciarse automáticamente tras un corte de energía. Pregunte con qué se midió el último proyecto de escritorio de un proveedor, y preste atención a ese tipo de respuesta. Nuestros servicios de mantenimiento de software existen porque esta etapa, no la construcción, es donde ocurre la mayor parte de la vida de un producto.

El escritorio es una elección, no un remanente

El escritorio es la respuesta correcta siempre que trabajar sin conexión, el procesamiento local intensivo o el acceso a equipos físicos importen más que estar disponible desde cualquier navegador. Eso lo convierte en una decisión de ingeniería deliberada, no en un remanente de una época anterior. Cada proyecto descrito arriba es un producto real con usuarios reales.

Como empresa de desarrollo de aplicaciones de escritorio, Redwerk desarrolla y mantiene software instalado para Windows, macOS y Linux. Si está evaluando el escritorio frente a las alternativas, cuéntenos qué está construyendo y le responderemos con una estimación gratuita.

Preguntas frecuentes

Descubra cómo auditamos el software Project Science de Complete Network y logramos un aumento del 80 % en la mantenibilidad del código

Este campo es obligatorio. no es un correo electrónico comercial

Obtener caso práctico