Swift 6

[quote='847299022, Peter_Si, /thread/789165?answerId=847299022#847299022, /profile/Peter_Si'] Can you help me understand the difference between a NetworkExtension.NWEndpoint and Network.NWEndpoint and where I would need to use one versus the other? [/quote] Sure. And that is, indeed, a gnarly edge case. NetworkExtension.NWEndpoint is an Objective-C class. It was introduced prior to the introduction of Network framework proper. Network framework is a Swift API [1] and, in Swift, it makes sense to represent endpoints as an enum, so Network.NWEndpoint is an enum. Quoting TN3151 Choosing the right networking API: Network Extension in-provider networking includes NWUDPSession. While there are some very limited circumstances where this is still useful, in most cases it’s better to use Network framework. For more details, see In-Provider Networking. So, what are those circumstances? In short: If your product supports system prior to the introduction of Network framework, that is, macOS 10.14. That’

I created a minimal SwiftUI macOS app that consistently reproduces the same ViewBridge warning. The issue occurs only when using a SecureField view in a Settings scene, not in a standard WindowGroup scene. Reproduction Steps Launch the application Open the Settings window (⌘,) Close the Settings window Open the Settings window again (⌘,) The Warning Upon reopening the Settings window, the following warning appears in the console: ViewBridge to RemoteViewService Terminated: Error Domain=com.apple.ViewBridge Code=18 (null) UserInfo={com.apple.ViewBridge.error.hint=this process disconnected remote view controller -- benign unless unexpected, com.apple.ViewBridge.error.description=NSViewBridgeErrorCanceled} Key Observations The warning only occurs when a SecureField view is present in a Settings scene The same SecureField view in a WindowGroup scene does not trigger the warning when repeatedly opening and closing the main window (⌘N) Environment OS: macOS 15.3.2 SDK: macOS 15.4 IDE: Xcode 16.3 Compiler: Swift 6

ABI stability isn't the issue here — enabling module stability through the library evolution build flags is. When you build an XCFramework, you need to enable the BUILD_LIBRARY_FOR_DISTRIBUTION build setting, which enables library evolution for the module defined by the Xcode target to which you're applying that build setting. That causes a swiftinterface file to be output as part of the build, which is the textual representation of your module's interface that is stable for newer complier versions to consume. When you import SomePackage into your module, module stability is not conveyed for that imported module, it too would need to enable module stability. Further, the public interface with all of the types of that imported module becomes part of the public interface in your final XCFramework. So if I look at the arm64-apple-ios.swiftinterface in your test project's XCFramework, I see this: // swift-interface-format-version: 1.0 // swift-compiler-version: Apple Swift version 5.10

I boiled your question down to this: 1 class Test { 2 3 func asd() { 4 } 5 6 func test() { 7 DispatchQueue.global().async { [self] in 8 DispatchQueue.main.async { 9 self.asd() 10 } 11 DispatchQueue.main.async { [self] in 12 asd() 13 } 14 DispatchQueue.main.sync { 15 self.asd() 16 } 17 DispatchQueue.main.sync { [self] in 18 asd() ^ Call to method 'asd' in closure requires explicit use of 'self' to make capture semantics explicit; this is an error in Swift 6 19 } 20 } 21 } 22 } This is an interesting glitch in the matrix. It’s definitely triggered by the context set up by line 7. Without that, you don’t see the warning. The immediate fix here is to use an explicit self, as shown by lines 14 through 16. As to why capturing self on line 17 still triggers the warning, I’m not sure. It’s probably worth filing a bug about that. Please post your bug number, just for the record. Taking a step back, this overall approach is kinda worrying. First, I recommend against using Dispatch global concurrent qu

Folks, This conversation will go more smoothly if you reply as a reply, rather than in the comments. See Quinn’s Top Ten DevForums Tips for this and other tips. eoonline wrote: for the sake of future readers, that alone is insufficient. Agreed. As that’s a critical point of my previous post, I’ve edited that post to clarify it. Thanks for pointing this out. Praveenraj4256 wrote: Using Task.detached is better approach? No. In general, you should try to avoid creating new tasks wherever possible. [quote='817895022, Praveenraj4256, /thread/770655?answerId=817895022#817895022, /profile/Praveenraj4256'] I want to achieve the same functionality using structured concurrency [/quote] I think it’s a mistake to look for ‘drop in’ replacements for old techniques. The key thing to remember about Swift concurrency is that the isolation context of your code is determined statically [1]. That’s a benefit for you — you can look at the code and understand its isolation context — but it’s of critical importance to the