Native Device APIs
Permissions, camera, location (using Expo modules or react-native libraries)
Animations & Gestures
Basic Animated API usage
Touchable & gesture basics
Code Organization & Optimization
Folder structure for scale
Performance tips
Testing
Basics of Jest & React Native Testing Library
Publishing Your App
Preparing for release (iOS/Android)
Building APK/IPA
Overview of App Store/Play Store submission
The Appearance module exposes information about the user's appearance preferences, such as their preferred color scheme (light or dark).
Launches an alert dialog with the specified title and message.
Optionally provide a list of buttons. Tapping any button will fire the respective onPress callback and dismiss the alert. By default, the only button will be an 'OK' button.
colorScheme = Appearance.getColorScheme();
if (colorScheme === 'dark') {
// Use dark color scheme
}Keyboard module to control keyboard events.
useEffect(() => {
const showSubscription = Keyboard.addListener('keyboardDidShow', () => {
setKeyboardStatus('Keyboard Shown');
});
const hideSubscription = Keyboard.addListener('keyboardDidHide', () => {
setKeyboardStatus('Keyboard Hidden');
});
return () => {
showSubscription.remove();
hideSubscription.remove();
};
}, []);Give information about current platform Android or IOS
<Text>OS</Text>
<Text style={styles.value}>{Platform.OS}</Text>
<Text>OS Version</Text>
<Text style={styles.value}>{Platform.Version}</Text>Understand the prerequisites for both Android and iOS app submissions.
Prepare your app's metadata, icons, and screenshots for submission.
Navigate App Store Connect for app submission and management.
Monitor app performance and user feedback after launch.
Specify permissions needed for your app in app.json.
In React Native, you deal with permissions on two levels:
Manifest/Config Declaration (Build-time)
Tells the OS that your app might use certain features.
Android → AndroidManifest.xml
iOS → Info.plist (must provide a usage description string)
#AndroidManifest.xml
<uses-permission android:name="android.permission.CAMERA" />
#Info.plist
<key>NSCameraUsageDescription</key> <string>We use your camera to let you scan QR codes</string>PermissionsAndroidReact Native built-in module to request/check Android runtime permissions.
Example: Requesting camera access:
import { PermissionsAndroid } from 'react-native';
async function requestCameraPermission() {
try {
const granted = await PermissionsAndroid.request(
PermissionsAndroid.PERMISSIONS.CAMERA,
{
title: 'Camera Access',
message: 'We need to use your camera to scan barcodes',
buttonNeutral: 'Ask Me Later',
buttonNegative: 'Cancel',
buttonPositive: 'OK',
},
);
if (granted === PermissionsAndroid.RESULTS.GRANTED) {
console.log('Camera permission granted');
} else {
console.log('Camera permission denied');
}
} catch (err) {
console.warn(err);
}
}No built-in PermissionsIOS module.
Most iOS permissions are triggered automatically the first time you use a related API (e.g., using the camera).
You must add keys to Info.plist (e.g., NSCameraUsageDescription) or the app will crash.
For more fine-grained control, you typically use a library like react-native-permissions.
react-native-permissions (Recommended)Handles both Android & iOS with a consistent API.
import { request, PERMISSIONS, RESULTS } from 'react-native-permissions';
async function askLocation() {
const result = await request(
Platform.select({
ios: PERMISSIONS.IOS.LOCATION_WHEN_IN_USE,
android: PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION,
})
);
if (result === RESULTS.GRANTED) {
console.log('Location granted');
}
}AspectAndroidiOS
| Manifest keys required | Yes (AndroidManifest.xml) |
Yes (Info.plist) |
| Runtime request needed | For "dangerous" permissions (e.g., camera, location) | Almost always auto-requested when API is first called |
| Permanent denial | "Never Ask Again" flag returned | User must re-enable in Settings app |
| Default allow | Some "normal" permissions auto-granted at install | None for sensitive APIs |
In React Native, you deal with permissions on two levels
Runtime Requests (Code-time)
Some permissions require asking the user while the app runs.
The API and UX differ between Android and iOS.
Prereqs
Install & log in: npm i -g eas-cli && eas login docs.expo.dev
Set identifiers:
app.json/app.config.ts → "android.package": "com.yourco.yourapp"
"ios.bundleIdentifier": "com.yourco.yourapp"
{
"cli": { "version": ">= 10.0.0" },
"build": {
"production": { "android": { "buildType": "app-bundle" }, "ios": { "simulator": false } }
},
"submit": { "production": {} }
}# iOS & Android production builds
eas build --platform all --profile production
# (optional) build and auto-submit in one go
eas build --platform all --profile production --auto-submitIf you didn’t use --auto-submit, run:
# Android
eas submit --platform android --profile production
# iOS
eas submit --platform ios --profile production
Android setup (one-time)
Google Play Developer account
Create a Service Account and upload its JSON key to EAS (to let CLI talk to Play) docs.expo.dev+1
iOS setup
App Store Connect account (Apple Developer Program)
EAS handles ASC API keys or you can log in with Apple when prompted docs.expo.dev
Full step-by-step store submission guides are here.
After your first store release, push over-the-air (OTA) JS/assets without rebuilding:
# install once
npx expo install expo-updates
# create a channel (e.g., production)
eas channel:create production
# publish an update
eas update --branch production --message "Fix login race condition"App icons, splash, screenshots, privacy details, content rating ready.
iOS: correct bundle identifier + provisioning, Push/Sign In entitlements if used.
Android: correct package name, Play Console app created, signing set up.
Versioning: bump version/buildNumber (iOS) and versionCode (Android) each release.
Runtime version (for OTA): configure runtimeVersion so EAS Update targets the right native build.
Check for any warnings or errors before submission.