Thanks Quinn! With the understanding that we can't reasonably ask users to kill 3rd party apps, this means that using the Network framework to implement an SSDP client is not recommended at this time? I just want to be clear that there isn't a Network way to implement the SSDP client that I somehow missed. Here is the bug# FB11642799 (SSDP clients broken by unrelated 3rd party apps)

Yes after cloning the test app, same interference. The first opened app will be in status ready, and the app started subsequently will show the error status failed(POSIXErrorCode ....address already in use)

Yes allowLocalEndpointReuse is set to true Here is the entire code from the test app in the GitHub repository import Foundation import UIKit import Network class ViewController: UIViewController {   @IBOutlet weak var stateLabel: UILabel! var connectionGroup: NWMulticastGroup!   override func viewDidLoad() {     super.viewDidLoad()     let multicastGroup = try! NWMulticastGroup(for: [ .hostPort(host: "239.255.255.250", port: 1900) ])     let parameters = NWParameters.udp     parameters.allowLocalEndpointReuse = true     let connectionGroup = NWConnectionGroup(with: multicastGroup, using: .udp)     stateLabel.text = "\(connectionGroup.state)"     connectionGroup.setReceiveHandler(maximumMessageSize: 16384, rejectOversizedMessages: true) { message, content, isComplete in       NSLog("Received \(content?.count ?? 0) bytes from \(String(describing: message.remoteEndpoint))")     }     connectionGroup.stateUpdateHandler = { newState in       NSLog("Group entered state \(String(describing: newState))")       self.stateLabel.text = "\(newState)"     }     connectionGroup.start(queue: .main)   } }

If that's helpful, we did find a solution to our most immediate problem (the crash itself): digging through our own code we discovered that our logic to recover from an unexpected disconnect event was flawed, as our app was calling connect more than once in response to a single disconnect event. The crash went away after we cleaned up redundant connect calls. It is still unclear why iOS 13, 14 were unaffected by the redundant calls - but it no longer matters at this point.

I figured it out - I had moved the project into the same workspace which contains the local Swift Package dependencies: building the project was my mistake, I should have been building the workspace. In other words xcodebuild -workspace "../MyWorkSpace.xcworkspace" -scheme "MyScheme instead of xcodebuild -project "../MyProj.xcodeproj" -scheme "MyScheme"

Addendum, the WWDC video "What's new in App Store Connect" - https://developer.apple.com/videos/play/wwdc2020/10651/, says from 14:24 If you want to check the validation status of your App Clip, go to the build details page in App Store Connect. From here, click the View Status link in the App Clip section, and this will bring up a modal showing domain validation status. Well ....no App Clip section for me on the build details page, though the Store Information section does show the App Clip's application identifier (and other info related to the App Clip embedded with the App)

I forgot to mention I also checked that my apple-app-site-association can be GET'd from https://[my-associated-domain]/.well-known/apple-app-site-association, and that the json array returned does contains the app clip info like so { 		"appclips": { 				"apps": ["ABCED12345.com.example.MyApp.Clip"] 		} }