Testing Environment:
iOS Version: 26.0 Beta 7
Xcode Version: 17.0 Beta 6
Device: iPhone 16 Pro
Description: We are implementing the new BGContinuedProcessingTask API and are using the wildcard identifier notation as described in the official documentation. Our Info.plist is correctly configured with a permitted identifier pattern, such as com.our-bundle.export.*.
We then register a single launch handler for this exact wildcard pattern. We are performing this registration within a UIViewController, which is a supported pattern as BGContinuedProcessingTask is explicitly exempt from the "register before applicationDidFinishLaunching" requirement, according to the BGTaskScheduler.h header file. The register method correctly returns true, indicating the registration was successful.
However, when we then try to submit a task with a unique identifier that matches this pattern (e.g., com.our-bundle.export.UUID), the BGTaskScheduler.shared.submit() call throws an NSInternalInconsistencyException and terminates the app. The error reason is: 'No launch handler registered for task with identifier com.our-bundle.export.UUID'.
This indicates that the system is not correctly matching the specific, unique identifier from the submit call to the registered wildcard pattern handler. This behavior contradicts the official documentation.
Steps to Reproduce:
Create a new Xcode project.
In Signing & Capabilities, add "Background Modes" (with "Background processing" checked) and "Background GPU Access".
Add a permitted identifier (e.g., "com.company.test.*") to BGTaskSchedulerPermittedIdentifiers in Info.plist.
In a UIViewController's viewDidLoad, register a handler for the wildcard pattern. Check that the register method returns true.
Immediately after, try to submit a BGContinuedProcessingTaskRequest with a unique identifier that matches the pattern.
Expected Results: The submit call should succeed without crashing, and the task should be scheduled.
Actual Results: The app crashes immediately upon calling submit(). The console shows an uncaught NSInternalInconsistencyException with the reason: 'No launch handler registered for task with identifier com.company.test.UUID'.
Workaround: The issue can be bypassed if we register a new handler for each unique identifier immediately before submitting a request with that same unique identifier. This strongly suggests the bug is in the system's wildcard pattern-matching logic.
This indicates that the system is not correctly matching the specific, unique identifier from the submit call to the registered wildcard pattern handler. This behavior contradicts the official documentation.
You've misunderstood what the wildcard pattern system is "for". The wildcard system exists to support two cases:
-
Apps that want to have a number of static task handlers, but want to avoid needing to specifically list all of them.
-
Apps that want to dynamically generate task identifiers as needed, using an approach like this:
Workaround: The issue can be bypassed if we register a new handler for each unique identifier immediately before submitting a request with that same unique identifier.
Registering a wild card handler like this:
We then register a single launch handler for this exact wildcard pattern.
...is specifically blocked, as it would greatly both the routing of new jobs (if specific as well as generic handlers are allowed) and it would require your block to be reentrant (an API pattern we generally avoid).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
