Introduction

You can guide users back to location access after they deny it, but you usually cannot keep showing the system prompt whenever you want. The right approach depends on both the platform and the exact denial state: app permission denied, global location services disabled, or a permanent denial that now requires the user to visit Settings.

First Separate Permission Denial from Location Services Being Off

These are not the same problem.

Possible situations include:

• the app does not have location permission
• the device’s location services are disabled globally
• the user denied permission and the system no longer wants to show the prompt again

If you do not separate these states, the app ends up showing the wrong explanation or taking the user to the wrong screen.

iOS: You Cannot Force a Second System Prompt After Denial

On iOS, once the user has denied location access, the app cannot programmatically trigger the original permission alert again on demand. The usual pattern is:

1. detect the denied status
2. explain why the feature needs location
3. send the user to the app’s Settings screen

Example in Swift:

1import CoreLocation
2import UIKit
3
4final class LocationCoordinator: NSObject, CLLocationManagerDelegate {
5    private let manager = CLLocationManager()
6
7    override init() {
8        super.init()
9        manager.delegate = self
10    }
11
12    func requestAccess(from presenter: UIViewController) {
13        switch manager.authorizationStatus {
14        case .notDetermined:
15            manager.requestWhenInUseAuthorization()
16        case .denied, .restricted:
17            let alert = UIAlertController(
18                title: "Location Disabled",
19                message: "Enable location in Settings to use nearby results.",
20                preferredStyle: .alert
21            )
22            alert.addAction(UIAlertAction(title: "Cancel", style: .cancel))
23            alert.addAction(UIAlertAction(title: "Open Settings", style: .default) { _ in
24                if let url = URL(string: UIApplication.openSettingsURLString) {
25                    UIApplication.shared.open(url)
26                }
27            })
28            presenter.present(alert, animated: true)
29        case .authorizedAlways, .authorizedWhenInUse:
30            manager.startUpdatingLocation()
31        @unknown default:
32            break
33        }
34    }
35}

This is the standard iOS recovery path: explain, then deep-link to Settings.

Android: You May Be Able to Ask Again

Android has more states to consider. If the user denied the permission once, you may still be able to request it again after showing rationale UI. If the user selected a permanent-denial path, the app usually has to send them to Settings.

A modern permission request flow often uses ActivityResultContracts.RequestPermission() together with shouldShowRequestPermissionRationale().

1class MainActivity : AppCompatActivity() {
2
3    private val requestLocation =
4        registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted ->
5            if (granted) {
6                println("Location granted")
7            } else {
8                println("Location denied")
9            }
10        }
11
12    fun askForLocation() {
13        when {
14            ContextCompat.checkSelfPermission(
15                this,
16                Manifest.permission.ACCESS_FINE_LOCATION
17            ) == PackageManager.PERMISSION_GRANTED -> {
18                println("Already granted")
19            }
20            ActivityCompat.shouldShowRequestPermissionRationale(
21                this,
22                Manifest.permission.ACCESS_FINE_LOCATION
23            ) -> {
24                showRationaleThenRequest()
25            }
26            else -> {
27                requestLocation.launch(Manifest.permission.ACCESS_FINE_LOCATION)
28            }
29        }
30    }
31
32    private fun showRationaleThenRequest() {
33        AlertDialog.Builder(this)
34            .setTitle("Location needed")
35            .setMessage("Allow location to show nearby places.")
36            .setPositiveButton("Continue") { _, _ ->
37                requestLocation.launch(Manifest.permission.ACCESS_FINE_LOCATION)
38            }
39            .setNegativeButton("Cancel", null)
40            .show()
41    }
42}

This is better than immediately re-requesting because it gives users context before the system dialog appears again.

When the User Must Go to Settings

If the system will not show the permission dialog again, the next step is usually to send the user to the app’s settings page instead of pretending the app can recover silently.

Android example:

1val intent = Intent(
2    Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
3    Uri.fromParts("package", packageName, null)
4)
5startActivity(intent)

This pattern is conceptually similar to iOS: once the permission has reached a certain denied state, your job is to explain and route the user to Settings, not to keep trying the same prompt.

Global Location Services Can Require a Different Prompt

Sometimes permission is granted, but the device-level location setting is off. On Android, Google Play services provides a settings resolution flow for this case. On iOS, you generally direct the user to Settings because the issue is outside the app’s direct control.

So the right UX is often:

• denied permission: explain app access and route to app settings
• location services disabled: explain device setting and route to system settings

Those are different conversations with the user.

Good UX Matters More Than Re-Prompting Aggressively

Permission recovery works better when the request is contextual. Ask when the user taps a feature that clearly needs location, not immediately at app launch. If they deny access, explain the benefit in concrete terms such as:

• show nearby stores
• enable turn-by-turn navigation
• attach current location to a report

Users are much more likely to grant permissions when the reason is obvious at the point of need.

Common Pitfalls

• Treating app-level denial and device-level location-services disablement as the same state.
• Trying to force a second system prompt on iOS after the user has already denied access.
• Re-requesting Android permission immediately without rationale when the system recommends explanation first.
• Sending users to Settings without explaining why location is needed for the feature they just tried to use.
• Asking for location too early, before the user has any context for why the app wants it.

Summary

• After denial, the recovery flow depends on platform and permission state.
• On iOS, you generally cannot re-show the system prompt after denial, so you explain and deep-link to Settings.
• On Android, you may be able to request again, especially when rationale UI is appropriate.
• If the permission is effectively permanently denied, send the user to app settings instead of looping the request.
• Always explain the feature benefit clearly, because good permission UX matters more than aggressive prompting.