Javier Cantos

Hasta hace poco, añadir IA generativa a una aplicación móvil significaba casi siempre enviar una petición a un servicio remoto, esperar la respuesta y pagar por los tokens consumidos. Microsoft Build 2026 puso otra opción en primer plano para .NET MAUI: ejecutar modelos y capacidades de IA en el propio dispositivo. No es solamente una forma de ahorrar. Si el caso de uso encaja, la IA local permite trabajar sin conexión, reduce la exposición de datos sensibles y evita que la latencia de red forme parte de la experiencia. Pero también traslada a la aplicación responsabilidades que antes asumía el proveedor de la API: compatibilidad de hardware, descarga del modelo, memoria, batería, actualizaciones y calidad de las respuestas. Qué anunció Microsoft y qué conviene matizar En el resumen oficial de .NET en Microsoft Build 2026 , Microsoft destacó la sesión Taking your AI to the edge with .NET MAUI : modelos locales y capacidades en el dispositivo para aplicaciones móviles y de escri...

Durante años, desarrollar aplicaciones móviles con C# ha significado convivir con dos mundos dentro de .NET. El backend, las aplicaciones de escritorio y los servicios en la nube utilizaban CoreCLR, mientras que Android, iOS y Mac Catalyst seguían ejecutándose sobre Mono. En .NET 11 esa separación empieza a desaparecer: CoreCLR pasa a ser el runtime predeterminado de .NET MAUI también en las plataformas móviles. El cambio es importante, pero conviene interpretarlo bien. No significa que tengamos que reescribir la interfaz ni abandonar XAML, los handlers o nuestras bibliotecas habituales. Lo que cambia está más abajo: es el motor que ejecuta el código administrado, gestiona la memoria, compila métodos y proporciona herramientas de diagnóstico. Mono fue la pieza que hizo posible .NET en móviles Hablar de esta transición como si Mono hubiera sido un error sería injusto. Mono llevó C# a entornos donde originalmente .NET no podía ejecutarse. De MonoTouch y MonoDroid nacieron Xamarin...

Esta semana el caso mas interesante no fue un error grande, sino uno de esos fallos de interfaz que solo aparecen cuando la aplicación empieza a correr en un dispositivo real, con listas virtualizadas, filas de altura variable y eventos que llegan en momentos poco cómodos. El sintoma era serio: en iOS, la app podia cerrarse al recibir o cargar mensajes en un chat. La operación que parecía inocente era el scroll automático al final de la conversación, el dato ya estaba en la coleccion, pero la vista nativa todavía no siempre tenia preparada la fila correspondiente. El contexto En una pantalla de chat, hacer scroll al ultimo mensaje parece una accion sencilla, cuando llega un mensaje nuevo, se actualiza la coleccion y se pide al listado que se posicione al final: var item = messages[messages.Count - 1]; listView.ScrollTo(item, position: ScrollToPosition.End, animated: false); El problema es que en una lista real no hay una equivalencia instantanea entre "el elemento ya e...

En este post explico cómo monté un pequeño pipeline local para publicar una app .NET MAUI iOS en TestFlight sin depender de un servicio externo de CI. La idea final fue: Visual Studio en Windows -> ejecuta una External Tool -> conecta por SSH al Mac mini -> el Mac compila la app iOS -> genera la IPA -> sube la IPA a TestFlight 1. Separar el repositorio de los secretos El primer aprendizaje importante fue no mezclar el repositorio Git con los secretos ni con scripts locales que necesitan permisos de ejecución. Por ejemplo, podemos tener el repositorio en: /Users/usuario/Builds/MiApp.Mobile Y el pipeline local en una carpeta independiente: /Users/usuario/LocalMagic Creamos la estructura: mkdir -p /Users/usuario/LocalMagic/secrets mkdir -p /Users/usuario/LocalMagic/logs 2. Preparar los archivos necesarios En la carpeta de secretos coloqué los siguientes archivos: ios_distribution.p12 AuthKey_XXXXXXXXXX.p8 AppStore_Profile.mobileprovis...