@MobileTen thank you for your help, unfortunately neither breaking up nor hyphenating the word to "simply go tab", "simply-go tab" or "simply-go-tab" does help, "tab" is still spoken "T A B"

Seems like issues are resolved with Xcode 15.4

Here is my class for reference final class BackgroundTaskManager: NSObject { private var cancellables = Set<AnyCancellable>() func registerTasks() { BGTaskScheduler.shared.register(forTaskWithIdentifier: BackgroundTaskManager.processingIdentifier, using: nil) { [manager = self] task in manager.handle(task: task) } } func cancelAllTasks() { BGTaskScheduler.shared.cancelAllTaskRequests() } func scheduleTasks() { scheduleProcessingTask() } private func scheduleProcessingTask() { let request = BGProcessingTaskRequest(identifier: BackgroundTaskManager.processingIdentifier) request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) request.requiresNetworkConnectivity = true do { try BGTaskScheduler.shared.submit(request) } catch { print(error.localizedDescription) } } } extension BackgroundTaskManager { private static let processingIdentifier = "SOMEIDENTIFIER" } extension BackgroundTaskManager { public static let shared = BackgroundTaskManager() } extension BackgroundTaskManager { func handle(task: BGTask) { let provider = HealthDataProvider() let steps = Future { promise in provider.getTodaysSteps { result in promise(result) } } let distance = Future { promise in provider.getDistance { result in promise(result) } } Publishers.Zip(steps, distance) .flatMap { steps, distance -> AnyPublisher<HealthPostRequest.Parser.OutputType, Error> in let date = Date() let healthPostRequest = HealthPostRequest(steps: steps, distance: distance, date: date) return API.shared.postHealth(healthPostRequest: healthPostRequest) .eraseToAnyPublisher() } .sink() .store(in: &cancellables) } }

Nevermind, it was a weak referencing issue.

I reported a bug (9120983) for this and I really hope this gets resolved (soon-ish). In the meantime I might use a library that supports this. Thank you both, Quinn and Matt, for your time and help.

One known workaround here is to just respond to the entire group and then indicate via SSDP where your response is coming from. I understand that this is not the best workaround for SSDP, but it does work at the moment. Hey Matt! Thank you for your answer and time! If I understood you correctly, you are suggesting the devices in the network to respond to the group instead sending back responses with unicast. If that is the case, then this is not a viable workaround for me, as I have no control over the devices within somebody's network. If that is not what you meant, then I would kindly ask for a snippet showcasing the workaround. Also the Network framework does not seem to be open source anymore? At least the ones I have found are a few years old.

192.168.1.47 is my device, Network opens a random port, 57367 in this case, and sends an UDP packet with length of 94 (my SSDP request) to 239.255.255.250:1900. My Router, 192.168.1.1, forwards any UDP response from devices within the network to my iOS device at 192.168.1.47:57367. So sending SSDP works, devices within the network respond, messages are being forwarded to my iOS device but it seems like Network does not handle received messages?

Hey Quinn! Thank you for your answer! I tried running both commands you provided. First one returns the plist with my entitlement, so that's fine. Archived project has the embedded.mobileprovision file which also includes the entitlement. Assume NWConnectionGroup it is strong referenced and not deallocated going forward. Also I get messages from devices in the network when they publish themselves but not when I send my package. I tried packet capturing and I can confirm that messages are being sent and my router responds with the response. It works with a different app from the App-Store, they are using the upnpx library. Using the open source library BlueSocket works as-well, but I am trying to stick to the Network framework. Data captured from reference app: 15:42:35.873001 IP 192.168.1.47.59611 239.255.255.250.1900: UDP, length 157 15:42:35.927494 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 438 15:42:35.927501 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 406 15:42:35.927503 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 426 15:42:35.927504 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 430 15:42:35.927505 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 358 15:42:35.927506 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 367 15:42:35.927507 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 367 15:42:35.927508 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 367 15:42:35.927510 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 422 15:42:35.927511 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 422 15:42:35.927512 IP 192.168.1.1.1900 192.168.1.47.59611: UDP, length 420 Data captured from my app: 15:42:53.975416 IP 192.168.1.47.57367 239.255.255.250.1900: UDP, length 94 15:42:54.032783 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 367 15:42:54.032788 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 367 15:42:54.032790 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 367 15:42:54.032791 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 422 15:42:54.032793 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 422 15:42:54.032794 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 420 15:42:54.032795 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 438 15:42:54.032796 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 406 15:42:54.032798 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 426 15:42:54.032800 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 430 15:42:54.032801 IP 192.168.1.1.1900 192.168.1.47.57367: UDP, length 358 According to the logs, I am able to send multicast packets Seems like remote peer does respond I do, for some reason, do not receive the response