“Xcode”

Distribution through the App Store requires a minimum deployment target of iOS 15. The Xcode Support webpage has this information.

I tried to open my project with Xcode 26.5 beta 1 and to view the Preview of some SwiftUI views present in local Packages referenced by the project, and they worked as expected, without any issue. I also tried with the very simple test project, and the result is the same. I can say that this Xcode 26.5 beta 1 behaves like Xcode 25.3. Thank you for this message.

I understand that I need to convert it to a Network Extension. What about testing? Is it still possible to run it through Xcode for testing? It seems like I would have to install the system extension over and over again to test it—am I right? Thank you for your respond

This is still happening in the debug console, app not crashing. Wonder if this is something I can ignore? A fix is documented elsewhere? Not fixed? The Apple sample app SwiftDataFlashCardSample prints the same log messages than my app I just started to implement. On macOS Tahoe 26.4 (25E246), Xcode Version 26.4 (17E192).

I have the same issue, Xcode 26.4, Objective-C project.

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.