Request Location Permissions

Request foreground and background location on iOS and Android, with the purpose strings the app stores actually require.

This guide covers requesting location permissions correctly on iOS and Android, including the platform-specific requirements that cause store rejections or crashes if skipped.

Quick Answer

Add usage description strings on iOS (Info.plist) and the location permissions on Android (AndroidManifest.xml), request permission at a point in the app where the reason is obvious to the user, and only request background location if you genuinely need it, since it comes with extra store scrutiny.

1. iOS: Usage Description Strings

iOS requires a human-readable purpose string for each type of location access, or the app crashes on launch the first time it tries to access location, not just fails gracefully:

NSLocationWhenInUseUsageDescription for foreground-only access;
NSLocationAlwaysAndWhenInUseUsageDescription if you also need background access.

Write a specific, honest reason ("to show nearby restaurants"), not a generic placeholder; vague strings are a common App Store review rejection reason.

2. Android: Manifest Permissions

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

Only include ACCESS_BACKGROUND_LOCATION if you actually need it; Android Runtime permission requests must ask for foreground access first, and background access as a clearly separate, later request.

3. Request at the Right Moment

Don't request location permission on app launch before the user has any context for why. Ask immediately before the feature that needs it (e.g. when the user taps "Find nearby"), so the system permission dialog has an obvious reason attached.

4. Handle Permanent Denial

If a user denies permission and later denies again (or selects "Don't ask again" on Android), the OS stops showing the system prompt entirely. Detect this state and show your own UI explaining how to enable it manually, with a deep link to the app's Settings page, rather than silently failing.

5. Background Location Requires Justification

Both stores require you to explain, in your store listing/privacy details, exactly why the app needs background location, and reject apps that request it without a clear, feature-driven reason (e.g. live delivery tracking is fine; requesting it "just in case" is not).

Common Issues

App crashes immediately on iOS when a location API is called the corresponding Info.plist usage string is missing entirely, not just denied.

Permission denied forever with no way to re-prompt expected OS behavior after repeated denial; you must deep link to Settings, you cannot force the system dialog to reappear.

App rejected in review for background location the store listing didn't clearly justify why background access is needed.

Location works in the foreground but never updates in the background background permission was requested but the corresponding background modes/services weren't also configured on the native side.

Verification Checklist

all required Info.plist usage strings are present and specific;
Android manifest only requests the location permissions actually used;
permission is requested at the point of use, not on launch;
permanent denial is detected and routes the user to Settings;
background location (if used) has a clear justification recorded for store review.