I'm not sure I understand; that's the way it's supposed to work? See the docs for init(dateMatching:repeats:): Discussion If you specify true for the repeats parameter, you must explicitly remove the notification request to stop the delivery of the associated notification. Use the methods of UNUserNotificationCenter to remove notification requests that are no longer needed. So in response to, say, some user action you have to remove the notification yourself.

I think I was able to solve a similar problem, though my problem was slightly different. The short answer is: use at least a .userInitiated qualityOfService in Catalyst; when the qualityOfService is .default (or below) requests become discretionary when the app is in the background (i.e., inactive). And I think that's where the problem is. For a longer answer, see my response on Stack Overflow.

I'm seeing various UISearchController/UISearchBar bugs too. One example: on iPhone (and only on iPhone) setting searchBar.searchTextField.backgroundColor has no effect. If I wrap the set in a Task it works — until the search field scrolls out of view and back in. Then it once again has the wrong background color. Furthermore, if I use something like .integratedButton for my searchBarPlacement I'm seeing a lot of animation stutters when the search bar button item morphs from a button into a field and, later, from a field to a button. It's a nice idea, but a poor implementation.