Swift 6

[quote='779913021, duoskater, /thread/779913, /profile/duoskater'] Also, are there any plans to migrate eg. CoreBluetooth stack to new swift 6 concurrency? [/quote] I can’t talk about The Future™. If you’d like to see improvements in this space, I recommend that you file an enhancement request explaining what you’re doing, what’s causing you grief, and what you’d like to see change. If you do file this, please post your bug number, just for the record. [quote='779913021, duoskater, /thread/779913, /profile/duoskater'] I wonder if something has changed in this regards? [/quote] Yes and no. Integrating run loop based APIs clearly into a Swift 6 codebase is still quite tricky. I’ve spent a bunch of time playing around with that lately and my conclusion was… yeah… try to avoid that if you can |-: There is one special case here, namely the main thread’s run loop. If you do all your run loop work on the main thread, things go relatively smoothly. Whether that’s practical or not depends on the natu

Thanks for the crash report. Consider this snippet: @MainActor var counter = 0 @main class AppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions …) -> Bool { counter += 1 let authOptions: UNAuthorizationOptions = [.alert, .badge, .sound] UNUserNotificationCenter.current().requestAuthorization(options: authOptions) { _, _ in counter += 1 } return true } … } I’m compiling this with Xcode 16.0 in the Swift 6 language mode. The increments of counter show that Swift thinks that both application(_:didFinishLaunchingWithOptions:) and the closure are supposed to be running on the main actor. However, the closure called by requestAuthorization(options:completionHandler:) is documented to not run there. I’d expect that the compiler would insert code to ‘bounce’ to the main actor, but instead it inserted code to trap if it’s not on the main actor. I’m not sure why it thinks that in this context. Oh, and I checked with the lates

The topic is very interesting, and I humbly acknowledge that I haven’t grasped all the subtleties of Swift 6 (I’ll need to improve my skills on this subject). Here’s more information: my application takes input data and generates an output file. The file generation (which is complex) is carried out on a secondary thread (old school with GCD). Compatibility with Swift Concurrency is handled through a facade using withCheckedThrowingContinuation. The processes performed on the secondary thread (file creation) require configuration data that is used solely in a read-only way (the secondary thread does not modify this data, which is encapsulated in an object). In short, it looks something like this (names have been simplified for the example): Job (file creation on a secondary thread using GCD) AsyncJob (a facade over Job to ensure compatibility with Swift Concurrency) Configuration (data needed for the job processing) Code example: do { let configuration = Configuration(...) let job =

I know you said to ignore this, but I want to post some info just in case other folks bump into it. For historical reasons, Network framework and Network Extension framework export different types with the same name. The list of such types includes NWPath and NWEndpoint. Historically: This caused ambiguous type problems if you imported both frameworks. The workaround was to fully qualify the name. So, instead of NWEndpoint, you would use Network.NWEndpoint or NetworkExtension.NWEndpoint. If that caused too much grief, you could deploy some type aliases: ### NWHelper.swift ### import Network typealias NWEndpoint = Network.NWEndpoint ### NEHelper.swift ### import NetworkExtension typealias NEEndpoint = NetworkExtension.NWEndpoint ### main.swift ### func test(endpointNW: NWEndpoint, endpointNE: NEEndpoint) { } This has changed in Xcode 16. If you’re in the Swift 5 language mode, things behave as they did previously. However, in the Swift 6 language mode the Network Extension types have been mad

I was gonna say that this looks remarkably like an issue I’ve been working on a different thread, but then I noticed that you’re the OP on that thread too. So, yeah, this is a similar issue and, as I mentioned over there, I’m still not 100% sure I fully understand all of these cases. However, I do have a suggestion for you. Consider this snippet: @MainActor class AudioPlayerProvider: ObservableObject { func setMetadataQ() { let defaultArtwork = UIImage(systemName: fireworks)! let nowPlayingInfo = [ MPMediaItemPropertyTitle: Hello, MPMediaItemPropertyArtist: Cruel World!, MPMediaItemPropertyArtwork: MPMediaItemArtwork(boundsSize: defaultArtwork.size) { _ in defaultArtwork }, ] as [String: Any] MPNowPlayingInfoCenter.default().nowPlayingInfo = nowPlayingInfo } } @MainActor func test() { let o = AudioPlayerProvider() o.setMetadataQ() } I put this into a small test project, built it with Xcode 16.0 in Swift 6 mode, and ran on an iOS 18.0 device. It crashed exactly like your code. I resolved the crash by

The issue here is that: The data race protection in Swift 6 requires that the compiler be able to understand the context in which code is run. Timer.scheduledTimer(…) runs the timer callback on the current run loop, which isn’t a concurrency mechanisms that the Swift compiler understands. Fixing this isn’t trivial in the general case, but there’s an easy fix in this case. You’re calling Timer.scheduledTimer(…) from a main-actor-isolated context, which means you’re on the main thread. Thus the timer will schedule its callback on the main thread’s run loop, and you just need to let the Swift compiler know that. The canonical way to do that is with MainActor.assumeIsolated(_:). For example: self.timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in MainActor.assumeIsolated { … the compiler now knows you’re on the main actor, trapping at runtime if that’s not the case … } } Pasted in below is a more complete example. Share and Enjoy — Quinn “The Eskimo!” @ Developer

I also try to be a good app, and provide asynchronous support. I think that's your problem. It's too difficult to keep up with that. Your asynchronous code is already deprecated and disavowed. First of all, make sure you try using the ClipboardViewer tool. I think it's in Xcode's AdditionalTools as a separate download. I know you're dealing with Drag and Drop, which is not quite the same, but it may be enlightening as most people implement Copy and Paste with the same data. I've never tried dragging from Safari, but I certainly never seen any TIFF conversions. I even support data types that the system doesn't, so there's no way it ever could convert it. Again, I think you're trying too hard. Instead of itemProvider.loadInPlaceFileRepresentation, try just loadItem. That should give you the actual URL. You might run into concurrency problems. I seem to have encountered that myself with these APIs. Unfortunately, there's no easy solution. You definitely don't want to try those old dispatch queues, at least not i

@DTS Engineer I spent sometime and enabled concurrency checks to complete in the compiler options. I was able to fix two main sources of warning (which are error in Swift 6) by changing the definition of two functions as follows: func capturePhoto(with features: PhotoFeatures, isolation: isolated (any Actor)? = #isolation) async throws -> Photo func stopRecording(_ isolation: isolated (any Actor)? = #isolation) async throws -> Movie Effectively, I forced these functions to be called from the isolation domain of an Actor (which is actor CaptureService in the source code). I believe this should be okay as this is the only place where these functions are invoked. However, there is one place in the code where I still need help: ```` override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey: Any]?, context: UnsafeMutableRawPointer?) { switch keyPath { case systemPreferredKeyPath: // Update the observer's system-preferred camera value. let newDevice = chang

I believe the crash (with the Incorrect actor executor assumption message) is intentional. When you use the Swift 6 mode to build your app, the compiler adds some runtime checks to detect problems that could otherwise cause a data race. If a check is not satisfied, it triggers a crash. I am by no means an expert of Swift compiler, but here is my theory about what happens in your case: a. ConnectivityManager is actor-isolated, meaning that, in your code snippet, self.session.sendMessageData(...), the replyHandler closure, and also the errorHandler closure are supposed to run in the actor's executor. b. WCSession.sendMessageData(...) doesn't really run replyHandler (or errorHandler) in the calling queue. This is mentioned in the API reference: If you specify a reply handler block, your handler block is executed asynchronously on a background thread. For some reason, the compiler doesn't detect the problem at the compile time, but at runtime, replyHandler (or errorHandler) is running in a queue