“Xcode”

Xcode 26.5 Beta 1 was just released which the team believes should address the issues y'all were seeing here. Would you be able to give it a go and let us know what you see?

yeah i have the same bug with the new xcode 26.4 for me an short time solution is to downgrade xcode to the old version there it works like it have always been

FB22362166 Thanks! AFAICT this is Just A Bug™. I’m seeing a similar issue with my Xcode 26.4 install (a public release of Xcode 26.4 running on a public release of macOS 26.3.1). I suspect it’s due to the recent work to synchronise documentation between Apple > Developer and Swift > Documentation. However, we won’t know for sure until your bug has had more chance to find its way through our systems. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882371022, Arebus, /thread/820871?answerId=882371022#882371022, /profile/Arebus'] I thought it would be easier to write a CLI than … [/quote] Yeah, I know what you mean, but recently I’ve moved away from that approach: For low-level stuff, I tend to put the test code into a unit test. This is just as easy to debug as a command-line tool, but it has the advantage that, as you exercise various code paths, you build up a corpus of unit tests that ensure that things continue to work in the future. For GUI stuff, I lean into Xcode’s preview feature. Or just do my experimentation in an target. And there’s Xcode’s UI testing support. I don’t use that a lot but, in my defence, UI stuff isn’t my focus. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Quinn, Following up on your earlier advice about using NEAppProxyUDPFlowHandling and the async readDatagrams / writeDatagrams API. I’ve updated my DNS proxy as follows: I now implement NEAppProxyUDPFlowHandling and handle DNS over UDP via the async API. For each flow, I store the Network.NWEndpoint that comes from readDatagrams() and then pass that same endpoint back into writeDatagrams. I no longer use NWHostEndpoint / NetworkExtension.NWEndpoint anywhere in this path. Relevant code (stripped down): private func readFirstDatagrams(from udpFlow: NEAppProxyUDPFlow, into flow: Flow, channel: Channel) { Task { let (pairs, error) = await udpFlow.readDatagrams() if let error = error { // handle error... return } guard let pairs = pairs, !pairs.isEmpty else { // retry... return } let (firstData, firstEndpoint) = pairs[0] let size = firstData.count MainLogger.shared.log(message: UDP recv (pairs.count) datagrams, first size=(size) from=(firstEndpoint) type=(type(of: firstEndpoint)) ) // Force a hostPort e

[quote='821027021, Pavel, /thread/821027, /profile/Pavel'] For debugging purposes, I am trying to run the daemon's executable directly from the terminal [/quote] This won’t work. For your launchd daemon to work correctly, it must be started by launchd. I explain why that’s the case in XPC and App-to-App Communication. My general advice for debugging a launchd daemon is: Structure your code so that you can do most of your debugging in unit tests, rather than in your daemon. That’ll make your life much easier. To unit test your XPC code, use the technique in TN3113 Testing and debugging XPC code with an anonymous listener. To debug integration issues: Using LLDB’s --wait-for option to attach to the daemon shortly after it starts. There’s a similar option in Xcode, under Debug > Attach to Process by PID or Name. Or if you absolutely need to debug from the first instruction, add the WaitForDebugger property to your launchd property list. See the launchd.plist man page for details. [quote='821027021, P

Not just Xcode 26 — re-releasing with an older version of Xcode has the same issue. For users on iOS 12 and below, the app can no longer launch.

The same codebase previously ran fine when uploaded to TestFlight, but after re-uploading it now fails to launch on iOS 12, even though neither the code nor the Xcode version has changed. I suspect a recent change in the App Store Connect backend processing pipeline is the cause.

Also one more point, when i integrated metric Kit and used Xcode to simulate MetricKit payloads, i was getting the callback i.e func didReceive(_ payloads: [MXMetricPayload]) Main issue was that when i launched my app with changes and waited for more than 24 hours, but i did not get any callback, so wanted to know if it works on background apps or not? Also does it work on MacOS or not? Could u pls help to answer it