[expo-notifications] setBadgeCountAsync(0) also clears notifications

[kaitlyn-lighthouse]

Minimal reproducible example

see steps in summary

What platform(s) does this occur on?

iOS

Did you reproduce this issue in a development build?

Yes

Summary

I'm using expo-notifications on iOS only. If I call setBadgeCountAsync with any positive integer, the badge count is updated, and any notifications currently in the iOS notification center remain unchanged. However if I call setBadgeCountAsync(0), the badge disappears correctly, but all notifications are also dismissed.

Expected behavior

Calling setBadgeCountAsync(0) removes the badge but leaves any existing push notifications visible in the notification center.

Actual behavior

Calling setBadgeCountAsync(0) removes the badge and all existing push notifications.

Steps to reproduce

1. Create the default expo app using the CLI and install expo-notifications
2. Ask the user for push notification permission, and send them one or more push notifications using expo.dev/notifications.
3. Call setBadgeCountAsync(0) and see that the notifications disappear from the notification center

Environment

expo-env-info 1.2.0 environment info:
System:
OS: macOS 14.3
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
npm: 10.2.4 - ~/Documents/bloom/ui-mobile/node_modules/.bin/npm
Managers:
CocoaPods: 1.15.2 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.4, iOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.1, watchOS 10.4
IDEs:
Xcode: 15.3/15E204a - /usr/bin/xcodebuild
npmPackages:
@expo/metro-config: ~0.10.0 => 0.10.7
@expo/webpack-config: ^19.0.1 => 19.0.1
expo: ^49.0.21 => 49.0.21
react: 18.2.0 => 18.2.0
react-dom: 18.2.0 => 18.2.0
react-native: 0.72.10 => 0.72.10
react-native-web: ~0.19.10 => 0.19.10
Expo Workflow: bare

Expo Doctor Diagnostics

✔ Check Expo config for common issues
✔ Check package.json for common issues
✔ Check dependencies for packages that should not be installed directly
✔ Check npm/ yarn versions
✔ Check for issues with metro config
✔ Check for common project setup issues
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check native tooling versions
✖ Check that packages match versions required by installed Expo SDK
✔ Check for legacy global CLI installed locally
✔ Check that native modules do not use incompatible support packages
✔ Check that native modules use compatible support package versions for installed Expo SDK

Detailed check results:

Some dependencies are incompatible with the installed expo version:
@sentry/[email protected] - expected version: 5.10.0
[email protected] - expected version: ~7.1.0
Your project may not work correctly until you install the correct versions of the packages.
Fix with: npx expo install --fix
Found outdated dependencies

[expo-bot]

Hi there! It looks like your issue requires a minimal reproducible example, but it is invalid or absent. Please prepare such an example and share it in a new issue.

The best way to get attention to your issue is to provide a clean and easy way for a developer to reproduce the issue on their own machine. Please do not provide your entire project, or a project with more code than is necessary to reproduce the issue.

A side benefit of going through the process of narrowing down the minimal amount of code needed to reproduce the issue is that you may get lucky and discover that the bug is due to a mistake in your application code that you can quickly fix on your own.

Resources

• "How to create a Minimal, Reproducible Example"
• "How to narrow down the source of an error"

Common concerns

"I've only been able to reproduce it in private, proprietary code"

You may not have spent enough time narrowing down the root cause of the issue. Try out the techniques discussed in this manual debugging guide to learn how to isolate the problem from the rest of your codebase.

"I didn't have time to create one"

That's understandable, it can take some time to prepare. We ask that you hold off on filing an issue until you are able to fully complete the required fields in the issue template.

"You can reproduce it by yourself by creating a project and following these steps"

This is useful knowledge, but it's still valuable to have the resulting project that is produced from running the steps, where you have verified you can reproduce the issue.

[brentvatne]

What you are encountering is an expected behavior of iOS for the API used - if you look at the implementation of setBadgeAsync, it is quite straightforward: 

expo/packages/expo-notifications/ios/EXNotifications/EXBadgeModule.m

Lines 19 to 34 in 949423c

	EX_EXPORT_METHOD_AS(setBadgeCountAsync,
	setBadgeCountAsync:(NSNumber *)badgeCount
	resolve:(EXPromiseResolveBlock)resolve
	reject:(EXPromiseRejectBlock)reject)
	{
	[[UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings * _Nonnull settings) {
	dispatch_async(dispatch_get_main_queue(), ^{
	if (settings.badgeSetting == UNNotificationSettingEnabled) {
	[EXSharedApplication() setApplicationIconBadgeNumber:badgeCount.integerValue];
	resolve(@(YES));
	} else {
	resolve(@(NO));
	}
	});
	}];
	}

- it calls setApplicationIconBadgeNumber, which has the side effect that you describe.

One thing you could try is setting the value to -1 (source: StackOverflow). It also looks like iOS 16 may have introduced a new API that doesn't have this quirk (source: also StackOverflow).

cc @douglowder

[kaitlyn-lighthouse]

Setting the value to -1 does seem to work, thank you! It would be great to add a note in the docs if possible so that others don't have the same issue

[brentvatne]

@kaitlyn-lighthouse - makes sense! can you send a pull request for that?