Diseña una función de rastreo de ubicación que respete tanto la batería como la privacidad del usuario

#Aclarar los requisitos primero

Antes de tocar una sola API, quiero saber qué significa realmente 'rastrear la ubicación' para este producto, porque la arquitectura correcta para una app de viajes compartidos que necesita precisión a nivel de calle mientras un viaje está activo no se parece en nada a la de una app de fitness que solo dibuja una ruta después del hecho, o a la de una app de retail a la que solo le importa si el teléfono entró en un radio de 100 metros alrededor de una tienda. Le preguntaría al entrevistador: ¿esto tiene que funcionar con la app en segundo plano o incluso cerrada? ¿Se necesita precisión al metro, o basta con saber en qué barrio está? ¿Es un flujo continuo o una verificación disparada por un evento? Y la pregunta que en realidad define el diseño: ¿qué valor recibe el usuario a cambio de otorgar este permiso?, porque eso determina tanto la experiencia como si los equipos de revisión de Apple y Google lo van a aceptar siquiera.

#La tensión central: batería, precisión y confianza

El GPS es uno de los subsistemas que más energía consume en un teléfono. Obtener una posición implica encender el chip de GPS, correlacionar señales satelitales y, muchas veces, también consultar torres celulares y puntos de acceso Wi-Fi para el posicionamiento asistido. Consultarlo de forma continua a alta precisión agota la batería de forma visible en pocas horas, y hace que la app quede marcada por las propias heurísticas de actividad en segundo plano del sistema operativo — el reporte de batería por app de iOS, los App Standby Buckets y Battery Historian de Android — mucho antes de que un usuario se queje. Al mismo tiempo, la ubicación continua es posiblemente el flujo más sensible que puede recolectar una app móvil: a lo largo de unas semanas revela el domicilio, el lugar de trabajo, el lugar de culto, visitas médicas y con quién pasa la noche alguien. Por eso ambas plataformas condicionan la autorización 'Siempre' a una justificación explícita, y por eso los reguladores tratan la ubicación precisa como dato personal sensible con reglas propias de consentimiento y retención. Entonces el objetivo de diseño no es 'rastrear la ubicación', sino entregar la precisión que la función realmente necesita usando el modo más económico, menos frecuente y de menor duración que la satisfaga.

#Primitivas de cada plataforma

Ambas plataformas ofrecen un menú de niveles por debajo del GPS continuo completo, y una respuesta senior se apoya en todos ellos en lugar de recurrir por defecto al más potente. En iOS, el servicio estándar de CLLocationManager es el costoso; el servicio de cambio significativo de ubicación en cambio usa triangulación de celdas y Wi-Fi para despertar la app solo después de unos 500 metros de movimiento o un cambio de torre celular, a una fracción del costo energético, y funciona incluso si el sistema terminó el proceso de la app. El monitoreo de regiones (CLCircularRegion, hasta 20 regiones por app) es geocercado respaldado por hardware — el propio chip de radio vigila los cruces de frontera y solo despierta el proceso al entrar o salir, así que cuesta casi nada mientras está inactivo. El monitoreo de CLVisit va un paso más allá e informa que el usuario se quedó en un lugar por un tiempo, que muchas veces es todo lo que necesita una app de retail o logística. En Android, FusedLocationProviderClient expone prioridades de precisión — PRIORITY_BALANCED_POWER_ACCURACY prefiere el posicionamiento por red (~100m, barato) sobre el GPS crudo, mientras que PRIORITY_HIGH_ACCURACY es el costoso — y su API de geofencing (hasta 100 regiones) refleja el monitoreo de regiones respaldado por hardware de iOS. Desde Android 8, todo trabajo de ubicación continuo en segundo plano debe correr dentro de un foreground service con una notificación persistente, y desde Android 10, ACCESS_BACKGROUND_LOCATION es un permiso en tiempo de ejecución separado que el usuario otorga deliberadamente en la configuración del sistema, no en el diálogo propio de la app.

#Una arquitectura por niveles

Por defecto colocaría a todo usuario en un nivel inactivo barato — actualizaciones de cambio significativo en iOS, ubicación fusionada de potencia balanceada en Android — que despierta la app con poca frecuencia y le indica aproximadamente dónde está el dispositivo. Encima de eso, registraría geocercas alrededor del puñado de puntos de interés que a la función realmente le importan (una tienda, una dirección de entrega, un campus), lo cual no cuesta nada mientras el usuario está lejos y dispara un evento justo cuando importa. Solo cuando ese evento promueve la sesión a activa — un viaje comenzó, un pedido salió para entrega — pasaría a GPS de alta precisión acotado, y solo durante esa sesión, con un indicador visible (la píldora azul de ubicación en segundo plano de iOS, la notificación de foreground service de Android) para que el usuario siempre sepa cuándo está corriendo el nivel costoso. En el momento en que la sesión termina, volvería directo al nivel inactivo en lugar de dejar corriendo el sondeo de alta precisión por comodidad.

#Privacidad por diseño, no como anexo de política

El diálogo de permisos es la parte menos interesante del diseño de privacidad; lo que pasa con los datos después importa más. Pediría 'Mientras se usa' por defecto y solo escalaría a 'Siempre' en el momento exacto en que la función lo necesita, con una explicación en lenguaje simple de qué se gana — pedirlo por adelantado durante el onboarding es la causa más común tanto de que el usuario lo niegue como de rechazo en la App Store. En el dispositivo, aplicaría un filtro de distancia y tiempo para que las actualizaciones solo se generen cuando la posición realmente cambió, y truncaría la precisión antes de que algo salga del dispositivo a menos que la función necesite explícitamente precisión a nivel de casa — un mapa de fitness no necesita saber en qué sala de examen de un hospital está el usuario. Del lado del servidor, pondría un TTL corto al historial de ubicación cruda, agregaría o eliminaría los datos pasada esa ventana, y le daría al usuario un control real y funcional de eliminar su historial de ubicación en lugar de un ticket de soporte. Y dado que desde iOS 14 el usuario puede otorgar ubicación Aproximada en vez de Precisa, me aseguraría de que el nivel aproximado de mi propia arquitectura sea genuinamente útil bajo esa restricción en lugar de tratarlo como un modo degradado y sin soporte.

#Modos de fallo que vale la pena nombrar en la entrevista

Algunos casos límite separan una respuesta senior de una superficial. Los usuarios pueden revocar el permiso de ubicación mientras la app está en segundo plano a mitad de una sesión, así que el código de rastreo tiene que manejar que la autorización cambie debajo de él, no solo verificarla una vez al iniciar. El GPS se degrada mucho en interiores y en cañones urbanos, así que diseñaría un respaldo hacia la última posición buena conocida más un indicador de antigüedad, en lugar de mostrar un pin confiadamente incorrecto. El sistema operativo puede matar, y va a matar, una app en segundo plano para recuperar memoria o batería (Doze mode, App Standby Buckets, el presupuesto de ejecución en segundo plano de iOS), así que cualquier cosa que deba sobrevivir debería entregarse a un programador durable — WorkManager en Android, BGTaskScheduler en iOS — en lugar de un timer crudo. Y el límite de 20 regiones en el geofencing de iOS implica que una función que quiera vigilar más puntos de interés que eso tiene que re-registrar dinámicamente las N regiones más cercanas a medida que el usuario se mueve, no simplemente fallar en silencio al superar el límite.

#Tradeoffs que expondría sin que me los pregunten

Cerraría nombrando los tradeoffs explícitamente en lugar de esperar a que me los pregunten. El cambio significativo y el geofencing son mucho más baratos en batería que el GPS continuo, pero introducen latencia real — hasta 500 metros de movimiento antes de que la app siquiera despierte — así que cualquier función que prometa rastreo en vivo por debajo del segundo tiene que aceptar el costo del nivel caro durante esa ventana acotada. Aproximar la precisión por privacidad reduce directamente la exactitud con la que puede contar el resto del producto, así que tiene que ser una decisión de producto, no solo un valor por defecto de ingeniería. Y una consulta de ubicación puntual disparada por un push silencioso puede reemplazar por completo el rastreo continuo en segundo plano para casos de uso que solo necesitan una posición fresca de vez en cuando, como saber dónde está el repartidor ahora mismo, cambiando un poco de antigüedad del dato por una gran reducción tanto en costo de batería como en superficie de privacidad — normalmente esa es la primera alternativa que propondría antes de siquiera considerar el rastreo en segundo plano.