addNotificationResponseReceivedListener and useLastNotificationResponse not triggered for killed iOS apps SDK 40

🐛 Bug Report

After updating to SDK 40 expo-notifications does not trigger addNotificationResponseReceivedListener after app was killed on iOS. This last upgrade did fix the issue on Android, but now I am having that same problem on iOS.

SDK 40
Standalone App (I built a new bundle after updating to SDK 40)
Only on iOS.

Expo CLI 4.0.13 environment info:
System:
OS: macOS 11.0.1
Shell: 5.8 – /bin/zsh
Binaries:
Node: 12.18.4 – /usr/local/bin/node
npm: 6.14.9 – /usr/local/bin/npm
SDKs:
iOS SDK:
Platforms: iOS 14.2, DriverKit 20.0, macOS 11.0, tvOS 14.2, watchOS 7.1
IDEs:
Android Studio: 4.1 AI-201.8743.12.41.6953283
Xcode: 12.2/12B45b – /usr/bin/xcodebuild
npmPackages:
expo: ^40.0.0 => 40.0.0
react: 16.13.1 => 16.13.1
react-dom: 16.13.1 => 16.13.1
react-native: https://github.com/expo/react-native/archive/sdk-40.0.0.tar.gz => 0.63.2
react-native-web: ~0.13.12 => 0.13.18
npmGlobalPackages:
expo-cli: 4.0.13
Expo Workflow: managed

Reproducible Demo

class HandlePushNotifications extends Component {
    componentDidMount() {
        this.onResponseReceivedListener = Notifications.addNotificationResponseReceivedListener(
            this.handlePush <-- This is never triggered when the app was killed on iOS.
        );
    }
}

Steps to Reproduce
Kill the app, Send a push notification, tap on that push (it opens the app)

Expected Behavior vs Actual Behavior
Expected Behavior: Notifications.addNotificationResponseReceivedListener triggers since the user interacted with the push.
Actual Behavior: The triggering of Notifications.addNotificationResponseReceivedListener never occurs.

3 thoughts on “addNotificationResponseReceivedListener and useLastNotificationResponse not triggered for killed iOS apps SDK 40

  1. @sjchmiela For me the problem is that useLastNotificationResponse does not trigger with the app killed on iOS. My impression is that on your example the app is backgrounded, which doesn’t present issue on my apps.

  2. Hey guys, I just reproduced it, I’ll take a look into what we can do to fix this. As a workaround I can only suggest ejecting to bare workflow where this bug does not exist as far as I know.

    EDIT: the problem is most probably caused by ExpoKit registering its own legacy notification manager before aforementioned EXNotificationsEmitter is initialized which causes the legacy manager to consume all pending notification responses — they never get to expo-notifications.

    We’ll fix this as soon as possible.

  3. If by any npm stuff on local dev you mean:

    • any patches made to packages on local dev — no, the fixes were native-only so if you’re in managed workflow you don’t need to worry, I updated the native code for you!
    • any package updates — no, the fixes were native-only, so:
      • if you’re in managed workflow you don’t need to worry, I updated the native code for you!
      • if you’re in bare workflow you don’t need to worry, the bug did not exist there (it was caused by stuff we do in standalone apps and Expo Client). 🙂