Handling Notification Taps and Deep Links in React Native

Course: React Native Training

Topic: Handling Notification Taps and Deep Links

Course Link: React Native Training at JustAcademy

Demo Link: Register for a Course Demo

Training Provider: JustAcademy

1. Introduction to Notification Taps and Deep Links

Mobile applications often send notifications to inform users about messages, orders, appointments, account updates, and other important events. When a user taps a notification, the application should take them to the relevant screen instead of simply opening the home page.

Handling notification taps means detecting a user's interaction with a notification and deciding what action the application should perform. Deep linking allows an application to open a specific screen or piece of content using a URL.

In React Native applications built with Expo, the expo-notifications package can detect notification interactions, while Expo Router or React Navigation can direct users to the appropriate screen.

For example, when a user taps a notification that says “Your order has shipped,” the application can open the Order Details screen for that particular order.

Official documentation: Expo Notifications API.

2. Learning Objectives

After studying this topic, learners should be able to:

• Understand notification taps and deep linking.
• Differentiate push notifications, notification responses, and deep links.
• Configure deep linking in a React Native Expo application.
• Handle notification taps using expo-notifications.
• Extract URLs and navigation data from notification payloads.
• Navigate to specific screens using Expo Router.
• Understand how notification navigation works with React Navigation.
• Handle notifications when the application is open, in the background, or launched from a closed state.
• Configure custom URL schemes and understand universal links.
• Validate incoming links and protect sensitive screens.
• Test deep links and troubleshoot common navigation issues.

3. What Is a Notification Tap?

A notification tap occurs when a user selects a notification displayed by the operating system. The interaction may launch the application, bring an existing application to the foreground, or trigger navigation within an already running application.

For example, a food delivery application may display this notification:

Title: Your order is on the way
Body: Tap to view your delivery status
Data: {
  "screen": "OrderDetails",
  "orderId": "ORD123"
}

When the user taps the notification, the application reads its associated data, checks the destination, and opens the corresponding order screen.

3.1 Common Notification Tap Scenarios

• A user taps a new message notification and opens a chat conversation.
• A user taps an order update and opens the order tracking screen.
• A user taps an appointment reminder and opens the appointment details.
• A user taps a social media notification and opens a particular post.
• A user taps a security alert and opens the relevant account activity page.

4. What Is Deep Linking?

Deep linking is a technique that opens a specific destination within a mobile application through a URL. It enables navigation from notifications, emails, websites, QR codes, or other applications.

Without deep linking, an application might open its home screen regardless of the link's intended destination. With deep linking, it can open the relevant screen directly.

4.1 Example Deep Links

The examples use fictional application names and identifiers. A custom URL scheme must be configured in the app, while HTTPS app links or universal links require additional website and native configuration.

5. Notification Taps vs. Deep Links

Notification handling and deep linking often work together: the notification supplies a URL, and the application's linking system resolves that URL to a screen.

6. Understanding the Notification Navigation Flow

A typical notification navigation flow includes the following steps:

1. A backend or notification service sends a notification to a device.
2. The operating system displays the notification when permitted.
3. The user taps the notification.
4. The application receives a notification response event or retrieves the last response after startup.
5. The application reads the notification payload.
6. The destination is validated.
7. The navigation system opens the appropriate screen.
8. The destination screen loads the required data and checks user access.

Push Notification
       |
       v
User Taps Notification
       |
       v
Notification Response Event
       |
       v
Read Notification Data or URL
       |
       v
Validate Destination
       |
       v
Expo Router / React Navigation
       |
       v
Open Specific Screen
       |
       v
Load Data and Check Authorization

Navigation should not depend on notification data alone for authorization. The destination screen must retrieve protected information through the application's normal authenticated APIs.

7. Installing the Required Packages

For an Expo application, install the notifications package using Expo's compatible installation command.

npx expo install expo-notifications

If you use Expo Router, configure it according to your project's existing setup. Expo Router supports file-based routes and automatically provides much of the standard deep-linking behavior.

Official resources:

• Expo Notifications
• Expo Linking Overview
• Expo Router Introduction

8. Configuring a Custom URL Scheme

A custom URL scheme allows links such as shopapp://orders/ORD123 to open the application. Configure the scheme in the Expo application configuration.

8.1 Example app.json

{
  "expo": {
    "name": "ShopApp",
    "slug": "shop-app",
    "scheme": "shopapp",
    "plugins": [
      "expo-notifications"
    ],
    "android": {
      "package": "com.example.shopapp"
    },
    "ios": {
      "bundleIdentifier": "com.example.shopapp"
    }
  }
}

Replace the example identifiers with values appropriate for your application. If your project already has a configuration file, merge these settings into the existing configuration rather than replacing unrelated settings.

After adding or changing a custom scheme, create a new development build and install it on the device. A JavaScript reload alone may not apply native configuration changes.

Official guide: Linking into Your Expo App.

9. Creating Screens with Expo Router

Expo Router uses files and folders to define application routes. For example, the following structure creates product and order detail screens:

app/
  _layout.js
  index.js
  products/
    [id].js
  orders/
    [id].js

Example destinations include:

• /products/101 for product 101.
• /orders/ORD123 for order ORD123.

9.1 Example Order Details Screen

// app/orders/[id].js

import { View, Text } from 'react-native';
import { useLocalSearchParams } from 'expo-router';

export default function OrderDetailsScreen() {
  const { id } = useLocalSearchParams();

  return (
    <View style={{ flex: 1, padding: 20 }}>
      <Text style={{ fontSize: 24, fontWeight: 'bold' }}>
        Order Details
      </Text>
      <Text style={{ marginTop: 12 }}>
        Order ID: {String(id ?? '')}
      </Text>
    </View>
  );
}

The screen receives the order identifier from the route. In a real application, it should use the identifier to fetch the order details from the backend and confirm that the authenticated user has permission to access the order.

10. Handling Notification Taps with Expo Router

Expo Notifications provides addNotificationResponseReceivedListener() to listen for notification interactions. When a user taps a notification, the response contains the notification and an action identifier.

For a standard tap, the action identifier is normally Notifications.DEFAULT_ACTION_IDENTIFIER.

10.1 Example Notification Payload

{
  "to": "ExponentPushToken[YOUR_REAL_TOKEN]",
  "title": "Order Shipped",
  "body": "Tap to view your order.",
  "data": {
    "url": "/orders/ORD123"
  }
}

This payload is illustrative. Use an actual token generated by the application when testing remote push notifications.

10.2 Handling the Tap in the Root Layout

// app/_layout.js

import { useEffect } from 'react';
import { Slot, router } from 'expo-router';
import * as Notifications from 'expo-notifications';

function useNotificationObserver() {
  useEffect(() => {
    function redirectFromNotification(notification) {
      const data = notification.request.content.data;
      const url = data?.url;

      if (typeof url === 'string' && url.startsWith('/')) {
        router.push(url);
      }
    }

    const lastResponse =
      Notifications.getLastNotificationResponse();

    if (
      lastResponse?.actionIdentifier ===
      Notifications.DEFAULT_ACTION_IDENTIFIER
    ) {
      redirectFromNotification(lastResponse.notification);
      Notifications.clearLastNotificationResponse();
    }

    const subscription =
      Notifications.addNotificationResponseReceivedListener(
        response => {
          if (
            response.actionIdentifier !==
            Notifications.DEFAULT_ACTION_IDENTIFIER
          ) {
            return;
          }

          redirectFromNotification(response.notification);
          Notifications.clearLastNotificationResponse();
        }
      );

    return () => subscription.remove();
  }, []);
}

export default function RootLayout() {
  useNotificationObserver();

  return <Slot />;
}

This example demonstrates the main concept: read the notification URL and send it to Expo Router. The sample assumes that notification URLs are trusted internal paths. For production, validate each destination against an allowlist of supported routes and identifiers before navigation.

For applications using the current Expo Notifications API, consult the installed SDK documentation for the latest synchronous and asynchronous methods for reading and clearing the last notification response.

11. Handling Notification Taps When the App Is Closed

When the application is fully closed, the notification response event may occur as the app launches. Registering a listener alone may not be enough to handle every startup scenario.

The application should also inspect the last notification response during startup. This helps determine whether the user launched the app by tapping a notification.

The previous root-layout example demonstrates the general pattern:

1. Read the last notification response during initialization.
2. Check whether the interaction represents a normal notification tap.
3. Extract and validate the destination.
4. Navigate once the routing system is ready.
5. Clear the handled response to avoid processing it repeatedly.

Be careful when navigation is not yet initialized. If your application performs authentication or onboarding first, preserve the intended destination and navigate only when the application is ready.

12. Handling Notification Taps When the App Is Already Open

When the app is already running, the notification response listener can process the tap and navigate to the relevant screen.

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';
import { router } from 'expo-router';

export function useOrderNotificationNavigation() {
  useEffect(() => {
    const subscription =
      Notifications.addNotificationResponseReceivedListener(
        response => {
          const data =
            response.notification.request.content.data;

          if (
            response.actionIdentifier ===
              Notifications.DEFAULT_ACTION_IDENTIFIER &&
            data?.type === 'order' &&
            typeof data.orderId === 'string'
          ) {
            router.push({
              pathname: '/orders/[id]',
              params: { id: data.orderId }
            });
          }
        }
      );

    return () => subscription.remove();
  }, []);
}

This example uses structured data instead of an arbitrary URL. The application checks the notification type and confirms that the order identifier is a string before navigating.

13. Using Structured Data Instead of Raw URLs

A notification can provide either a destination URL or structured data describing the destination. Structured data can be easier to validate and maintain when your application has a limited set of screen types.

13.1 Example Structured Payload

{
  "to": "ExponentPushToken[YOUR_REAL_TOKEN]",
  "title": "New Message",
  "body": "You have received a message.",
  "data": {
    "type": "chat",
    "conversationId": "CONV456"
  }
}

13.2 Handling Structured Data

function handleNotificationData(data) {
  if (!data || typeof data.type !== 'string') {
    return;
  }

  if (
    data.type === 'chat' &&
    typeof data.conversationId === 'string'
  ) {
    router.push({
      pathname: '/conversations/[id]',
      params: {
        id: data.conversationId
      }
    });
    return;
  }

  if (
    data.type === 'order' &&
    typeof data.orderId === 'string'
  ) {
    router.push({
      pathname: '/orders/[id]',
      params: {
        id: data.orderId
      }
    });
  }
}

Structured payloads help centralize routing rules. The destination screen must still validate the identifier and retrieve the associated data securely.

14. Handling Deep Links with React Native Linking

The React Native Linking API can retrieve the initial URL that launched the app and listen for URLs received while the app is running.

import { useEffect } from 'react';
import { Linking } from 'react-native';

export function useIncomingLinks() {
  useEffect(() => {
    async function getInitialLink() {
      const url = await Linking.getInitialURL();

      if (url) {
        console.log('App opened with URL:', url);
      }
    }

    getInitialLink();

    const subscription = Linking.addEventListener(
      'url',
      event => {
        console.log('Incoming URL:', event.url);
      }
    );

    return () => subscription.remove();
  }, []);
}

This hook demonstrates how to receive incoming links. Logging a URL does not automatically navigate to a screen; the application must resolve it through Expo Router or its own navigation configuration.

Official documentation: React Native Linking API.

15. Deep Linking with HTTPS App Links and Universal Links

Custom schemes are useful, but HTTPS links are often preferable when links need to work both in a browser and in a mobile application.

• Android App Links: Verified HTTPS links that can open the associated Android application.
• iOS Universal Links: HTTPS links that can open the associated iOS application when the required domain association is configured.
• Custom URL schemes: Application-specific links such as shopapp://orders/ORD123.

HTTPS app links and universal links require domain verification and native configuration. They should not be treated as working merely because a URL opens in a browser.

Official guide: Expo Linking, Deep Links, App Links, and Universal Links.

16. Configuring React Navigation for Notification Deep Links

Applications using React Navigation can integrate notification URLs with the linking configuration on NavigationContainer. This allows the navigation system to handle URLs from both normal deep links and notification interactions.

import { Linking } from 'react-native';
import * as Notifications from 'expo-notifications';

const linking = {
  prefixes: [
    'shopapp://',
    'https://example.com'
  ],
  config: {
    screens: {
      Home: '',
      OrderDetails: 'orders/:orderId',
      ProductDetails: 'products/:productId'
    }
  },
  async getInitialURL() {
    const initialURL = await Linking.getInitialURL();

    if (initialURL) {
      return initialURL;
    }

    const response =
      await Notifications.getLastNotificationResponseAsync();

    const url =
      response?.notification.request.content.data?.url;

    return typeof url === 'string' ? url : null;
  },
  subscribe(listener) {
    const linkSubscription = Linking.addEventListener(
      'url',
      ({ url }) => listener(url)
    );

    const notificationSubscription =
      Notifications.addNotificationResponseReceivedListener(
        response => {
          const url =
            response.notification.request.content.data?.url;

          if (typeof url === 'string') {
            listener(url);
          }

          Notifications.clearLastNotificationResponse();
        }
      );

    return () => {
      linkSubscription.remove();
      notificationSubscription.remove();
    };
  }
};

export default linking;

Pass the linking configuration to the application's NavigationContainer:

<NavigationContainer linking={linking}>
  {/* Application navigators */}
</NavigationContainer>

Update the screen names and path configuration to match your actual navigator. If the application uses Expo Router, prefer its built-in routing approach rather than combining two competing navigation systems.

17. Handling Notification Actions

Some notifications contain action buttons such as “Reply,” “Mark as Read,” or “View Details.” These interactions can return an action identifier that differs from the default notification tap identifier.

When using interactive notification categories, register the supported categories and actions according to the Expo Notifications documentation. Then inspect the response's actionIdentifier to determine what the user selected.

import * as Notifications from 'expo-notifications';

export function listenForNotificationActions() {
  return Notifications.addNotificationResponseReceivedListener(
    response => {
      const action = response.actionIdentifier;
      const data =
        response.notification.request.content.data;

      if (
        action === Notifications.DEFAULT_ACTION_IDENTIFIER
      ) {
        console.log('Notification opened:', data);
      } else if (action === 'mark-read') {
        console.log('Mark message as read:', data?.messageId);
      } else {
        console.log('Other notification action:', action);
      }
    }
  );
}

The action identifier must match the action configured for the notification category. The code above illustrates the branching pattern; it does not create the action button itself.

18. Validating Incoming Deep Links

Incoming links can originate from external websites, email messages, QR codes, and notifications. Treat them as untrusted input and validate them before navigation.

Recommended validation practices include:

• Allow only known application routes.
• Check that identifiers are strings and follow the expected format.
• Reject unsupported or malformed URLs.
• Avoid accepting arbitrary URLs that can navigate to unintended destinations.
• Do not put passwords, access tokens, or other secrets in deep-link parameters.
• Check authentication before opening protected screens.
• Verify record ownership through the backend before displaying private content.
• Provide a safe fallback screen for unknown routes.

18.1 Example Internal URL Validation

const allowedPaths = [
  /^\/orders\/[A-Za-z0-9_-]+$/,
  /^\/products\/[A-Za-z0-9_-]+$/,
  /^\/conversations\/[A-Za-z0-9_-]+$/
];

export function isAllowedInternalPath(url) {
  if (typeof url !== 'string') {
    return false;
  }

  if (!url.startsWith('/') || url.startsWith('//')) {
    return false;
  }

  return allowedPaths.some(pattern => pattern.test(url));
}

This example is a basic allowlist for internal route paths. More complex applications should use a proper URL parser and explicit route-specific validation, especially when handling query parameters or externally supplied HTTPS URLs.

19. Handling Authentication Before Navigation

Suppose a user taps an order notification while signed out. The application should not immediately display protected order data. Instead, it should preserve the intended destination, ask the user to authenticate, and continue to the order screen after successful sign-in.

A common flow is:

1. Read the notification destination.
2. Validate that the destination is allowed.
3. Check whether the user is authenticated.
4. If authenticated, navigate to the intended screen.
5. If unauthenticated, store the pending destination in application state.
6. Show the sign-in screen.
7. After successful sign-in, revalidate and navigate to the intended destination.
8. Fetch the requested data and verify the user's access rights.

Do not treat a notification payload as proof that the user has access to the requested record. Authentication and authorization must be enforced by the application's backend.

20. Preventing Duplicate Navigation

Duplicate navigation can occur when an application handles both the last notification response and a newly received notification response for the same interaction. It can also occur when several components register duplicate listeners.

To reduce duplicate navigation:

• Register the notification response listener once near the root of the application.
• Remove listeners when the component unmounts.
• Clear the last notification response after successful handling where appropriate.
• Track a notification or event identifier if your application needs deduplication.
• Ensure startup logic and foreground listener logic do not both process the same event unnecessarily.
• Wait for the navigation system and authentication state to be ready.

Use the current SDK's supported last-response and clearing APIs. Some older Expo Notifications methods have been deprecated in favor of asynchronous alternatives.

21. Handling Invalid or Expired Destinations

A notification may refer to a record that has been deleted, an expired promotion, or a screen that no longer exists. Applications should handle these situations gracefully.

For example, if a user taps a notification for a deleted product, the application can display a message explaining that the product is unavailable and provide a link back to the product list.

Recommended behavior includes:

• Check whether the destination identifier exists.
• Display a helpful message when the record is unavailable.
• Provide a fallback route for unsupported destinations.
• Handle backend errors and network timeouts.
• Do not leave the user on a blank or broken screen.
• Log non-sensitive diagnostic information for debugging.

22. Testing Deep Links During Development

Deep links should be tested on the intended platforms and build types. Expo Go has limitations for some linking scenarios, so development builds are recommended when testing native configuration.

22.1 Test a Custom URL Scheme

After configuring the scheme and installing a suitable build, try opening a URL such as:

shopapp://orders/ORD123

Use your platform's supported tools to open the URL on the test device. Confirm that the application opens and resolves the route correctly.

22.2 Test a Notification Tap

1. Install the development build on a physical device.
2. Configure push notification credentials and permission.
3. Generate a valid Expo push token.
4. Send a test notification containing a supported route or data payload.
5. Tap the notification while the application is in the foreground, if supported by the test setup.
6. Repeat while the app is in the background.
7. Repeat after the app has been closed.
8. Check that the correct destination opens and no duplicate navigation occurs.
9. Test an invalid identifier and a destination requiring authentication.

23. Common Errors and Troubleshooting

24. Security Best Practices

• Validate notification payloads and incoming URLs.
• Use an allowlist of supported routes.
• Never embed passwords, authentication tokens, or sensitive personal data in a URL.
• Check authentication before opening protected screens.
• Verify authorization on the backend before returning private information.
• Do not trust identifiers simply because they came from a notification.
• Avoid passing arbitrary external URLs directly to navigation without validation.
• Handle missing or malformed data without crashing.
• Use HTTPS for web links and configure verified app links where appropriate.
• Remove event listeners when they are no longer needed.
• Log only the diagnostic information necessary to investigate issues.

25. Performance and User Experience Best Practices

• Open the most relevant screen for each notification type.
• Keep notification payloads small and meaningful.
• Use structured data when your app has a limited set of destination types.
• Wait until navigation and authentication are ready before redirecting.
• Show loading indicators while retrieving destination data.
• Provide clear error messages when a record is missing or unavailable.
• Prevent duplicate navigation and repeated processing.
• Keep route handling in one shared location rather than scattering listeners across screens.
• Test notification taps in foreground, background, and terminated states.
• Ensure the destination remains usable if the notification is old or the underlying record has changed.

26. Mini Project: Notification-Based Navigation

Project objective: Create an Expo application that opens the correct screen when a user taps an order, product, or message notification.

Project Requirements

• Create an Expo application with Expo Router.
• Configure a custom URL scheme.
• Create dynamic product, order, and conversation routes.
• Install and configure Expo Notifications.
• Prepare a test notification payload with a destination URL or structured data.
• Handle notification response events in the root layout.
• Handle the last notification response during startup.
• Validate destinations before navigation.
• Handle signed-out users and preserve pending navigation where appropriate.
• Test foreground, background, and closed-app scenarios.
• Show a fallback screen for invalid or expired destinations.

Expected Result

When a user taps an order notification, the application opens the corresponding order details screen. Product and message notifications open their own destinations. Invalid destinations display a helpful fallback, and protected content remains inaccessible without proper authentication.

27. Practical Exercises

1. Explain the difference between a notification tap and a deep link.
2. Configure a custom URL scheme in an Expo project.
3. Create a dynamic order detail route using Expo Router.
4. Write a notification response listener.
5. Read the last notification response during application startup.
6. Pass an order ID through notification data and navigate to the order screen.
7. Handle a notification containing structured chat data.
8. Test a custom deep link from outside the application.
9. Add validation for unknown routes and malformed identifiers.
10. Implement authentication-aware navigation for protected screens.
11. Test notification taps when the app is foregrounded, backgrounded, and closed.
12. Investigate and fix duplicate navigation caused by multiple listeners.

28. Interview Questions and Answers

Q1. What is a notification tap?

It is a user interaction with a displayed notification that the application can handle to perform an action or navigate to a relevant screen.

Q2. What is deep linking?

Deep linking opens a specific screen or resource inside an application using a URL.

Q3. What is the purpose of addNotificationResponseReceivedListener()?

It listens for user interactions with notifications, including standard taps and configured notification actions.

Q4. Why should an app check the last notification response?

When the application launches after being closed, startup logic may need to inspect the last response to identify the notification that launched the app.

Q5. What is a custom URL scheme?

It is an application-specific URL prefix, such as shopapp://, that can open the associated application.

Q6. What is the difference between App Links and Universal Links?

Android App Links and iOS Universal Links associate verified HTTPS links with a native application, allowing the link to open the app when the required configuration is valid.

Q7. Can Expo Router handle deep links?

Yes. Expo Router supports deep linking for application routes and can be integrated with notification response handling.

Q8. Why should incoming URLs be validated?

Links may contain malformed or unexpected destinations. Validation helps prevent unintended navigation and reduces security risks.

Q9. How should an app handle a notification tapped by a signed-out user?

It should preserve the intended destination, request authentication, and navigate after sign-in while still validating access to the requested resource.

Q10. How can duplicate navigation be prevented?

Register listeners centrally, remove them during cleanup, track handled events when needed, and avoid processing the same response through multiple paths.

Q11. What should happen if a deep link refers to a deleted record?

The application should display a useful error or fallback screen instead of crashing or leaving the user on a blank page.

Q12. Does opening a deep link prove that a user can access the destination?

No. The application must verify authentication and authorization before displaying protected data.

29. Quick Revision Checklist

• Install and configure Expo Notifications.
• Understand notification responses and deep-link URLs.
• Configure a custom scheme or verified HTTPS links as needed.
• Create routes for the intended destinations.
• Register a notification response listener in a central location.
• Inspect the last notification response during startup.
• Read the notification payload safely.
• Validate route names and identifiers.
• Navigate using Expo Router or React Navigation.
• Handle authentication before displaying protected content.
• Prevent duplicate navigation and clean up listeners.
• Test foreground, background, and closed-app scenarios.
• Provide fallback behavior for invalid or expired destinations.

30. Official Learning Resources

• Expo Notifications API Reference
• Expo Linking Overview
• Linking into Your Expo App
• Expo Router Introduction
• React Native Linking Documentation
• Sending Push Notifications with Expo
• React Native Training at JustAcademy
• Register for a Course Demo
• Visit JustAcademy

31. Conclusion

Handling notification taps and deep links allows React Native applications to provide a seamless navigation experience. By connecting notification response events to the application's routing system, developers can direct users to specific orders, conversations, products, and other relevant destinations.

A reliable implementation must support application startup, foreground and background interactions, URL validation, authentication-aware navigation, and appropriate handling of invalid or outdated destinations. Expo Router provides a convenient way to handle application routes, while React Navigation can use a linking configuration to connect incoming URLs with screens.

By following these practices, developers can build notification-driven experiences that are convenient, secure, and reliable.

To learn more about React Native development, visit JustAcademy's React Native Training or register for a course demo.