{"id":"l-rn-4-3","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Ask for location and camera access at the moment it makes sense, handle every permission state including permanent denial, and write the usage descriptions iOS and app review require.","html":"

Trailhead’s best feature is live tracking: start a hike, and the app records your route. It needs the phone’s location, and the phone won’t give it without asking the user. That request is the most fragile moment in the app. Ask badly and you lose the feature for that user, sometimes for good.

\n

The states a permission can be in

\n

Every Expo module that needs a permission (location, camera, media library, notifications) returns the same response shape:

\n
TypeScript
{\n  status: 'undetermined' | 'granted' | 'denied',\n  granted: boolean,\n  canAskAgain: boolean,\n  expires: 'never' | number,\n}
\n\n
\n From undetermined, the app explains and then requests. The user grants or denies. Granted proceeds to the feature. Denied with canAskAgain true can be requested again; denied with canAskAgain false can only be changed by opening Settings.\n \n undetermined\n \n \n explain, then\n request…()\n \n \n \n granted → feature\n \n denied\n canAskAgain?\n \n yes\n no → open Settings\n \n
Where each permission state leads
\n

Ask in context, once you’ve explained

\n

The worst pattern is the one many apps ship: a cascade of system prompts at first launch, before the user knows what the app does. People deny what they don’t understand, and on iOS that first “Don’t Allow” is permanent unless they dig into Settings.

\n

Trailhead asks for location when the user taps Start tracking, the first moment the request is obviously connected to something they want. Before the system prompt, it shows its own short explanation: “Trailhead records your route while you hike. Your location stays on this phone unless you sync.” Then a Continue button triggers the real request. Your own screen can be dismissed without consequence; the system prompt can’t.

\n

The same rule applies to every permission in the app. Ask for the camera when the user taps Add photo, and for notifications when they turn on reminders, not before. Each request then arrives with its reason already visible on screen, and acceptance rates go up noticeably.

\n
src/hooks/useLocationPermission.ts
import * as Location from 'expo-location';\nimport { useFocusEffect } from 'expo-router';\nimport { useCallback, useState } from 'react';\nimport { Linking } from 'react-native';\n\nexport function useLocationPermission() {\n  const [permission, setPermission] = useState<Location.LocationPermissionResponse | null>(null);\n\n  // Re-check whenever the screen regains focus: the user may have\n  // changed the setting in the Settings app while Trailhead was in the background.\n  useFocusEffect(\n    useCallback(() => {\n      Location.getForegroundPermissionsAsync().then(setPermission);\n    }, []),\n  );\n\n  const request = useCallback(async () => {\n    const result = await Location.requestForegroundPermissionsAsync();\n    setPermission(result);\n    return result.granted;\n  }, []);\n\n  return { permission, request, openSettings: () => Linking.openSettings() };\n}
\n

The tracking screen then reads permission and chooses what to render: a spinner while it’s null, the explanation and Continue button while asking is still possible, a “Location is off for Trailhead” message with an Open Settings button once canAskAgain is false, and the live map once it’s granted. Turning the response into one of those four actions is a small pure function, and it’s this lesson’s exercise.

\n\n

Usage descriptions and config plugins

\n

iOS shows a sentence from your app in every permission prompt, and the App Store rejects apps whose descriptions are missing or vague (“This app needs your location”). Say what the feature does with the data. You set these strings through each module’s config plugin in app.json:

\n
app.json
{\n  \"expo\": {\n    \"plugins\": [\n      [\n        \"expo-location\",\n        { \"locationWhenInUsePermission\": \"Trailhead records your route on the map while you track a hike.\" }\n      ],\n      [\n        \"expo-image-picker\",\n        {\n          \"photosPermission\": \"Trailhead lets you attach photos from your library to a hike.\",\n          \"cameraPermission\": \"Trailhead lets you take trail photos to attach to a hike.\"\n        }\n      ]\n    ]\n  }\n}
\n

Config plugins write native configuration (the iOS Info.plist, the Android manifest) when the app is built. That makes them native changes: Fast Refresh won’t apply them, so rebuild your development build after editing them. Expo Go shows its own generic strings, which is one more reason Trailhead moves to a development build now.

\n

Foreground first, background only if you must

\n

Tracking a hike with the screen off needs background location, a separate, more sensitive permission with extra platform requirements and closer review on both stores. Start with foreground (“while using the app”) access, which covers tracking while Trailhead is open. Add background access only when users ask for it, with a clear explanation of why, and expect the review to ask you the same question.

\n

Next you’ll use these permissions for real: the hiker’s position, trail photos, and a reminder notification.

\n","toc":[{"id":"sec-1","text":"The states a permission can be in","level":2},{"id":"sec-2","text":"Ask in context, once you’ve explained","level":2},{"id":"sec-3","text":"Usage descriptions and config plugins","level":2},{"id":"sec-4","text":"Foreground first, background only if you must","level":2}],"takeaways":["Permission responses have a status of undetermined, granted or denied, plus canAskAgain, which tells you whether a system prompt can still appear.","Ask when the user starts the feature that needs it, after a short explanation in your own UI, never as a wall of prompts at launch.","Once canAskAgain is false, only the system Settings app can change the answer, so offer a button that calls Linking.openSettings().","iOS requires a usage description for each permission; set them through config plugin options in app.json and rebuild.","Re-check permissions when a screen regains focus, because users change them in Settings while your app is in the background."],"further":[{"title":"Permissions","url":"https://docs.expo.dev/guides/permissions/"},{"title":"Location","url":"https://docs.expo.dev/versions/latest/sdk/location/"},{"title":"Linking","url":"https://reactnative.dev/docs/linking"}],"quiz":[{"q":"

Trailhead asks for location the first time the app launches, before the user has seen anything. On iOS, many users tap Don’t Allow. Why does this matter so much?

","options":[{"text":"The app is rejected from the App Store for asking at launch.","why":"Asking at launch isn’t automatically a rejection. The real cost is to your users and features."},{"text":"After a denial, iOS won’t show the system prompt again; only the Settings app can change it, so the tracking feature is effectively gone for those users.","why":"Correct. You get one system prompt per permission on iOS, so spend it when the user understands why."},{"text":"Denying at launch also denies camera and notification permissions.","why":"Each permission is answered separately. The damage is to location only, but it’s lasting."}],"answer":1},{"q":"

A permission response is { status: 'denied', granted: false, canAskAgain: false }. What should the Start tracking button do?

","options":[{"text":"Call requestForegroundPermissionsAsync() again; the user may have changed their mind.","why":"With canAskAgain false, the request resolves immediately with the same denial and no prompt appears."},{"text":"Hide the button permanently.","why":"The user may want the feature later. Hiding it gives them no path back."},{"text":"Explain that location is off for Trailhead and offer a button that opens the app’s page in Settings.","why":"Correct. Linking.openSettings() takes them straight to the switch they need."},{"text":"Start tracking anyway and show an error if it fails.","why":"The location calls will reject; starting a feature you know can’t work is a worse experience than explaining."}],"answer":2},{"q":"

You change the location usage description in app.json, reload with Fast Refresh, and the old text still appears in the prompt. Why?

","options":[{"text":"The description is part of the native app configuration, so it only changes in a new build.","why":"Correct. Usage strings are compiled into Info.plist; rebuild the development build to see them."},{"text":"iOS caches prompt text for 24 hours.","why":"There’s no such cache; the text comes from the installed binary."},{"text":"The description must be set in JavaScript with Location.setDescription().","why":"There’s no such function. Usage descriptions are native configuration, not runtime calls."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// Decide what the tracking screen shows for a permission response.\n// Returns one of: 'wait' | 'proceed' | 'ask' | 'open-settings'\nfunction permissionAction(response) {\n if (response.status === 'granted') return 'proceed';\n return 'ask';\n}\n\nconsole.log(permissionAction({ status: 'denied', granted: false, canAskAgain: false, expires: 'never' }));\n"},"solution":{"js":"function permissionAction(response) {\n if (!response) return 'wait';\n if (response.granted) return 'proceed';\n if (response.status === 'undetermined') return 'ask';\n return response.canAskAgain ? 'ask' : 'open-settings';\n}\n\nconsole.log(permissionAction({ status: 'denied', granted: false, canAskAgain: false, expires: 'never' }));\n"},"checks":[{"id":"loading","test":"return typeof permissionAction === 'function' && permissionAction(null) === 'wait' && permissionAction(undefined) === 'wait';"},{"id":"granted","test":"return permissionAction({ status: 'granted', granted: true, canAskAgain: true, expires: 'never' }) === 'proceed';"},{"id":"undetermined","test":"return permissionAction({ status: 'undetermined', granted: false, canAskAgain: true, expires: 'never' }) === 'ask';"},{"id":"denied-can-ask","test":"return permissionAction({ status: 'denied', granted: false, canAskAgain: true, expires: 'never' }) === 'ask';"},{"id":"denied-final","test":"return permissionAction({ status: 'denied', granted: false, canAskAgain: false, expires: 'never' }) === 'open-settings';"}],"title":"Turn a permission response into a screen","prompt":"

Trailhead’s tracking screen calls permissionAction(response) to decide what to render. response is the object from getForegroundPermissionsAsync(), or null while it’s still loading. Return:

\n\n","hints":["Handle the loading case first, before you read any property of response.","granted is already a boolean, so you don’t need to compare status for that case.","For a denial, the only thing that matters is canAskAgain."],"explanation":"

The starter crashed on null (reading .status of nothing) and sent permanently denied users to a request that silently does nothing. The fixed function covers every state in a fixed order: loading, granted, then the two kinds of not-yet-granted. Because it’s pure, you can test all four branches in milliseconds, and the screen becomes a simple switch over four strings.

\n","checkLabels":{"loading":"A missing response means wait","granted":"A granted permission proceeds","undetermined":"A permission never asked for leads to asking","denied-can-ask":"A denial that can be asked again leads to asking","denied-final":"A permanent denial leads to Settings"}},"words":657,"readMinutes":3}