権限の適切な処理
リクエスト前に権限の状態を確認し、ユーザーに状況に応じた説明を表示して、権限が拒否された場合は機能を適切に縮退させます
「権限の適切な処理」はCoddyKit上の無料React Native Academyレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはReact Native Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 React Native Academyコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
Why Permission Handling Matters
iOS and Android require explicit user consent before an app can access sensitive capabilities like the camera, location, microphone, or contacts. How you ask for and respond to permission decisions significantly affects user trust and app ratings. A poorly timed or unexplained permission request often results in denial, and once denied, the only recovery path is the device's Settings app.
Permission Lifecycle: The Four States
A permission can be in one of four states: undetermined (never asked yet), granted (user allowed it), denied (user said no during the last prompt), and restricted (iOS — blocked by parental controls, cannot be changed). Your app must handle each state correctly and never assume a permission is granted without checking.
import { PermissionStatus } from 'expo-location';
const { status } = await Location.getForegroundPermissionsAsync();
switch (status) {
case PermissionStatus.UNDETERMINED:
// Safe to call requestForegroundPermissionsAsync()
break;
case PermissionStatus.GRANTED:
// Proceed with the feature
break;
case PermissionStatus.DENIED:
// Show instructions to open Settings
break;
}Check Before Requesting
Always check the current permission status with a get*Async call before calling request*Async. If the permission is already granted, skip the request dialog. If it was already denied, do not re-prompt — iOS will silently ignore the request and Android will briefly flash a snackbar. Only prompt when status is undetermined.
async function ensureCameraPermission(): Promise<boolean> {
const { status } = await Camera.getCameraPermissionsAsync();
if (status === 'granted') return true;
if (status === 'undetermined') {
const { status: newStatus } = await Camera.requestCameraPermissionsAsync();
return newStatus === 'granted';
}
// status === 'denied' — direct user to Settings
return false;
}Contextual Pre-Permission Rationale
Before triggering the OS permission dialog, show the user a custom rationale screen that explains in plain language why your app needs the permission and how it benefits them. This 'prime' screen dramatically increases grant rates. It should appear right before the system dialog, not during onboarding before any feature context is established.
function LocationRationale({ onConfirm }: { onConfirm: () => void }) {
return (
<View style={styles.rationale}>
<Ionicons name='location-outline' size={48} color='#6200ee' />
<Text style={styles.title}>Share your location</Text>
<Text style={styles.body}>
We use your location to show nearby restaurants and
calculate accurate delivery times.
</Text>
<Button title='Allow Location' onPress={onConfirm} />
<Button title='Not Now' onPress={() => {}} color='gray' />
</View>
);
}Linking to App Settings When Denied
When a user has denied a permission and the feature cannot work without it, guide them to the device Settings app to manually grant it. Use Linking.openSettings() from React Native to open the app's settings page directly. Explain in an alert what they need to enable before calling openSettings.
import { Linking, Alert } from 'react-native';
function showSettingsPrompt(feature: string) {
Alert.alert(
feature + ' Access Denied',
'Please enable ' + feature + ' access in your device Settings to use this feature.',
[
{ text: 'Cancel', style: 'cancel' },
{ text: 'Open Settings', onPress: () => Linking.openSettings() },
]
);
}Graceful Degradation
Graceful degradation means your app still works — with reduced functionality — when a permission is denied. For example, a food delivery app denied location access can show a manual address input instead of auto-detecting the address. Design every permission-gated feature with a fallback path so no user is completely blocked from the app's core value.
export default function LocationPicker() {
const [permission] = Location.useForegroundPermissions();
const granted = permission?.granted;
if (granted) {
return <MapWithAutoLocation />; // use GPS
}
return <ManualAddressInput />; // fallback — type address manually
}canAskAgain: One Chance to Re-Request
The permission result object includes a canAskAgain property. On iOS, once the user taps 'Don't Allow' on the system dialog, canAskAgain becomes false and the system will never show the dialog again for that permission. On Android, it becomes false after the user denies twice. Always check this flag to decide whether to show the re-prompt button or the Settings link.
const { status, canAskAgain } = await Camera.requestCameraPermissionsAsync();
if (status !== 'granted') {
if (canAskAgain) {
// Show in-app explanation and re-request button
setShowRationale(true);
} else {
// Show link to Settings — OS won't show dialog again
showSettingsPrompt('Camera');
}
}Handling Multiple Permissions
Some features require multiple permissions simultaneously — for example a media picker needs both camera and media library access. Request them in sequence, checking each result before requesting the next. If any permission is denied, handle it and stop — do not proceed to the next request so users are not overwhelmed by multiple system dialogs in rapid succession.
async function requestMediaFeaturePermissions() {
const { status: cameraStatus } = await Camera.requestCameraPermissionsAsync();
if (cameraStatus !== 'granted') {
showSettingsPrompt('Camera');
return false;
}
const { status: mediaStatus } = await MediaLibrary.requestPermissionsAsync();
if (mediaStatus !== 'granted') {
showSettingsPrompt('Media Library');
return false;
}
return true;
}Persisting Permission State
You do not need to persist permission state in AsyncStorage — always query it fresh with get*Async calls because the user can change permissions in device Settings between app sessions. However, you can persist a flag like hasSeenPermissionRationale in AsyncStorage so you only show your custom rationale screen once and do not re-show it on every app launch.
async function maybeShowRationale() {
const seen = await AsyncStorage.getItem('seenLocationRationale');
if (!seen) {
setShowRationale(true);
await AsyncStorage.setItem('seenLocationRationale', 'true');
} else {
// Rationale seen before — go straight to checking permission
await checkLocationPermission();
}
}Testing Permission Flows
Test all four permission states: first launch (undetermined), granted, denied, and denied with canAskAgain=false. On iOS Simulator, reset permissions via Device Settings app. On Android Emulator, use App Info to revoke permissions manually. Also test the Settings link — make sure it opens the correct per-app settings page, not the general device settings screen.
A Reusable Permission Hook
Encapsulate the full permission lifecycle — check, rationale, request, and Settings fallback — into a reusable custom hook. The hook returns the current status and a function to trigger the permission request. This eliminates duplicated permission handling code across multiple screens that need the same capability.
function useCameraPermission() {
const [status, setStatus] = React.useState<string>('undetermined');
async function request() {
const { status: s, canAskAgain } = await Camera.requestCameraPermissionsAsync();
setStatus(s);
if (s !== 'granted' && !canAskAgain) {
showSettingsPrompt('Camera');
}
}
useEffect(() => {
Camera.getCameraPermissionsAsync().then(({ status: s }) => setStatus(s));
}, []);
return { status, granted: status === 'granted', request };
}Quick Check
Test your understanding of React Native Mobile Development concepts from this lesson.
Lesson Recap
In this lesson you learned: checking permission status before requesting prevents redundant system dialogs and handles already-denied states correctly, canAskAgain determines whether to re-prompt or direct users to Settings, and graceful degradation provides a fallback path so denied permissions don't completely block users from your app. Next up we explore forms and validation with react-hook-form.
よくある質問
「権限の適切な処理」レッスンは無料ですか？
はい。「権限の適切な処理」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、React Native Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 React Native Academyコースには全4レッスンが含まれています。
「権限の適切な処理」で何を学びますか？
リクエスト前に権限の状態を確認し、ユーザーに状況に応じた説明を表示して、権限が拒否された場合は機能を適切に縮退させます ブラウザで直接実行するハンズオンコードでReact Native Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
React Native Academyを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのReact Native Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「権限の適切な処理」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このReact Native Academyレッスンでコードを書いて実行できますか？
はい。すべてのReact Native Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。