Icons guide for Expo apps
A guide exists on how to use various types of icons in Expo apps, including vector icons, custom icon fonts, icon images, and icon buttons.
Expo & React Native · all subjects
guides
835 notes in this subject, read out of this brain and free to use. This is page 1 of 14.
ESLint and Prettier configuration for Expo
A guide is available on configuring ESLint and Prettier to format Expo projects.
Use TypeScript in Expo projects
An in-depth guide is available on configuring an Expo project with TypeScript or migrating an existing JavaScript project to TypeScript.
SafeAreaView component wraps content with safe area padding
The SafeAreaView component from react-native-safe-area-context is a regular View with safe area insets applied as extra padding or margin. You can directly wrap your screen component content with it to account for safe areas automatically.
useSafeAreaInsets return object structure
The useSafeAreaInsets hook returns an object with the following properties: top (number), right (number), bottom (number), left (number). Each value represents the inset distance for that edge.
React Navigation supports safe areas by default
React Navigation supports safe areas by default and uses react-native-safe-area-context as a peer dependency. No additional setup is required for safe area handling when using React Navigation.
SafeAreaView usage example
import { Text } from 'react-native'; import { SafeAreaView } from 'react-native-safe-area-context'; export default function HomeScreen() { return ( <SafeAreaView style={{ flex: 1 }}> <Text>Content is in safe area.</Text> </SafeAreaView> ); }
useSafeAreaInsets hook provides direct access to insets
The useSafeAreaInsets hook from react-native-safe-area-context provides direct access to safe area insets, allowing you to apply padding for each edge of a View. It returns an object with top, right, bottom, and left properties, each containing a number representing the inset value in pixels.
SafeAreaProvider required for non-Expo Router templates
If you are using a different Expo template without Expo Router installed, import and add SafeAreaProvider to the root component file (such as App.tsx) before using SafeAreaView in your screen components.
Web SSR requires special setup for SafeAreaProvider
If you are targeting the web with server-side rendering (SSR), you need to set up SafeAreaProvider according to the Web SSR section in the react-native-safe-area-context library documentation.
react-native-safe-area-context is included in default template
The library react-native-safe-area-context is installed as a peer dependency for Expo Router. If you created a project using the default template, you can skip installing it. Otherwise, install it by running npx expo install react-native-safe-area-context (or equivalent for yarn, pnpm, or bun).
Safe area prevents content overlap with device elements
Safe areas ensure app screen content is positioned correctly so it doesn't get overlapped by notches, status bars, home indicators, and other interface elements that are part of the device's physical hardware or controlled by the operating system. Without safe areas, content can be concealed by these interface elements on both Android and iOS.
useSafeAreaInsets hook example
import { Text, View } from 'react-native'; import { useSafeAreaInsets } from 'react-native-safe-area-context'; export default function HomeScreen() { const insets = useSafeAreaInsets(); return ( <View style={{ flex: 1, paddingTop: insets.top }}> <Text>Content is in safe area.</Text> </View> ); }
Splash screen icon file location and naming
Export the splash screen icon as a .png file and save it in the assets/images directory. By default, Expo uses splash-icon.png as the file name. If you change the file name, update the reference in the app config.
iOS splash screen caching in development builds (SDK 52 and earlier)
For SDK 52 and earlier, in iOS development builds, launch screens can sometimes remain cached between builds. Apple recommends clearing the derived data directory before rebuilding. Use: npx expo run:ios --no-build-cache (npm), yarn expo run:ios --no-build-cache (yarn), pnpm expo run:ios --no-build-cache (pnpm), or bun expo run:ios --no-build-cache (bun).
App icon file requirements
Export the app icon as a .png file and save it in the assets/images directory. By default, Expo uses icon.png as the file name. If you use a different file name, update the reference in the app config accordingly.
Splash screen configuration not available without Expo Prebuild
If your app does not use Expo Prebuild to generate the native android and ios directories, then changes in the app config related to splash screen will have no effect. For manual customization, see the expo-splash-screen package documentation on GitHub for installation in bare React Native projects.
iOS app icon requirements and guidelines
For iOS, follow the Apple Human Interface Guidelines. Use a .png file with dimensions of at least 512x512 pixels, preferably 1024x1024. The icon must be exactly square with no rounded corners or transparent pixels; the operating system will mask the icon appropriately. Make sure the icon fills the whole square. For SDK 54 and later, you can provide an Icon Composer .icon directory via ios.icon property.
Splash screen icon requirements
For splash screen icons, use a 1024x1024 image in .png format with a transparent background. Currently, only .png images are supported as splash screen icons in an Expo project; using another image format will cause production build failures.
expo-file-system local file storage and sharing
expo-file-system provides access to a file system stored locally on the device. Within Expo Go, each project has a separate file system and no access to other Expo projects' files. It can save content shared by other projects to the local filesystem, share local files with other projects, and is capable of uploading and downloading files from network URLs.
expo-sqlite database access and persistence
expo-sqlite package gives your app access to a database that can be queried through a WebSQL-like API. The database is persisted across restarts of your app. You can use it for importing an existing database, opening databases, creating tables, inserting items, querying and displaying results, and using prepared statements.
expo-secure-store for encrypted key-value storage
expo-secure-store provides a way to encrypt and securely store key-value pairs locally on the device. It is intended for small values such as tokens, keys, and other secrets.
Async Storage for unencrypted key-value storage
Async Storage is an asynchronous, unencrypted, persistent key-value storage for React Native apps. It has a simple API and is a good choice for storing small amounts of data that does not need encryption, such as user preferences or app state.
Navigation bar customization on Android
The Navigation Bar appears at the bottom of the screen on Android devices only. Use the expo-navigation-bar library's NavigationBar component to customize it. The setStyle method sets the navigation bar style (for example, 'dark' for dark style).
Status bar customization with expo-status-bar
The status bar appears at the top of the screen on both Android and iOS. Use the expo-status-bar library's StatusBar component to control appearance while the app is running. The style property controls appearance (for example, 'light' for light text instead of dark text for better contrast with dark backgrounds). The setStatusBarStyle method can also be used. In the Expo default template, the style property defaults to 'auto', which automatically picks the appropriate style depending on the current color scheme (light or dark mode).
Edge-to-edge layout on Android
With edge-to-edge display on Android, safe areas must be used to ensure content does not overlap with system bars. Previously, translucent status bars and navigation bars meant content behind them was already underneath, making safe areas less necessary.
System bars definition and components
System bars are UI elements at the edges of the screen that provide essential device information and navigation controls. On Android, they include the status bar, caption bar, and navigation bar. On iOS, they include the status bar, navigation bar, and home indicator. They display information such as battery level, time, and notification alerts, and provide direct device interaction from anywhere in the interface.
Navigation bar visibility control
To control NavigationBar visibility on Android, use the hidden prop or the NavigationBar.setHidden method.
NavigationBar component usage example
Import NavigationBar from 'expo-navigation-bar'. In a root layout component, render <NavigationBar style="dark" /> to set the navigation bar style to dark.
StatusBar component usage example
Import StatusBar from 'expo-status-bar'. In a root layout component, render <StatusBar style="light" /> to use light text in the status bar instead of dark text for better contrast with a dark background. The style property can be set to 'auto' to automatically pick the appropriate style based on color scheme.
Content overlapping system bars handling with safe areas
When app content draws behind system bars, you must position content correctly by avoiding overlap and ensuring system bar controls remain present. Use SafeAreaView or a hook to apply insets directly for each edge of the screen.
Status bar visibility control
To control StatusBar visibility, set the hidden property to true or use the setStatusBarHidden method.
Google Play Store policy on interpreted code
Google Play policy states that an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser). Apps with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time must not allow potential violations of Google Play policies.
Apple App Store policy on interpreted code
Apple App Store policy allows interpreted code to be downloaded to an Application only if: (a) it does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) it does not create a store or storefront for other code or applications, and (c) it does not bypass signing, sandbox, or other security features of the OS.
Sharing and submitting Expo projects
The fastest way to share a project is to publish with EAS Update and launch in a development build, providing a shareable URL. When ready, you can create a production build (**.aab** and **.ipa**) to submit to app stores. You can build with EAS Build and submit with EAS Submit in a single command. Internal distribution is also available using APK on Android and ad-hoc or enterprise provisioning on iOS.
Expo CLI vs React Native Community CLI features
Expo CLI offers the same core functionality as React Native Community CLI with additional features including automatic TypeScript setup, web support, auto installing compatible libraries, improved native build commands, tunneling, Prebuild, and more. Expo CLI can be used simultaneously with React Native Community CLI. You can use any part of the Expo SDK and Expo Application Services with either CLI.
Eject deprecation and Continuous Native Generation
The `expo eject` command was removed in SDK 46. Expo now uses Continuous Native Generation (CNG). To access or customize native code, run `npx expo prebuild` to generate native directories, then modify them directly or use config plugins. The concept of ejecting was replaced by the `npx expo prebuild` command in SDK 41 (April 2021), which continuously generates native projects based on libraries in your project and the app config (app.json).
Expo Go capabilities and limitations
Expo Go is a playground for students and learners to test Expo quickly. It allows you to use libraries included in the Expo SDK and libraries that don't require custom native code. Expo Go cannot use third-party libraries that require custom native code and you cannot edit native code directly in Expo Go. It's limited and not useful for building production-grade projects. Development builds are strongly recommended for any real project.
Why Expo uses feature preview instead of beta
Expo chose the feature preview label instead of beta because developers are skeptical of anything labeled beta, knowing it is sometimes applied to projects that are early in development, incomplete, or may not receive long-term support. Feature preview signals that the functionality is tested and adopted by multiple teams.
Feature preview meaning and intent
Feature preview means Expo publishes new features as previews to gather developer feedback, not that features are in beta. Expo emphasizes that preview features have been tested and adopted by many teams. The preview period is used to understand developer expectations and shape features to fit their needs. Breaking changes in preview packages are expected to occur more frequently than in the stable Expo SDK.
create-expo-app --example option
Use create-expo-app with the --example option and no name to browse and pick an example interactively. You can also pass a known example name directly, such as npx create-expo-app@latest --example with-widgets.
System requirements for Expo
Expo requires Node.js (LTS) and supports macOS, Windows (Powershell and WSL 2), and Linux.
Expo Application Services (EAS)
Expo Application Services (EAS) is a set of services that complement the Expo framework in each step of the development process.
Reset project command removes boilerplate code
Running the reset-project command removes boilerplate code by moving existing files in the app directory to app-example, then creating a new app directory with a new index.tsx file. The command can be run with npm run reset-project, yarn run reset-project, pnpm run reset-project, or bun run reset-project depending on your package manager.
Tutorial available for step-by-step Expo app building
A step-by-step tutorial is available that provides a guided walkthrough of building an app with Expo from start to finish.
Typical Expo app development workflow stages
The standard workflow for building an Expo app consists of three main stages: development (creating UI elements, adding unit tests, including native modules), review (sharing the app with teammates), and deployment (building and submitting the project to app stores).
Real device recommended for development
Expo recommends using a real device to develop because developers will see exactly what users will see.
Fast Refresh not working troubleshooting
If changes are not showing up on your device, ensure development mode is enabled in Expo CLI. Close and reopen the Expo app. Shake your device to open the developer menu (or press Cmd+D on iOS). If Fast Refresh is enabled, toggle it off. If it says Disable Fast Refresh, dismiss the developer menu. Then try making another change.
Make changes to app code
Edit the src/app/index.tsx file in your code editor to make changes to the app. Expo Go is configured to automatically reload the app whenever a file is changed.
Troubleshoot QR code scanning issues
If the QR code won't scan, ensure your computer and device are on the same Wi-Fi network. If problems persist due to router configuration (common on public networks), use the Tunnel connection type by running `npx expo start --tunnel` (or equivalent with yarn, pnpm, bun), then scan the QR code again.
Tunnel connection type performance trade-off
Using the Tunnel connection type makes app reloads considerably slower than LAN or Local connections. Tunnel is best avoided when possible. Consider using an emulator or simulator for faster development if Tunnel is required to access your machine from another device on your network.
Open app on device from development server
Scan the QR code displayed in your terminal to open the app on your device. For Android Emulator or iOS Simulator, press A or I respectively to open the app.
Run prebuild to generate native projects
Run `npx expo prebuild --clean` to regenerate the android and ios directories based on the app config (app.json/app.config.js). This command should be run after committing changes, as the command will warn about uncommitted changes. The time required depends on the amount of custom native modifications in the existing project.
Replace AppRegistry with registerRootComponent
Change the entry file (index.js) to use `registerRootComponent` from 'expo' instead of `AppRegistry.registerComponent`. Replace `import {AppRegistry} from 'react-native'` and `AppRegistry.registerComponent(appName, () => App)` with `import {registerRootComponent} from 'expo'` and `registerRootComponent(App)`.
Test prebuild with run commands
After running prebuild, test the build by running `npx expo run:android` to build the native Android project and `npx expo run:ios` to build the native iOS project.
Install expo package for prebuild
Install the expo package to get access to the `npx expo prebuild` command and to indicate which prebuild template to use. The version of expo must match the currently installed version of react-native, as not all react-native versions are explicitly supported.
Add .expo to .gitignore
Add .expo to .gitignore to prevent generated values from Expo CLI from being committed. These values are unique to the project on the local computer. The android and ios directories are automatically added to .gitignore when creating a new project.
Prebuild adoption enables native module development
Adopting Expo Prebuild enables development of modules with the Expo native module API using Swift and Kotlin, which is automatically supported.
Clean up app.json for prebuild
Remove all fields that are outside the top-level `expo` object in app.json, as these will not be used in `npx expo prebuild`. Keep only the `expo` object with fields like `name`.
Update package.json scripts to use Expo CLI run commands
Change the package.json scripts to use Expo CLI run commands instead of react-native commands: replace `react-native run-android` with `expo run:android` and `react-native run-ios` with `expo run:ios`. These commands provide better logging, auto code signing, better simulator handling, and ensure the dev server is run with `npx expo start`.