Servicios de desarrollo de apps Android para marcas

Los proyectos nuevos parten de Kotlin 2.x con el compilador K2, target SDK 35 (Android 15) y minSdk en 26 (Android 8.0), que cubre aproximadamente el 95 % de los dispositivos activos de EE. UU. y la UE. La política de Google Play exige que el targetSdk esté a menos de un año de la última versión principal, por lo que incorporamos sprints de actualización del SDK a la hoja de ruta anual. En las apps B2B de flotas con dispositivos rugerizados bajamos minSdk a 24 (Android 7.0) con backports aislados de AndroidX. Jetpack Compose es la capa de interfaz por defecto; la interoperabilidad con View/XML se mantiene para módulos heredados y para las rutas de CameraX/PdfRenderer en las que Compose todavía está poniéndose al día.

Ejecutamos una comprobación previa frente a las categorías de rechazo más habituales: formulario de Data Safety que no coincide con el comportamiento real de los SDK, falta de eliminación de cuenta (obligatoria desde mayo de 2024 dentro de la app y desde la web), tipos de servicio en primer plano mal declarados en Android 14+, permisos restringidos sin Permissions Declaration Form (SMS, registro de llamadas, AccessibilityService, MANAGE_EXTERNAL_STORAGE) e infracciones de la política Families. También corregimos antes de nuestra versión interna los fallos del Pre-Launch Report que Google ejecuta en dispositivos de Firebase Test Lab, lo que evita el 80 % de las reseñas de 1 estrella posteriores a la publicación.

Google Play Billing Library 7.x es la opción por defecto para bienes digitales (la política de Play sigue exigiéndola dentro del canal de distribución de Play en la mayoría de las categorías). Para los usuarios de la UE implementamos el piloto de User Choice Billing donde proceda: los usuarios ven Play Billing junto al procesador propio del desarrollador, con la correspondiente reducción de la comisión de servicio (3 por ciento). Para las categorías relevantes de la DMA admitimos la distribución alternativa mediante flujos de instalación directa de APK con los avisos de usuario correctos de Install Unknown Apps, y mantenemos un track de Play separado para la misma app. Las suscripciones usan el nuevo modelo de plan base/oferta con flujos de consentimiento adecuados ante cambios de precio.

Compose-first desde 2023 para todo el código nuevo: Compose 1.7+ con el modo strong-skipping, Compose Navigation con rutas con seguridad de tipos, Compose Material 3 con color dinámico y Compose for Wear OS cuando el producto se extiende a relojes. Los ViewModels usan Kotlin Coroutines y StateFlow, la inyección de dependencias va con Hilt y la capa de datos con Room y DataStore. Seguimos incorporando la interoperabilidad AndroidView/ComposeView para la vista previa de CameraX, los anuncios nativos de AdMob, ExoPlayer (Media3) y PdfRenderer hasta que los equivalentes nativos de Compose estén listos para producción. Se generan Baseline Profiles en cada versión para mantener el arranque en frío por debajo de 500 ms en dispositivos de gama media.

Alineado con el RGPD desde el diseño: base jurídica documentada por categoría de datos, el SDK User Messaging Platform (UMP) de Google para el consentimiento IAB TCF v2.2 en la UE, exportación granular de datos y eliminación de cuenta (también un requisito de la política de Play) y DPA con cada SDK de terceros. El formulario de Data Safety se rellena a partir de una única fuente de verdad que auditamos frente a los SDK reales del paquete; la discrepancia es la causa n.º 1 de las medidas de aplicación de la política. Para los clientes de la UE alojamos la infraestructura del backend en eu-central-1 o europe-west3, activamos Android Privacy Sandbox cuando el producto usa atribución publicitaria y mantenemos los datos personales fuera de Crashlytics/Sentry mediante depuración de breadcrumbs.

Las apps Android son de alcance cerrado y se presupuestan todo incluido en USD, escalonadas según la ambición del producto. Un MVP parte de $3,500 (4–8 semanas): la primera app funcional con un flujo principal en Kotlin 2.x y Jetpack Compose más una publicación en Google Play. Una app de producción parte de $5,800 (varias funcionalidades, integración con el backend, persistencia offline, analítica). Un producto completo parte de $9,200 (múltiples módulos, roles, integraciones externas, CI/CD y QA de dispositivos). Una app compleja con pagos, sincronización offline-first, SDK nativos y experimentos A/B parte de $11,500. Lo que mueve la cifra es el número de factores de forma, la profundidad de las integraciones y los permisos, la complejidad de la facturación y el alcance de cumplimiento. Usted ve el presupuesto desglosado antes de escribir una sola línea de código y lo aprueba.

Desarrollamos sobre la matriz de dispositivos Android: teléfonos (clases de tamaño de ventana compacta, media y expandida), tabletas de 7–12 pulgadas, plegables (continuidad entre pantalla interior y exterior con WindowSizeClass y layouts adaptados al pliegue) y pantallas grandes, usando WindowSizeClass y layouts adaptativos desde el primer día en lugar de añadirlos después. minSdk 26 cubre ~95 % de los dispositivos activos de EE. UU. y la UE; bajamos a 24 en los casos de uso B2B de flotas con backports aislados de AndroidX. Las peculiaridades de los optimizadores de batería de los fabricantes (Samsung, Xiaomi, OnePlus, Huawei) se prueban en hardware real para las tareas en segundo plano, no solo emuladas. Los Baseline Profiles se generan en cada versión para compensar el comportamiento variable de la compilación JIT entre las compilaciones de los fabricantes, manteniendo el arranque en frío por debajo de 500 ms en un dispositivo de la clase del Pixel 6a incluso tras una actualización automática de Play Console.

Sí. Wear OS 4/5 con Compose for Wear, Tiles y Complications es nuestro camino habitual para las apps complementarias de relojes inteligentes: apps de salud y actividad física, puente de notificaciones y seguimiento offline de entrenamientos que se sincroniza con el teléfono mediante Wearable Data Layer. Las apps de Android Auto y Automotive OS siguen las pautas de diseño de AAOS para una experiencia en el coche probada frente a distracciones, con interacción por voz mediante Car App Library y navegación giro a giro integrada con la app del teléfono. Android TV usa la biblioteca Leanback y Compose for TV para una interfaz de 10 pies con navegación por mando y DPAD. Cada factor de forma pasa por las revisiones de los niveles de calidad de pantalla grande y de automoción de Google Play, que comprobamos antes del envío.

Offline-first significa que la app es plenamente funcional sin red, no solo que se degrada con elegancia. Usamos Room como fuente única de verdad con una capa reactiva de StateFlow para que la interfaz se actualice al instante desde la base de datos local y, después, un motor de sincronización que concilia con el backend cuando vuelve la conectividad. La estrategia de resolución de conflictos (last-write-wins, servidor como autoridad o basada en CRDT) se acuerda en el descubrimiento según el modelo de datos. WorkManager gestiona la sincronización en segundo plano con retroceso exponencial y conciencia de las restricciones de red, de modo que la tarea de sincronización se ejecuta cuando el dispositivo tiene una conexión adecuada sin agotar la batería. Hemos entregado offline-first en logística (xRouten, donde los conductores envían confirmaciones de entrega en zonas sin cobertura), HealthTech y escenarios de inspección de campo en los que la conectividad es estructuralmente poco fiable.

Sí, y es un proyecto habitual para nosotros. El enfoque estándar es incremental: convertimos los archivos Java a Kotlin con el conversor automático de IntelliJ y después depuramos la nulabilidad, las corrutinas y el Kotlin idiomático módulo a módulo. La migración de la interfaz de XML Views a Compose se hace pantalla a pantalla mediante la interoperabilidad con ComposeView, de modo que la interfaz antigua y la nueva coexisten sin una reescritura total (big-bang) y su app sigue llegando a los usuarios durante todo el proceso. También migramos las cadenas de RxJava a Kotlin Coroutines y StateFlow, AsyncTask/Loader a ViewModel y los scripts de compilación en Groovy a Kotlin DSL con version catalogs. La migración se dimensiona en nuestra evaluación inicial de descubrimiento, y nos comprometemos a no introducir regresiones ejecutando el conjunto de pruebas Espresso existente contra cada pantalla de Compose a medida que se publica.

Aplicamos la pirámide de pruebas estándar de Android: pruebas unitarias con JUnit5 y MockK para la lógica de negocio y los ViewModels (rápidas, sin necesidad de dispositivo); pruebas de integración con bases de datos Room en memoria, Hilt TestComponent y Retrofit MockWebServer para los contratos de la capa de datos; y pruebas de interfaz con Compose Test y Espresso para los flujos de extremo a extremo. La semántica de Compose hace las pruebas de interfaz mucho más estables que la comparación de capturas en jerarquías de Views. Macrobenchmark y Microbenchmark miden el arranque en frío y el rendimiento de desplazamiento sobre los objetivos de Baseline Profile. Los fallos del Pre-Launch Report en Firebase Test Lab se corrigen antes de cada versión interna, detectando los fallos específicos de dispositivos Samsung y Pixel en el laboratorio de pruebas antes de que los encuentren usuarios reales. En los sectores regulados añadimos pasadas adicionales de pruebas de seguridad que cubren el cifrado de datos en reposo, el análisis del tráfico de red y la verificación del certificate pinning.