Swift 6

Thanks for taking a look. I tried some more things and it looks like it's a misleading compiler error, maybe nothing to do with the path variable at all even though the compiler says it is. I took the path variable out of the function temporarily, then it gave another error: Task or actor isolated value cannot be sent; this is an error in the Swift 6 language mode. The containing class is marked as @Observable, so I'm assuming really it is complaining that self is getting pulled into the Task which can cause race conditions even though the compiler error does not say that. I added the Sendable protocol to the container class and the warning went away. Thanks for taking the time to look into it. Side note: Swift6 makes writing code miserable, it's so broken still, good idea poor execution.

Thanks @eskimo. I think I was confused why this code required await when turning on the Swift 6 extra concurrency warning/errors setting. self.applicationDidBecomeActiveSubscriber = NotificationCenter.default.publisher(for: UIApplication.didBecomeActiveNotification).sink() { [weak self] _ in self?.applicationDidBecomeActive() } In particular, it's surprising that UIApplication.didBecomeActiveNotification required @MainActor since this is essentially a constant string. It seems that because UIApplication requires @MainActor, referencing these class level properties bears the same obligation. In my particular case, this forces this code block into a Task{} because I don't want the enclosing function to be async. Which then means that it skips a run-loop execution cycle, causing me not to actually receive the didBecomeActive notification. (Note, this is just one example. I'm using several such notifications for a few different reasons). The mitigation appears to be to create my own clones of the UIAppli

[quote='806202022, DTS Engineer, /thread/764777?answerId=806202022#806202022'] I’m gonna do some more research about this (FB15294185) [/quote] I spent some time talking this over with various colleagues, just to make sure I fully understand what’s going on. The high-level summary is: Swift 6 has inserted a run-time check to catch a concurrency issue that Swift 5 did not. This isn’t caught at compile time because of a Swift / Objective-C impedance mismatch. If you want to know more, follow me down the rabbit hole! Consider this simplified version of Artecoop’s test code: @main final class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? func applicationDidFinishLaunching(_ application: UIApplication) { let center = UNUserNotificationCenter.current() center.requestAuthorization(options: [.alert, .sound, .badge]) { success, error in print(success) assert(Thread.isMainThread) } } } The entire did-finish-launching method should run on the main actor. That’s becaus

I'm getting the exact same error, very similar circumstances: extension NSItemProvider { func loadObject(ofClass: T.Type) async throws -> T? where T : _ObjectiveCBridgeable, T._ObjectiveCType : NSItemProviderReading { return try await withCheckedThrowingContinuation { continuation in _ = self.loadObject(ofClass: ofClass) { item, error in switch (item, error) { case (.some(let item), .none): continuation.resume(returning: item) /* Task-isolated value of type 'T' passed as a strongly transferred parameter; later accesses could race; this is an error in the Swift 6 language mode */ case (.none, .some(let error)): continuation.resume(throwing: error) default: let error = NSError(...) continuation.resume(throwing: error) } } } } } Based on the advice below I changed the method signature to: func loadObject(ofClass: T.Type) async throws -> T? where T : _ObjectiveCBridgeable, T._ObjectiveCType : NSItemProviderReading, T: Sendable which seems to have fixed it!

I just updated to macOS 15 Beta 3 and found something interesting. My App (pre macOS 15) from the AppStore worked fine yesterday with macOS 15 Beta 2 but now no longer does with macOS 15 Beta 3. Somehow going from Beta 2 to Beta 3 breaks NSHostingView for at least pre macOS 15 compiled apps. So I suspect it may be something with the OS and switched back to Swift 5. Essentially it looks like the NSHostingView breakage may not have anything to do with Swift 6 but something new in the OS that doesn't allow NSHostingView instances to accept user interaction anymore. Anyone know what might have possibly caused this? NSHostingView certainly was useful to those of us slowly transitioning to SwiftUI from AppKit and it would be unfortunate to have done all that transition work only to find out that NSHostingView is only partially usable in macOS 15. So I am wondering if someone has a workaround to nudge NSHostingView to work in the new macOS 15. In the meantime, I will keep trying to get NSHostingVie

I think you'll find that including contentURL as part of the initial query makes things significantly faster. Unfortunately CSUserQuery does not allow these types of query strings. CSUserQueryContext.filterQueries appears to be the only way to scope to contentURL. The issue is that Spotlight APIs appear to be App based & not Document based. Imagine that a user has created 2 documents, #1 & #2, but only #1 is currently open. The CSSearchableIndexDelegate.reindex* methods may be called by the system with identifiers from both files, but the app only has access to the DB for the open file. What is the correct way to handle this case? Only update the items for which #1 contains the identifiers? This will leave the indexed items for #2 in an invalid state. Should the acknowledgementHandler be called? Should the acknowledgementHandler be called if an error is encountered by a reindex* method? Swift 6.2, Swift 6 language mode: the reindex* methods call indexSearchableItems which in their ca

waldgeist, I recommend that you start a new thread for your specific issue. While the error you’re seeing is the same, the high-level task (doing work in parallel) is very different. Use the same topic, subtopic, and tags as this thread, so that I see it. bruceschek, It’s hard to offer specific guidance here because your paired down example is probable a little too paired down (-: It sounds like your final goal is to create an app. If so, keep in mind that the majority of your app’s UI code is isolated to the main actor, either explicitly or implicitly, and thus you’ll need to either show app code (like a view controller) or explicitly model that in your example. For the latter, you can build a ‘starter’ command-line tool like so: import Foundation @MainActor class Main { var counter: Int = 0 func run() async { counter += 1 } } await Main().run() Try reworking your example into this structure to see if it makes more sense. And if you get stuck, post an updated example and I’ll take a look. [quote='36174025, b

[quote='833063022, olonsky, /thread/779147?answerId=833063022#833063022, /profile/olonsky'] there’s one more issue: the value also needs to be sendable. [/quote] Which value are you talking about here? The value parameter of notifyListeners(…)? If so, that has to be sendable if you adopt the first choice I listed. If not, then you can avoid that constraint because you never cross between isolation domains (everything is bound to the main actor). [quote='833063022, olonsky, /thread/779147?answerId=833063022#833063022, /profile/olonsky'] I’m finding this more challenging [/quote] It’s definitely a challenge, but the more I work on this stuff the more I realise how important it is for the compiler to check this stuff for you. For example, I was recently stymied by the fact that Foundation’s Thread isn’t sendable. I’ve written Objective-C and pre-Swift 6 code for decades that just assumed that it was. How many weird crashes has that code caused over the years? Share and Enjoy — Quinn “The Eskimo!” @ Deve

For example there is a method func centralManager(_ cbCentralManager: CBCentralManager, didDiscover cbPeripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) from CBCentralManagerDelegate In our project we send advertisement data forward as we need it in the app to check if device is correct and to verify ids so that we will connect to right device. I made a Sendable structure for storing scan data: public let peripheral: Peripheral /// A dictionary containing any advertisement and scan response data. public let advertisementData: [String : Any] /// The current RSSI of the peripheral, in dBm. A value of 127 is reserved and indicates the RSSI /// was not available. public let rssi: NSNumber } and I get warning: Stored property 'advertisementData' of 'Sendable'-conforming struct 'ScanData' has non-sendable type '[String : Any]'; this is an error in the Swift 6 language mode So what to do here? We want to make our projects Swift6 ready and also have strict concurrency, but defa

@DTS Engineer thank you for these suggestions. I've added the full crash report from Crashlytics to this post. After enabling the launch argument you suggested, I managed to reproduce the crash in the debugger once, so that's some progress. After enabling Swift 6 and complete concurrency checking, I got some build errors in the class owning the ModelActor. Wherever I accessed the ModelActor, I got this error: Sending 'self.localStorage.some' risks causing data races. As mentioned in my original post, the ModelActor conforms to a protocol because I am using another type of storage in iOS 16 which doesn't support SwiftData. This protocol didn't require that conforming types were Actors, leading me to suspect that the class owning the ModelActor didn't treat it as an actor, because it only know about the protocol. Adding the Actor requirement to the protocol, removed the build errors in the owning class. Now, I have to ship this change to confirm that it actually fixes it, since I cannot reliably reprod

I was able to capture these machine exceptions (I've only tried with 2 signals, not all) in C++ using Signal handler mechanism. Is that okay? The point of it being super hard is that it usually isn't done properly. If any of these exceptions actually happen in the real work, this kind of carefully crafted exception handling logic will usually fail. Years ago, the approach you describe was popular. I remember large government projects where teams worked for weeks and all they accomplished was a huge mess of complex exception handling code. They held a code review for it but they hadn't actually implemented any of the actual logic for the mission. It was literally just exception handling. Don't do that. At least they were being paid for it. Are you? Regarding Swift and Objective-C exceptions, there are some subtle, but very important differences. Objective-C has both exception handling mechanisms and error handling mechanisms. They are not the same. Exceptions are supposed to crash the app. Errors shou

[quote='804849022, dhunts, /thread/764176?answerId=804849022#804849022, /profile/dhunts'] I'm pretty sure that objective-c must be in play here [/quote] To some extant, yes. As part of Swift 6 work, methods in the SDK have received annotations designating what's sendable or bound to the main actor. So, for WebKit, the method in question here was declared like this in the iOS 17.5 SDK (in WKNavigationDelegate.h): - (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler WK_SWIFT_ASYNC(3); and like this in the iOS 18 SDK: - (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(WK_SWIFT_UI_ACTOR void (^)(WKNavigationActionPolicy))decisionHandler WK_SWIFT_ASYNC(3); That extra WK_SWIFT_UI_ACTOR macro on the declaration produces the @MainActor annotation when expressed through the Swift interface: optional func we