{
  "id": 109952,
  "title": "Handling Notification Taps in expo-notifications: Launch vs. Runtime",
  "url": "https://urgent.news/2026/08/04/handling-notification-taps-in-expo-notifications-launch-vs-runtime",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-04T01:03:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/hirodeath/handling-notification-taps-in-expo-notifications-launch-vs-runtime-1egf"
  },
  "original_language": "en",
  "account": "When a user taps a push notification, the entry point varies based on whether the app is running or not. If only one listener is used with Expo Router to navigate to the notification target screen, launches from the terminated state may be missed. To handle both cases, the article describes two separate mechanisms: checking for the last notification response after launch and adding a notification response received listener when the app is running.\n\nThe notifications sent from the server include a destination path in data.url. Instead of parsing the displayed title or body to determine the destination, the article suggests passing a path the app can handle as separate data. This approach avoids parsing the displayed title or body to determine the destination.\n\nWhen the app is in a terminated state, the article recommends checking for the last notification response after launch using Notifications.getLastNotificationResponseAsync(). This process is asynchronous, so it's advised to run it after authentication or when the Navigator is ready, to avoid navigation conflicts.\n\nTo handle notification taps while the app is running, addNotificationResponseReceivedListener() can be used to receive taps from either the background or foreground. To avoid duplicate listeners from screen remounts or Fast Refresh, the listener needs to be removed in the cleanup. The article shares a unified function, handleNotificationTap(), to validate notification data, extract the path, and navigate accordingly.\n\nWhen implementing this solution, it's essential to unify both entry points while ensuring backward compatibility with previously sent notifications. The article recommends accepting both url and linkUrl, converting them to app-internal routes before passing, and defining allowed hosts and path formats to maintain safety.\n\nThe article also differentiates addNotificationReceivedListener and addNotificationResponseReceivedListener, explaining that the former is used when a notification is received, while the latter is used when a user taps the notification. The final example shows a unified hook, useNotificationNavigation(), that simplifies the process of handling notification taps based on the app's enabled state.",
  "summary": "This article is an English translation of the original Japanese article. When a user taps a push notification, the entry point differs depending on whether the app is running. If you only use one listener with Expo Router to navigate to the notification target screen, you may miss launches from the terminated state. In my app, I handle both cases with two separate mechanisms:…",
  "key_points": [
    "Expo notifications handle taps differently based on app state (running or terminated)",
    "unify handling with addNotificationResponseReceivedListener() and cleanup listener in cleanup"
  ],
  "editors_take": "Relying on a single listener with Expo Router may lead to missed notifications when the app is launched from a terminated state, requiring separate handling for launch and runtime cases.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}