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 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 just ran into a similar problem and discovered that my schemes referenced old configurations, configurations that no longer existed. Once I updated them to the correct configurations the build succeeded.   (I'm leaving this comment about a year later. It's possible that what I ran into is completely different from what was originally reported. Still, it took me quite a while to track the problem down, so I wanted to leave a note that might save others time.)

I think I've run into another variation of this (now in Xcode 11.6). I think there are two additional problems. I have two local Swift packages that reference two remote Swift packages. (The remote packages are Apple's SwiftProtobuf and RevenueCat.) When I build for testing, both of the local Swift packages generate errors. The error for the package that references SwiftProtobuf is a compiler error: Command CompileSwift failed with a nonzero exit code The error for the package that references RevenueCat is a linker error: Undefined symbols for architecture x86_64:   "___ubsan_handle_nonnull_arg", referenced from:       -[RCPurchaserInfo setUpDateFormatter] in Purchases.o       -[RCPurchases dispatch:] in Purchases.o   "___ubsan_handle_float_cast_overflow", referenced from:       -[NSDate(RCExtensions) millisecondsSince1970] in Purchases.o   "___ubsan_handle_load_invalid_value", referenced from:       _RCSetShowDebugLogs in Purchases.o       _RCShowDebugLogs in Purchases.o       _RCDebugLog in Purchases.o       _RCErrorLog in Purchases.o       -[RCSystemInfo initWithPlatformFlavor:platformFlavorVersion:finishTransactions:] in Purchases.o       -[RCSystemInfo finishTransactions] in Purchases.o       -[RCSystemInfo setFinishTransactions:] in Purchases.o       ...   "___ubsan_handle_pointer_overflow", referenced from:       ___32-[NSData(RCExtensions) asString]_block_invoke in Purchases.o   "___ubsan_handle_type_mismatch_v1", referenced from:       -[RCInMemoryCachedObject setCacheDurationInSeconds:] in Purchases.o       ___32-[NSData(RCExtensions) asString]_block_invoke in Purchases.o       -[RCSystemInfo setFinishTransactions:] in Purchases.o       -[RCHTTPClient setSystemInfo:] in Purchases.o       -[RCIntroEligibility setStatus:] in Purchases.o       -[RCPurchaserInfo setUpDateFormatter] in Purchases.o       -[RCPurchases allowSharingAppStoreAccount] in Purchases.o       ... ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Here's the first issue: Both errors seem to be caused by the fact that one of my test configurations uses UBSan. As per the original post, my scheme has two configurations, a default one and one that enables UBSan. Here's the second issue: The errors persist even if I disable the UBSan test configuration. If I turn off UBSan in the (disabled) UBSan test configuration, everything builds and runs successfully.

I was able to resolve this. As far as I can tell, it's an Xcode bug.The short version is that Xcode seems to assume that at least one test configuration will use the shared (default) test configuration, unmodified. That assumption can of course be wrong; it's possible that no test configuration exactly matches the defaults. The mistake can prevent Xcode from finding the test target bundles for local Swift Packages.The long version...* A test plan has a shared (default) test configuration.* A test plan has one or more actual test configurations.* Xcode places build products in directories whose names are based on their differences from the shared (default) configuration.* The build products for test configurations that don't have any meaningful differences are placed under the root, e.g.: "/Products/***/...".* The build products for test configurations that do have meaningful differences are placed under subirectories whose names are derived from the differences, e.g.: "/Products/Variant-ASan-UBSan/***/...", "/Products/Variant-UBSan/***/...".* Some part of Xcode assumes that at least one test configuration will match the shared defaults. In other words, some part of Xcode assumes that a test bundle will always exist under the root, in "/Products/***/...".* In my case that wasn't true; my one and only test configuration enabled UBSan. That caused its build products to be placed in "/Products/Variant-UBSan/***/...". So, at least for my local Swift Packages, Xcode was looking in the wrong place: it was looking in the root rather than in a variant subdirectory under the root.* The workaround was to create a test configuration that didn't differ from the default.===As an aside, I mentioned that the local Swift Package targets were listed in the scheme. I eventually realized that that was a hold over from my pre-test plan configuration; that's how I was getting Xcode to test all packages together with the main app before converting. With the test plan in place I no longer need them listed directly in the scheme. Unfortunately, removing them didn't fix my actual problem.