En vez de usar la Web de Mastodon usaré un cliente como Ice Cubes, en vez de un cliente IRC web (como The Lounge, que, por cierto, tiene una pinta estupenda) buscaré usar algo como Textual o Halloy. En vez de Gmail o iCloud Mail en la web configuraré todas mis cuentas en Mail.app. Y así con todo.

Y el caso es que, reflexionando, en general estoy pensando que mi cuestión no está tan relacionada con la tecnología usada para desarrollar una aplicación o con las APIs que terminan usándose, como con las sensaciones a la hora de utilizarla, de verla y de integrarse con el resto del sistema. Voy a intentar explicarme y espero no meterme en ningún jardín por el camino.

No es la tecnología, es el feeling

Estoy escribiendo esta nota utilizando el editor Zed, como ya os conté. El editor Zed en general se siente como nativo. Está desarrollado usando Rust, probablemente use las APIs de Cocoa como las demás. Otra app que estoy usando ahora mismo es el cliente IRC Halloy. También está desarrollado en Rust y usa un toolkit multiplataforma para la interfaz de usuario llamado Iced. Permite construir interfaces de usuario para Windows, Linux y macOS.

Y ambas apps yo las estoy sintiendo como “nativas”. Funcionan rápido, creo que son compiladas (tendría que ver cómo funciona Rust), no se ven feas. Cierto es que tienen ciertas peculiaridades en sus interfaces (por ejemplo, en la barra lateral se muestra la manita en vez del puntero normal del ratón), pero puedo vivir con eso sin mucho problema.

Esto plantea la verdadera pregunta, la clave de todo esto. ¿Qué es una app nativa?, me dices mientras clavas en mi pupila tu pupila azul. Es complicado de decir. En general yo diría que una app nativa es aquella que no es una app construida con tecnología Web. Pero esto tiene muchos peros: por un lado hay frameworks que permiten construir apps nativas desarrolladas con tecnología Web (ahí está React Native). Por otro lado, una app multiplataforma construída con el SDK nativo de Apple puede no sentirse como una app nativa. Las fronteras, en general, están difusas.

Hay apps que sabemos perfectamente que son Web y sin embargo en general se sienten como nativas también. Visual Studio Code es un ejemplo. Es una aplicación construida con tecnología Web que funciona gracias a Electron (en general y simplificando mucho, cada ventana de Visual Studio Code es un navegador Chromium con cosas). Y aunque en general no se ve nativa, funciona bien y podría vivir con ella. Slack, Obsidian y Logseq son otros ejemplos de ello que yo haya utilizado (y debe haber muchas más). Otras apps como Spotify también hacen uso extensivo de tecnologías Web en muchas partes de su interfaz.

En apps móviles el gap es un poco más evidente, eso sí. Algunas apps como Bluesky usan React Native y en general se sienten como nativas (en este post de Samuel en Mozzius se habla del tema). Otras apps como aquellas que usan Ionic sí que se notan como que son un navegador con cosas, y aquí sí que considero que muchas veces la experiencia sí que se resiente. Pero en el escritorio es otra cosa totalmente distinta y las diferencias no están tanto en la tecnología usada como en otras cuestiones más relacionadas con la pura experiencia del usuario. Al final se nota más una aplicación que “no termine de encajar” por cómo se ve que por cómo esté construída.

Por poner un ejemplo, siempre pensé que todas las versiones de Office desde Office XP no terminaban de encajar en Windows. En Windows XP, ni Office XP ni Office 2003 se veían “integrados”, “cohesionados” con la interfaz del resto del sistema. En Windows Vista también había diferencias entre las aplicaciones del sistema y otras aplicaciones de Microsoft (ya por no contar lo dispares que eran todas las interfaces de esa época). En macOS sin embargo las distintas apps siempre se veían más “como en casa” (y por lo general los usuarios de macOS le prestamos bastante atención a ese punto, incluso buscándolo específicamente; este post es ejemplo de ello).

Me importa más la experiencia que ofrecen en cada entorno

A mí, al final, lo que me acaba importando más es que las apps se sientan nativas en la plataforma y el entorno en el que están. Por ejemplo, que una app de escritorio (y, en menor medida y recientemente, de tablet) sea capaz de manejar más de una ventana sin problema. Poder tener, por ejemplo, distintos chats de WhatsApp abiertos en distintas ventanas. Más de un documento a la vez para así poder colocar uno al lado de otro.

Si tengo que usar una app de tablet o de móvil en el escritorio (algo que, en el caso concreto de los sistemas operativos de Apple en ordenadores con Apple Silicon, es particularmente frecuente) no pasa nada, es lo que hay y seguramente funcione bien. Pero se va a notar que no es una app pensada para el ordenador.

También importa que la app disponga de elementos en la barra de menús para sus funcionalidades, por ejemplo. O que los controles no sean “tamaño dedo” para entornos donde usas habitualmente un ratón, así como que tengan un menú contextual en el caso de que sea coherente. También que se puedan arrastrar y soltar archivos, textos o imágenes; es algo a lo que en realidad estamos acostumbrados.

Y, en todo caso, cuando uso web apps (al menos de manera prolongada y/o habitual) termino prefiriendo que tengan su propia ventana, y no que existan dentro de un navegador. Esto en Safari se hace en Archivo » Añadir al Dock. En iOS también puedes crear iconos en la pantalla de inicio y, si la webapp lo permite, ésta funcionará a pantalla completa y podrá no ser tan distinta a una aplicación “normal”.

En mi ordenador con Linux, por ejemplo, reconozco que me encantaría poder usar solo apps que se integraran con KDE. Me gusta usar Konqueror como navegador (incluso estando casi abandonado y existiendo Falkon) porque tengo la sensación de que se integra mejor. Me gusta que Kate se integre con otras herramientas, me gusta que la apariencia de todos los programas que uso sea coherente. No me gusta que los diálogos de guardar, por ejemplo, sean distintos en Firefox que en otros sitios, porque a veces sean KDE y a veces GNOME. También es cierto que soy menos exigente con ese ordenador y ese entorno porque entiendo que en muchos casos el desarrollo se hace de forma altruista.

En el blog Coyote Tracks se reflexiona justo sobre este tema. «What makes an app feel “right” on the Mac?»

Entiendo la existencia de apps híbridas y multiplataforma

No obstante como desarrollador entiendo perfectamente la existencia de apps híbridas y de aplicaciones construidas para todas las plataformas. Entiendo perfectamente que para un equipo de desarrollo es más sencillo y más rápido lanzar una única aplicación para todas las plataformas, con las adaptaciones necesarias, que construir una app para cada plataforma. A veces el time to market es crucial y a veces es necesario lanzar lo más rápido posible.

Entiendo también el uso de frameworks como los que menciono, Electron, React Native, así como el uso de sistemas que permiten compartir código entre plataformas, como Kotlin Multiplatform. Al final trabajo en la industria y entiendo que estos sistemas y estas formas de construir aplicaciones son útiles (y por lo general es mejor tener una aplicación, sea de la forma que sea, que no tenerla). Pero también entiendo, como usuario, que la experiencia tenga que ser la mejor posible y la que mejor se ajuste a la plataforma en que va a ejecutarse.

¿Qué pensáis vosotros? ¿Le prestáis atención a esto u os da igual? ¿Usáis muchas webapps, dentro del navegador o en sus propias ventanas?

El software de escritorio tiene en general que permitir tener varias ventanas abiertas, y que el usuario se las pueda recolocar a su gusto. Reflexionaré sobre esto en próximas entradas, cuando no tenga el dedo averiado (ya explicaré).

Pero el caso es que en un ordenador no es necesario mostrar los botones de una calculadora, al menos no los botones básicos. Todos los teclados tienen teclas para los números y permiten escribir, al menos, las operaciones básicas (+ para la suma, - para la resta, * para la multiplicación y / para la división).

Admito que en un modo científico sí muestres botones para mostrar las operaciones disponibles (las trigonométricas, las conversiones y demás). Pero para un uso normal una calculadora en realidad no debería tener que mostrar estos controles, que en realidad no son más cómodos que usar el teclado.

Mi teoría es que este tipo de interfaz se creó a finales de los 80 o inicios de los 90 como una forma de acercar esta funcionalidad a los usuarios que acaban de llegar a un ordenador, de mostrarles una aplicación familiar y semejante a la calculadora física que ya conocían y sabían manejar. Y paralelamente también serviría para entrenar en el uso del ratón, igual que en Windows incluían el Solitario.

Para los que en algún momento de la historia hemos aprendido a programar, además, hacer una calculadora es el ejercicio clásico cuando comienzas a aprender determinadas disciplinas. Puedes hacer la típica calculadora que va preguntando números para sumarlas si estás aprendiendo a programar, una calculadora gráfica para aprender cómo funciona el desarrollo de interfaces gráficas de usuario, o también si estás aprendiendo CSS. Y también puedes usar algún lenguaje de esos que reconocen cadenas para aprender a procesarlas y a crear lenguajes de uso específico (recuerdo vagamente un ejercicio sobre esto de la asignatura de Teoría de Lenguajes de la carrera).

En muchos sistemas, por suerte para los que somos de no levantar los dedos del teclado, hay alternativas a las calculadoras que solo requieren texto. Por ejemplo, en macOS es posible hacer una operación en Spotlight (Cmd+Espacio, y escribes una cadena con la operación a hacer, incluso con paréntesis si es necesario). En KDE acabo de probar y se puede hacer dentro del buscador del menú Inicio. No tengo acceso a un Windows pero seguramente puedas hacer la misma operación también con la búsqueda (aunque ahora lo mismo te sugiere que la operación la haga Copilot, que se ve que a los ordenadores se les ha olvidado cómo se calculan cosas).