Course: React Native Training
Topic: Configuring Push Notifications in Expo
Course Link: React Native Training at JustAcademy
Demo Link: Register for a Free Course Demo
Training Provider: JustAcademy
Push notifications are messages sent from a server or service to a mobile device, even when the user is not actively using the application. They help applications deliver important updates, reminders, alerts, promotions, and personalized information.
Expo simplifies push notification development in React Native through the expo-notifications library and Expo Push Service. These tools provide a common interface for working with notifications on Android and iOS.
Expo can communicate with the platform notification services behind the scenes:
Official reference: Expo Push Notifications Overview.
After studying this topic, learners should be able to:
expo-notifications package.Before configuring push notifications, it is important to understand the difference between local and remote notifications.
| Feature | Local Notification | Remote Push Notification |
|---|---|---|
| Origin | Scheduled or triggered by the application on the device. | Sent by a server or push notification service. |
| Internet connection | Not necessarily required to schedule a local notification. | Normally required for the push delivery process. |
| Example | A reminder scheduled for 8 PM. | A message alert sent when a new message arrives. |
| Token requirement | Does not require an Expo push token. | Requires a valid push token for the chosen delivery service. |
| Typical API | scheduleNotificationAsync() |
getExpoPushTokenAsync() and a push service. |
Local notifications are useful for reminders and scheduled events. Remote push notifications are useful when an external event, such as a new order or message, must trigger an alert on the user's device.
A typical Expo push notification follows this sequence:
User Device
|
| Request permission and obtain Expo push token
v
React Native + Expo Notifications
|
| Send token to backend
v
Application Backend + Database
|
| Send notification request
v
Expo Push Service
|
+-------------------+
| |
v v
Firebase FCM Apple APNs
| |
v v
Android Device iOS DeviceImportant: obtaining a token does not guarantee that a notification will be delivered. Credentials, permissions, network connectivity, device settings, token validity, and platform delivery policies all affect the result.
Prepare the following before starting the implementation:
npx expo.Important: Remote push notifications are not supported in Expo Go on Android from Expo SDK 53 onward. Use a development build for remote push notification testing. Local notifications can still be used in Expo Go where supported.
Official guide: Expo Push Notification Setup.
Install the notification package and Expo Constants using Expo's version-compatible installation command:
npx expo install expo-notifications expo-constantsThe packages serve different purposes:
expo-notifications provides APIs for permissions, push tokens, notification listeners, channels, and notification presentation.expo-constants provides application configuration information, including the EAS project ID used when requesting an Expo push token.Use npx expo install rather than choosing arbitrary package versions because Expo can select versions compatible with the SDK installed in the project.
Expo notification configuration includes settings that must be applied during the native app build. These settings are typically managed in app.json or app.config.js.
{
"expo": {
"name": "NotificationDemo",
"slug": "notification-demo",
"scheme": "notificationdemo",
"plugins": [
[
"expo-notifications",
{
"defaultChannel": "general",
"color": "#2563EB"
}
]
],
"android": {
"package": "com.example.notificationdemo"
},
"ios": {
"bundleIdentifier": "com.example.notificationdemo"
},
"extra": {
"eas": {
"projectId": "YOUR_EAS_PROJECT_ID"
}
}
}
}Configuration notes:
YOUR_EAS_PROJECT_ID with the actual project ID from your EAS project.Do not copy placeholder identifiers into a production app. The configuration must match your actual project and native application identifiers.
The Expo config plugin applies supported native configuration when the project is prebuilt or built through EAS. This is important because some notification settings cannot be changed by JavaScript at runtime.
After changing plugin configuration, create a new build and install it on the device. Reloading JavaScript alone does not apply all native configuration changes.
For the common Expo Push Service workflow, connect the project to EAS and make sure the EAS project ID is available to the application.
npm install --global eas-cli
eas login
eas build:configureFollow the prompts to link or configure the project. You can also use the official EAS project setup instructions: Expo Application Services documentation.
The EAS project ID is a unique identifier that associates the Expo push token with the correct project. It can be found in the EAS project dashboard or in the generated app configuration.
For a JavaScript application, it can be read from Expo Constants:
import Constants from 'expo-constants';
const projectId =
Constants.expoConfig?.extra?.eas?.projectId ??
Constants.easConfig?.projectId;
console.log('EAS Project ID:', projectId);Use the actual project ID in token registration. Do not assume that the project ID and the application's display name are interchangeable.
Android push notification delivery through Expo Push Service uses Firebase Cloud Messaging (FCM). Configure the Firebase project and link the appropriate credentials to the Expo application.
Expo's Android push setup uses FCM V1 credentials. Generate or obtain the required service account credentials through Firebase and upload them using the current EAS credential workflow.
Follow the official guide carefully: Configure Android FCM V1 Credentials.
Keep service account JSON files private. Never commit them to a public repository or include their contents in client-side JavaScript.
Android uses notification channels to group notifications by category. Users can adjust channel behavior, including sound, vibration, and visibility, through system settings.
For Android 13 and later, notification permission is controlled by the operating system. Creating a notification channel before requesting the permission helps ensure that the permission prompt can appear when needed.
iOS push notifications use Apple Push Notification service (APNs). The application needs suitable Apple developer configuration and push notification credentials.
Use EAS Build and its credential setup flow to configure the Apple push notification key and other required signing details. Follow the prompts and verify that the credentials are associated with the correct iOS application.
Official reference: EAS App Signing and Managed Credentials.
Apple push notification keys are sensitive credentials. Store and manage them securely, and do not place private keys in the application source code.
Use setNotificationChannelAsync() to create a channel before requesting the push token on Android. This is especially important on Android 13 and later because notification permission behavior depends on the channel being created.
import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';
export async function configureAndroidChannel() {
if (Platform.OS !== 'android') {
return;
}
await Notifications.setNotificationChannelAsync('general', {
name: 'General Notifications',
importance: Notifications.AndroidImportance.MAX,
vibrationPattern: [0, 250, 250, 250],
lightColor: '#2563EB'
});
}The channel ID is general. When sending notifications, the backend can specify this channel using the channelId field.
Channel IDs should be stable and meaningful. If a notification references a channel that does not exist on the device, the notification may not be displayed as expected.
An application should request permission at an appropriate moment and explain why notifications are useful. Users can decline permission or change notification settings later.
import * as Notifications from 'expo-notifications';
export async function requestNotificationPermission() {
const current = await Notifications.getPermissionsAsync();
if (current.granted) {
return true;
}
const requested = await Notifications.requestPermissionsAsync();
return requested.granted;
}Call the permission function from an appropriate point in the user journey, such as after the user enables alerts in settings or completes onboarding.
Best practice: Do not repeatedly display permission requests without a reason. If permission has been denied, explain how users can enable notifications through their device settings.
An Expo push token identifies the application installation for Expo Push Service. The backend uses this token as the recipient when sending a push notification.
import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
export async function registerForPushNotificationsAsync() {
if (Platform.OS === 'android') {
await Notifications.setNotificationChannelAsync('general', {
name: 'General Notifications',
importance: Notifications.AndroidImportance.MAX,
vibrationPattern: [0, 250, 250, 250],
lightColor: '#2563EB'
});
}
const permission = await Notifications.getPermissionsAsync();
let finalStatus = permission.status;
if (finalStatus !== 'granted') {
const requested = await Notifications.requestPermissionsAsync();
finalStatus = requested.status;
}
if (finalStatus !== 'granted') {
throw new Error('Notification permission was not granted.');
}
const projectId =
Constants.expoConfig?.extra?.eas?.projectId ??
Constants.easConfig?.projectId;
if (!projectId) {
throw new Error('EAS project ID is missing.');
}
const tokenResponse = await Notifications.getExpoPushTokenAsync({
projectId
});
return tokenResponse.data;
}A token may look similar to the following illustrative value:
ExponentPushToken[xxxxxxxxxxxxxxxxxxxxxx]This is an example format only, not a real token. The actual token must be generated on the installed application.
Use getExpoPushTokenAsync() when sending through Expo Push Service. If you choose to send directly through FCM or APNs, use the appropriate native device token API and follow that service's configuration requirements.
Separating registration logic from UI components makes the application easier to maintain and test. The registration function can be placed in a file such as notifications.js.
// notifications.js
import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
export async function registerDeviceForNotifications() {
if (Platform.OS === 'android') {
await Notifications.setNotificationChannelAsync('general', {
name: 'General Notifications',
importance: Notifications.AndroidImportance.MAX
});
}
const permission = await Notifications.getPermissionsAsync();
let status = permission.status;
if (status !== 'granted') {
const result = await Notifications.requestPermissionsAsync();
status = result.status;
}
if (status !== 'granted') {
return null;
}
const projectId =
Constants.expoConfig?.extra?.eas?.projectId ??
Constants.easConfig?.projectId;
if (!projectId) {
throw new Error('Missing EAS project ID.');
}
const token = await Notifications.getExpoPushTokenAsync({
projectId
});
return token.data;
}In a production application, also handle network failures, token refreshes, account sign-out, and registration with the backend.
When a notification arrives while the app is active, the app can decide whether to display a banner, play a sound, or update the badge. Configure a notification handler at the top level of the application.
import * as Notifications from 'expo-notifications';
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowBanner: true,
shouldShowList: true,
shouldPlaySound: true,
shouldSetBadge: false
})
});Place the handler in an initialization module or near the application entry point, rather than repeatedly registering it during frequent component renders.
Foreground presentation behavior differs from background notification behavior. The operating system and the app's configuration determine how notifications are shown when the app is not active.
Notification listeners allow the application to react when a notification is received or when a user interacts with it.
import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';
export function useNotificationListeners() {
useEffect(() => {
const receivedSubscription =
Notifications.addNotificationReceivedListener(notification => {
console.log('Notification received:', notification.request.content);
});
const responseSubscription =
Notifications.addNotificationResponseReceivedListener(response => {
const data = response.notification.request.content.data;
console.log('Notification tapped:', data);
});
return () => {
receivedSubscription.remove();
responseSubscription.remove();
};
}, []);
}Call this hook from a component mounted near the root of your application. Always remove subscriptions during cleanup to avoid duplicate listeners and unexpected behavior.
The following example combines permission registration, token display, and listener setup in a simple screen. It assumes the packages and native notification credentials have been configured correctly.
import { useEffect, useState } from 'react';
import {
View,
Text,
Button,
Alert,
Platform
} from 'react-native';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowBanner: true,
shouldShowList: true,
shouldPlaySound: true,
shouldSetBadge: false
})
});
export default function App() {
const [pushToken, setPushToken] = useState('');
useEffect(() => {
let receivedSubscription;
let responseSubscription;
async function initializeNotifications() {
try {
if (Platform.OS === 'android') {
await Notifications.setNotificationChannelAsync('general', {
name: 'General Notifications',
importance: Notifications.AndroidImportance.MAX
});
}
const current = await Notifications.getPermissionsAsync();
let status = current.status;
if (status !== 'granted') {
const requested = await Notifications.requestPermissionsAsync();
status = requested.status;
}
if (status !== 'granted') {
Alert.alert(
'Notifications disabled',
'Enable notifications in your device settings to receive alerts.'
);
return;
}
const projectId =
Constants.expoConfig?.extra?.eas?.projectId ??
Constants.easConfig?.projectId;
if (!projectId) {
throw new Error('EAS project ID is missing.');
}
const token = await Notifications.getExpoPushTokenAsync({
projectId
});
setPushToken(token.data);
console.log('Expo Push Token:', token.data);
} catch (error) {
console.error('Notification setup failed:', error);
}
}
initializeNotifications();
receivedSubscription =
Notifications.addNotificationReceivedListener(notification => {
console.log(
'Received:',
notification.request.content.title
);
});
responseSubscription =
Notifications.addNotificationResponseReceivedListener(response => {
console.log(
'Notification data:',
response.notification.request.content.data
);
});
return () => {
receivedSubscription?.remove();
responseSubscription?.remove();
};
}, []);
return (
Expo Push Notifications
Push Token: {pushToken || 'Not registered yet'}
This example is intended as a learning starting point. A production application should send the token to a protected backend endpoint rather than rely on displaying or logging it.
After configuring credentials, building the application, and generating a valid token, you can send a test notification through Expo's notification tool.
Use a real token generated by your installed application. Do not use the illustrative token shown in these notes.
{
"to": "ExponentPushToken[YOUR_REAL_TOKEN]",
"title": "Welcome!",
"body": "Your Expo push notification is working.",
"sound": "default",
"data": {
"screen": "Home",
"type": "welcome"
},
"channelId": "general"
}This is an illustrative message payload. Replace the token with a real token, and make sure the Android channel exists on the device before referencing it.
In production, notifications should generally be sent from a backend service. The backend can validate business events, check user preferences, choose recipients, and send the message through Expo Push Service.
The Expo Push API accepts HTTPS POST requests. The following example uses Node.js and the built-in fetch API.
async function sendExpoPushNotification({
pushToken,
title,
body,
data = {}
}) {
const response = await fetch(
'https://exp.host/--/api/v2/push/send',
{
method: 'POST',
headers: {
Accept: 'application/json',
'Content-Type': 'application/json'
},
body: JSON.stringify({
to: pushToken,
title,
body,
sound: 'default',
data,
channelId: 'general'
})
}
);
if (!response.ok) {
throw new Error(
`Expo push request failed: ${response.status}`
);
}
return response.json();
}Example usage:
await sendExpoPushNotification({
pushToken: 'ExponentPushToken[YOUR_REAL_TOKEN]',
title: 'Order Confirmed',
body: 'Your order has been confirmed.',
data: {
screen: 'OrderDetails',
orderId: 'ORDER_123'
}
});Use a valid Expo push token from your database. This code demonstrates the request structure; a real service must also validate tokens, handle errors, and process Expo push tickets and receipts.
Official reference: Sending Notifications with Expo Push Service.
Push notifications can contain additional JSON data that helps the application determine what to display when the user taps an alert.
{
"to": "ExponentPushToken[YOUR_REAL_TOKEN]",
"title": "New Message",
"body": "You have received a new message.",
"data": {
"screen": "Chat",
"conversationId": "CONV_456"
}
}Read the data in the notification response listener:
const subscription =
Notifications.addNotificationResponseReceivedListener(response => {
const data =
response.notification.request.content.data;
if (data.screen === 'Chat' && data.conversationId) {
// Navigate to the Chat screen using your navigation setup.
console.log('Open conversation:', data.conversationId);
}
});Integrate this logic with your navigation library. If a notification is opened while the app is launching, also consider the last notification response API so that the intended destination is not missed during startup.
Never assume that all payload fields are present or valid. Validate incoming notification data before navigating or performing an action.
A push token should be associated with a user or installation in the backend. The database design should account for users with multiple devices and tokens that become invalid.
Example token record:
{
"userId": "USER_123",
"expoPushToken": "ExponentPushToken[YOUR_REAL_TOKEN]",
"platform": "android",
"notificationsEnabled": true,
"updatedAt": "2026-10-21T00:00:00Z"
}The example record is illustrative. Use a real timestamp and your application's actual user identifier format.
Recommended token management practices:
Push tokens can change. A robust application should listen for token updates where supported and update its backend record accordingly.
import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';
export function usePushTokenUpdates(onTokenChanged) {
useEffect(() => {
const subscription =
Notifications.addPushTokenListener(token => {
onTokenChanged(token);
});
return () => subscription.remove();
}, [onTokenChanged]);
}For Expo Push Service, ensure that your backend stores the correct Expo push token. The listener provides a native push token update event; if your architecture specifically requires an updated Expo push token, refresh the Expo token through the appropriate API and synchronize it with your backend.
A successful HTTP request to Expo does not necessarily mean that the notification appeared on the device. Expo provides ticket and receipt information to help determine whether a message was accepted for processing and whether delivery encountered an error.
| Term | Meaning |
|---|---|
| Push request | The message sent by your backend to Expo Push Service. |
| Push ticket | An acknowledgement that indicates whether Expo accepted the message request for processing. |
| Push receipt | Follow-up information about processing and delivery to the underlying push service. |
| Device display | The final visible notification behavior, which can still be affected by operating-system settings and user preferences. |
Production notification systems should process errors and receipts, retry only when appropriate, and avoid repeatedly sending messages to invalid tokens.
Test the entire configuration rather than only checking whether the JavaScript function returns a token.
Push delivery is not guaranteed to be instantaneous in every situation. Operating-system restrictions, device power-saving settings, network connectivity, and notification preferences can affect when or whether a notification is displayed.
| Problem | Possible Cause | Recommended Solution |
|---|---|---|
| No push token is generated | Permission denied, project ID missing, network issue, or incomplete native setup. | Check permission status, verify the EAS project ID, inspect errors, and retry when online. |
| Push notification does not arrive | Invalid token, missing credentials, incorrect message payload, or delivery restrictions. | Validate the token and credentials, then inspect push tickets and receipts. |
| Android permission prompt does not appear | Notification channel was not created before requesting permission. | Create the channel first and request permission afterward. |
| Notifications fail in Expo Go on Android | Remote push notifications are not supported there from SDK 53 onward. | Build and install a development build. |
| Notifications work in development but fail in production | Production credentials or build configuration are incomplete. | Verify production credentials and rebuild with the correct configuration. |
| Android notification uses unexpected behavior | Wrong channel ID or channel settings already saved on the device. | Confirm that the channel exists and inspect its settings in Android system settings. |
| Notification appears but tapping does not navigate | Missing response listener, invalid data, or navigation not initialized. | Validate the payload and handle notification responses after navigation is ready. |
| Duplicate event handling | Multiple listeners registered without cleanup. | Remove subscriptions in the component cleanup function. |
| Push token becomes invalid | Token changed or the app installation is no longer registered. | Refresh the token and update the backend record; process invalid-token errors. |
| No sound or badge appears on iOS | User disabled sound or badge permission in system settings. | Check granular iOS notification permission settings and respect user preferences. |
Additional reference: Expo Push Notifications Troubleshooting and FAQ.
Push notifications often carry information related to user accounts, orders, or messages. Use a secure design from registration through delivery.
Project goal: Build a small React Native application that registers a device for push notifications and receives a test alert.
expo-notifications and expo-constants.When the application is installed in a properly configured development build, the user can grant notification permission, obtain a push token, receive a test notification, and inspect the data associated with a notification tap.
expo-notifications config plugin to the app configuration.It is a set of Expo tools and APIs that help React Native applications register devices, receive remote push notifications, and respond to notification interactions.
The expo-notifications package.
It is a token used to identify an app installation as a recipient when sending a message through Expo Push Service.
It identifies the EAS project associated with the Expo push token and helps ensure that token registration is attributed to the correct project.
FCM is Firebase Cloud Messaging, commonly used for Android delivery in the Expo workflow. APNs is Apple's push notification service for iOS.
Channels group notifications into categories and allow users to control behavior such as sound, vibration, and visibility. On Android 13 and later, a channel should be created before requesting notification permission.
Remote push notifications are not supported in Expo Go on Android from Expo SDK 53 onward. A development build is required.
The push service needs valid platform credentials to deliver notifications through FCM or APNs.
Register an addNotificationResponseReceivedListener() listener and read the notification's data payload to decide what action to take.
No. It indicates that the request was processed or accepted at a particular stage. Delivery receipts, platform behavior, permissions, and device settings must also be considered.
Generally, from a trusted backend service that validates business events, manages tokens, and sends requests to Expo Push Service.
Refresh or retrieve the relevant token and update the backend so future notifications use a valid recipient token.
expo-notifications and expo-constants.getExpoPushTokenAsync().Configuring push notifications in Expo involves more than installing a JavaScript package. A complete implementation requires app configuration, platform credentials, permission handling, token registration, notification listeners, and a reliable process for sending notifications from a backend.
By following these steps, developers can build a solid foundation for notification features in React Native applications, including message alerts, order updates, reminders, and personalized engagement. Always test the configuration in a development build, protect credentials, validate notification payloads, and respect the user's notification preferences.
To learn more about React Native development, visit JustAcademy's React Native Training or register for a course demo.
