Location Permission es un permiso que una aplicación móvil solicita al usuario para acceder a los datos de su ubicación geográfica. Sin este permiso, la aplicación no puede determinar las coordenadas del dispositivo y, por lo tanto, no puede proporcionar funciones de geolocalización. Según Apple Developer Documentation, 2024, todas las aplicaciones que utilizan servicios de geolocalización deben solicitar el consentimiento explícito del usuario a través de un diálogo del sistema.
Puntos clave
Location Permission es un mecanismo del sistema operativo que regula el acceso de las aplicaciones a los datos de ubicación geográfica del dispositivo. Sin el consentimiento explícito del usuario, la aplicación no puede obtener coordenadas GPS, datos de redes Wi-Fi ni información de torres de telefonía móvil.
Las plataformas móviles Android e iOS implementan su propio sistema de permisos, pero la lógica general es la misma: la aplicación declara los permisos necesarios en el manifiesto o archivo de configuración, luego los solicita en tiempo de ejecución. Según Android Developers, 2024, a partir de Android 10, todos los permisos de geolocalización pertenecen a la categoría de peligrosos y requieren solicitud en tiempo de ejecución.
La razón de este enfoque es la protección de la privacidad del usuario. Los datos de ubicación permiten construir rutas de viaje, determinar lugares de trabajo y ocio, así como identificar a la persona. Por lo tanto, ambas plataformas requieren una explicación transparente en el diálogo de solicitud: la aplicación debe indicar la razón por la que necesita acceso a la geolocalización.
El permiso de geolocalización es necesario para cualquier aplicación cuya funcionalidad dependa del conocimiento de la ubicación física del usuario. Mapas y navegación, aplicaciones de entrega, servicios meteorológicos, redes sociales con geolocalización — todas estas categorías de software requieren Location Permission.
Sin este permiso, la aplicación no puede determinar las coordenadas del dispositivo por ninguno de los métodos disponibles: ni a través del módulo GPS, ni mediante escaneo Wi-Fi, ni por posicionamiento de torres de telefonía. El usuario puede revocar el permiso en cualquier momento en la configuración del sistema, tras lo cual la aplicación debe manejar correctamente la denegación.
Según un estudio de Pew Research Center (2024), aproximadamente el 45% de los usuarios revocan el acceso a la geolocalización en aplicaciones que no lo utilizan para su funcionalidad principal. Esto significa que el desarrollador debe justificar claramente la solicitud y ofrecer mecanismos alternativos para quienes rechazaron Location Permission.
El GDPR en Europa y la Ley Federal 152-FZ en Rusia exigen obtener el consentimiento informado para el procesamiento de datos de ubicación. La aplicación no solo debe solicitar el permiso a través del diálogo del sistema, sino también proporcionar un aviso separado sobre los fines de la recopilación de datos. La violación de estos requisitos conlleva multas de hasta 20 millones de euros o el 4% de la facturación anual de la empresa.
Si la aplicación no solicita Location Permission o el usuario deniega el acceso, el desarrollador debe prever un escenario alternativo. Para una aplicación de mapas, podría ser la introducción manual de la dirección; para una aplicación de entrega — la selección de una lista de direcciones guardadas; para un servicio meteorológico — la determinación de la ciudad por dirección IP. Graceful degradation (degradación gradual) es una práctica estándar recomendada por Google y Apple.
Los niveles de acceso a la geolocalización difieren en Android e iOS, aunque la idea general es la misma: cuanto más preciso es el acceso, más estrictos son los requisitos que la plataforma impone a la aplicación.
| Nivel de acceso | Android | iOS |
|---|---|---|
| Durante el uso | Solo cuando la aplicación está activa | When In Use — solo en la aplicación |
| En segundo plano | Always — constantemente, incluso en segundo plano | Always — requiere revisión adicional de App Store |
| Aproximado | ACCESS_COARSE_LOCATION (precisión hasta 500 m) | Con opción Precision = Off (iOS 14+) |
ACCESS_FINE_LOCATION proporciona acceso a coordenadas GPS precisas con un margen de error de hasta varios metros. Para declarar este permiso en el manifiesto se utiliza la constante android.permission.ACCESS_FINE_LOCATION. ACCESS_COARSE_LOCATION, por su parte, proporciona una ubicación aproximada con una precisión de hasta 500 metros basada en datos de Wi-Fi y torres de telefonía.
When In Use permite a la aplicación recibir coordenadas solo cuando está abierta en pantalla. Always proporciona acceso a la geolocalización incluso en segundo plano, pero requiere una revisión obligatoria en App Store. A partir de iOS 14, el usuario puede desactivar por separado el posicionamiento preciso para cada aplicación mediante el interruptor Precision.
La solicitud de Location Permission en Android se realiza en dos etapas: declaración de permisos en el manifiesto y solicitud en tiempo de ejecución. A partir de Android 6.0 (API 23), todos los permisos peligrosos se solicitan durante la ejecución de la aplicación, no durante la instalación.
El primer paso es agregar los permisos necesarios al archivo AndroidManifest.xml. Se utilizan diferentes constantes para el posicionamiento preciso y aproximado.
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
Después de la declaración en el manifiesto, se debe llamar al diálogo del sistema de solicitud de permiso en el código de la aplicación. Veamos un ejemplo en Kotlin usando Activity Result API.
private val locationPermissionRequest =
registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
when {
permissions.getOrDefault(Manifest.permission.ACCESS_FINE_LOCATION, false) -> {
// Permiso concedido
getLocation()
}
permissions.getOrDefault(Manifest.permission.ACCESS_COARSE_LOCATION, false) -> {
// Solo ubicación aproximada
getCoarseLocation()
}
else -> {
// Usuario denegó
showLocationExplanation()
}
}
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
checkLocationPermission()
}
Si el usuario deniega el acceso, el sistema Android no permite volver a mostrar el diálogo automáticamente. El desarrollador debe llamar a shouldShowRequestPermissionRationale para mostrar una explicación preliminar. En caso de denegación repetida con la marca Never Ask Again, se debe redirigir al usuario a la configuración del sistema.
private fun checkLocationPermission() {
when {
ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ==
PackageManager.PERMISSION_GRANTED -> {
getLocation()
}
ActivityCompat.shouldShowRequestPermissionRationale(this,
Manifest.permission.ACCESS_FINE_LOCATION) -> {
showRationaleDialog {
requestLocationPermission()
}
}
else -> {
openAppSettings()
}
}
}
La solicitud de Location Permission en iOS requiere agregar claves especiales al archivo Info.plist y llamar a métodos de la clase CLLocationManager. Apple presta especial atención a la privacidad, por lo que el texto de explicación en el diálogo de solicitud debe ser lo más específico posible.
Para solicitar la ubicación en iOS, es necesario agregar una o ambas claves al Info.plist: NSLocationWhenInUseUsageDescription para el acceso durante el uso y NSLocationAlwaysAndWhenInUseUsageDescription para el acceso en segundo plano. El valor de cada clave es una cadena que se mostrará al usuario en el diálogo.
<key>NSLocationWhenInUseUsageDescription</key>
<string>Tu aplicación necesita tu ubicación para mostrar puntos cercanos en el mapa.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Tu aplicación necesita acceso a la geolocalización en segundo plano para rastrear la ruta.</string>
En código Swift, la solicitud se realiza a través de una instancia de CLLocationManager. Dependiendo del nivel de acceso requerido, se llama a requestWhenInUseAuthorization o requestAlwaysAuthorization.
import CoreLocation
class LocationManager: NSObject, CLLocationManagerDelegate {
private let manager = CLLocationManager()
func requestLocationAccess() {
manager.delegate = self
manager.requestWhenInUseAuthorization()
}
func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
switch manager.authorizationStatus {
case .authorizedWhenInUse, .authorizedAlways:
startLocationUpdates()
case .denied, .restricted:
showSettingsAlert()
case .notDetermined:
break
}
}
}
A diferencia de Android, iOS no proporciona al desarrollador un método para verificar shouldShowRequestPermissionRationale. El sistema decide por sí mismo cuándo mostrar la explicación. Además, en iOS el usuario solo puede cambiar el permiso a través de la configuración del sistema — la aplicación no puede volver a mostrar el diálogo del sistema después de que el usuario haya tomado una decisión. RequestAlwaysAuthorization primero solicita When In Use y luego, después de obtener el primer consentimiento, un diálogo separado para el acceso en segundo plano.
Las mejores prácticas con Location Permission ayudan a reducir las denegaciones de los usuarios y cumplir con los requisitos de las tiendas de aplicaciones. Google y Apple han publicado recomendaciones cuyo cumplimiento aumenta la probabilidad de aprobación de la aplicación.
No muestres el diálogo de solicitud de Location Permission inmediatamente al iniciar la aplicación. Un usuario que acaba de abrir la aplicación aún no comprende por qué debe proporcionar acceso a la geolocalización. Contextual request implica que el diálogo aparece en el momento en que el usuario realmente necesita una función que requiere permiso. Por ejemplo, al pulsar el botón “Buscar tienda más cercana”.
Antes del diálogo del sistema, muestra tu propia pantalla de explicación (pre-permission screen). En ella, explica por qué la aplicación necesita la geolocalización, qué datos se recopilan y cómo se utilizarán. Después de que el usuario haga clic en “Permitir” en tu pantalla, muestra el diálogo del sistema. Según Appsflyer (2024), este enfoque aumenta la tasa de aprobación en un 25-35%.
El acceso en segundo plano a la geolocalización solo es necesario para aplicaciones que funcionan en segundo plano: navegadores, rastreadores de actividad, aplicaciones de entrega. Si tu aplicación solo necesita coordenadas cuando la pantalla está abierta, solicita When In Use. App Store rechazará la aplicación si Always no está justificado funcionalmente. En Android, el acceso en segundo plano se regula adicionalmente mediante el permiso ACCESS_BACKGROUND_LOCATION.
Preguntas frecuentes
La aplicación debe manejar correctamente la denegación y ofrecer un escenario alternativo. Por ejemplo, la introducción manual de la dirección o la determinación de la ciudad por dirección IP. El diálogo del sistema no se muestra nuevamente — es necesario redirigir al usuario a la configuración.
Técnicamente, sí — se puede mostrar el diálogo del sistema sin una pantalla previa. Sin embargo, la tasa de aprobación sin explicación es del 30-40%, mientras que con una pantalla previa es del 60-75%. Apple y Google recomiendan explicar siempre el motivo de la solicitud.
Usa ContextCompat.checkSelfPermission con la constante Manifest.permission.ACCESS_FINE_LOCATION. El método devuelve PERMISSION_GRANTED o PERMISSION_DENIED, lo que permite determinar el estado actual sin llamar al diálogo del sistema.
ACCESS_FINE_LOCATION proporciona acceso a coordenadas GPS precisas con un error de 3-10 metros. ACCESS_COARSE_LOCATION proporciona una ubicación aproximada con una precisión de hasta 500 metros basada en Wi-Fi y torres de telefonía. En Android 12+, el desarrollador puede solicitar ambos permisos simultáneamente.
En Android, para escanear dispositivos BLE se requiere ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION, ya que las señales BLE pueden usarse para triangulación de posición. En iOS, para BLE solo se necesita el permiso de Bluetooth — no se requiere Location Permission.
Resumen
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también