Las bibliotecas Shiny (Bluetooth, tareas en segundo plano, push, ubicación y sincronización para .NET) han superado los 40 millones de descargas y están en el archivo de proyecto de apps que usted conoce. Las escribimos, las mantenemos y trabajamos con el equipo de .NET MAUI de Microsoft. Cuando su app tiene que funcionar en dispositivos reales sobre el terreno, esa es la profundidad que está contratando.
La parte de dispositivos del negocio, construida sobre una base que ya está en producción.
Apps de producción en .NET MAUI, iOS y Android, y migraciones de Xamarin a MAUI, incluido el trabajo en segundo plano, sin conexión y de ciclo de vida que la mayoría de los equipos hace mal. Trabajamos con el equipo de .NET MAUI de Microsoft desde los inicios de MAUI.
BLE central y periférico, flotas de dispositivos e integración de hardware. Escribimos las bibliotecas que el sector usa para esto.
Seguimiento de ubicación, geovallas y telemática para vehículos y equipos que trabajan donde la conectividad no está garantizada.
Aplicaciones para Apple Watch, Wear OS, CarPlay y Android Auto que llevan su aplicación móvil a la muñeca y al salpicadero, pensadas para un vistazo o una orden de voz, no para una pantalla de teléfono encogida. La conexión entre el teléfono y el reloj funciona con una biblioteca que escribimos nosotros.
Un presupuesto compra meses de ingeniería. La pregunta es en qué se gastan esos meses. En un producto conectado, cualquier cosa con un dispositivo, un proceso en segundo plano o funcionamiento sin conexión, una gran parte del primer año se va en infraestructura que el cliente no ve y que miles de equipos ya han escrito antes.
Proporciones ilustrativas: el reparto exacto depende del proyecto. Lo que no cambia es de qué lado de la línea le está pagando a un equipo de ingeniería por reconstruir.
Los ingresos y la retroalimentación llegan antes, porque el calendario no empieza con un trimestre de trabajo de base.
Los subsistemas más arriesgados (trabajo en segundo plano, sincronización, conectividad con dispositivos) ya están probados en producción antes de que empiece su proyecto.
Menos código propio significa menos que parchear, migrar y dotar de personal cada año tras la entrega.
La esquina que la mayoría de los proyectos sacrifica es una que nosotros ya pagamos, de forma abierta, a lo largo de 25 años, y viene incluida en el proyecto. Lo que eso le aporta es simple: más parte del año se dedica al producto que usted se propuso construir, y menos a llegar a la línea de salida.
Cualquier proyecto puede empezar con una de estas ofertas. Cada una tiene un nombre y un alcance por escrito antes de empezar, de modo que la primera decisión es pequeña, y usted ve cómo trabajamos antes de comprometerse con algo de mayor tamaño.
Para apps que ya están en .NET MAUI: tiempo de arranque, fallos que solo se reproducen en dispositivos reales y tareas en segundo plano que dejaron de ejecutarse tras una actualización del sistema operativo.
Una lista ordenada de correcciones, con las más graves diagnosticadas hasta la línea de código.
Cada plugin y dependencia de plataforma de su app de Xamarin, con lo que lo sustituye en .NET MAUI: el paso en el que se atascan la mayoría de las migraciones.
Un plan de migración basado en una consulta y no en una fase de investigación, y una estimación real.
Su hardware comunicándose con una app real en iOS y Android (escaneo, conexión, reconexión y sincronización en segundo plano) en dispositivos, no en un simulador.
La prueba de que la parte difícil funciona en teléfonos reales, y un camino presupuestado hasta la app de producción.
Cada oferta se presupuesta a precio cerrado cuando hemos visto el alcance, y un precio cerrado no cambia: si nos lleva más tiempo, es problema nuestro, no suyo.
Rara vez lo decide la conversión de la interfaz: lo decide la lista de dependencias. La auditoría de dependencias de dos semanas asigna a cada plugin su sustituto y lo convierte en una estimación por fases.
No. Normalmente tiene sentido, porque son de código abierto, ya están en producción y las mantienen las mismas personas que hacen el trabajo. Nunca queda atado a una capa privada que solo entiende el contratista.
Sí. La mayoría de los problemas de Bluetooth aparecen en la frontera entre la app y el firmware, y estamos acostumbrados a trabajar a ambos lados, incluido decirle a un proveedor qué tiene que cambiar por su parte.
Nuestra especialidad es .NET MAUI y .NET para iOS y Android, incluido el código nativo de plataforma que hay debajo. Si una app nativa es la decisión correcta para su producto, se lo diremos.
Cuéntenos sobre la app, los dispositivos y dónde se usan. Le diremos dónde suele fallar, y cómo lo evitaríamos.
