Swift 6

It’s better if you reply, rather than in the comments. See Quinn’s Top Ten DevForums Tips for this and other titbits. I didn't gte you ? Sorry about that. Honestly, I’m not sure what your concern is here. You original post mentions OpaqueTypeErasure but that’s not a symbol in any of Apple’s SDKs. And searching the ’net for OpaqueTypeErasure only turns up one hit, this thread. If you can explain your concern in more detail, I’d be happy to help out further. [quote='767838021, fouadmagdy, /thread/767838, /profile/fouadmagdy'] But upgrading the app swift version will be a very long process [/quote] That shouldn’t be the case if you stick with the Swift 5 language mode. In general, the Swift 6 compiler in Xcode 16 is very compatible with the Swift 5 compiler in older versions of Xcode as long as you don’t enable the Swift 6 language mode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I forgot to mention that I'm doing this from a background thread: DispatchQueue.global().async { DispatchQueue.main.async { [self] in asd() // no warning or error } DispatchQueue.main.sync { [self] in asd() // warning: Call to method 'asd' in closure requires explicit use of 'self' to make capture semantics explicit; this is an error in Swift 6 } }

I can't speak to urgency, because that could be interpreted as a future looking timeframe. As a process, I would enable the Swift 5 stricter concurrency checking in code that you control to gauge what the important issues in your code base are, and decide what it would mean to fix them in terms of complexity. After that, try out the Swift 6 language mode, and see what other issues the complier identifies, once again with an eye for complexity. You can then take that information about the technical complexity and use that as information in your overall scheduling and mangement of your software project, and when the best time to do the work is. Since you can do that on a module-by-module basis, there's no need to jump to Swift 6 all at once. You can turn it on just for one module where perhaps there are no issues, or they are easy to address, after updating the language mode, and expand outward from there. And looking at this from the other direction, if there's a module where the iss

Hi, I just tested with iOS 18.0.1 with the same issue. As soon as the peripheral device enters into background, the central device does not receive callbacks to CBCentralManagerDelegate.centralManager(_:didDiscover:advertisementData:rssi:) when scanning with scanForPeripherals(withServices:options:) This worked before changing to iOS 18 and SWIFT 6. Does anyone have some news about this topic or some feedback from Apple? Thank you!

I'm also experiencing this on Xcode 16.3 running on macOS 15.4 (24E248) (it's a SwiftUI multiplatform app and IIRC the same thing is happening on iOS but can't test it right now.) I've just been refactoring for Swift 6 so my code's a bit of a mess, but I'll file a bug once I can make a nice example.

So even Swift 6, Xcode 16 did not help. it seems to be a bug within the original code. The function is not working as expected. I would like to ask to solve the bug by the function: renderEncoder?.drawPrimitives(type: .line, vertexStart: 0, vertexCount: 3) and renderEncoder?.drawPrimitives(type: .lineStrip, vertexStart: 0, vertexCount: 3)

I have the same issue, it has completely broken my project. I have upgraded to Swift 6, but that didnt help. I have tried manually creating a container, but the container is not unique to the document. I have a large data model with many relationships, it stores simple data and image data. It has been working great for a year, and then completely crashes on IOS18! I am at a loss, please help!

Wow, this was as simple as adding a @Sendable keyword! I posted about this last month here: https://forums.developer.apple.com/forums/thread/763790 I also submitted a bug report #FB15145734 as I assumed the block was being run on the incorrect thread which was out of our control. Happy to have this working now, but I do wonder is this still an issue with the function, or simply a Swift 6 compiler issue?

The general technique would be to create your own actor backed with serial executor backed with a dispatch queue that you create, can access, and can then pass to AVCapture APIs that expect queue… then all code will be executed on that queue and can coexist with the code on actor. so yes, you can do it, but I am exactly not sure whether it will build cleanly and work without issues on 5.10, should be possible easily from swift 6.

[quote='790881022, Bikrrr, /thread/757007?answerId=790881022#790881022, /profile/Bikrrr'] But I'm new at this [/quote] We’re all new at this (-: [quote='790881022, Bikrrr, /thread/757007?answerId=790881022#790881022, /profile/Bikrrr'] I'm not sure if that's OK or if I should be importing UIKit instead? [/quote] I don’t think it matters, because in this case your only goal is to suppress the warning. The underlying code is safe. Which isn’t universally true. Every time you hit a warning like this you have to evaluate whether it’s your issue, an SDK issue, or a compiler issue (the latter being quite rare). That can be quite tricky. I have a couple of great resources to help you: Migrating to Swift 6 WWDC 2024 Session 10169 Migrate your app to Swift 6 Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

And another similar warning with overriden functions (nos NS-based this time: import Foundation import UIKit class TestListCell: UICollectionViewCell { private func doSomething() { } override func awakeFromNib() { // [WARNING] Call to main actor-isolated instance method 'doSomething()' in a synchronous nonisolated context; this is an error in the Swift 6 language mode doSomething() } }```

I tried reproducing this but couldn’t. Having seen the error myself, I could reproduce it as follows: Paste the three structs from the op's original post into a Swift file in a new app project. Change Decodable for each to Codable (I couldn't reproduce it for Decodable only for some reason). Make sure that strict concurrency checking is set to Complete and MainActor is set as the default actor isolation for the project. When I do this, I see a Circular reference error with several Through reference here comments that don't make much sense. There seem to be two possible fixes depending on how the struct is intended to be used: Explicitly set the struct as nonisolated (which prior to the change in default actor isolation would have been the default): nonisolated struct FriendListResponse: Codable Force the conformance to @MainActor: struct FriendListResponse: @MainActor Codable (Note that the second solution will break if you use custom codingKeys, however, even if you try to force the conformance on t

Migrating a large codebase to Swift 6 is not a trivial task. You can expect to encounter a significant number of issues. However, it’s possible to make rapid progress because, in general, these issues falls into big groups. Once you work on the solution for one of the issues in a group you can apply the same solution to all other issues in that group. There are a couple of standard resources that I generally point folks at here: WWDC 2024 Session 10169 Migrate your app to Swift 6 Migrating to Swift 6 Additionally, the Swift team is actively exploring ways to make this process easier. For a general explanation of the plan, see the Improving the approachability of data-race safety vision doc. There are are a bunch of in-flight Swift Evolution proposals that work towards that vision. So, you have a choice here: You can choose to tackle this today. Or you can wait for those changes to land in a production Swift compiler. If you want to tackle this today then I

Unfortunately CSUserQuery does not allow these types of query strings. CSUserQueryContext.filterQueries appears to be the only way to scope to contentURL. That's unfortunate. Well, looking at our code again, I think perfomance loss will be smaller than I'd thought, as the filterQueries is actually being passed over and processed on the daemon side. 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. Actually, this reminded me of something I'd overlooked. The correct answer is to create a CSImportExtension. That extension point hands you the file you're indexing, side stepping the entire issue. FYI, this extension point has been broken on previous macOS versions, but does appear to work on macOS 15. Swift 6.2, Swift 6 language mode: the reindex* methods call indexSearchableItems which in their callbacks need to invoke the acknowledgementHandler. However the callback is @Sendable b

Unfortunately in the meantime FB 11722934 was closed by Apple: Investigation completed - functional capability according to current design given (translated from the german status message on the Feedback web page) In the best interpretation this means the problem is known to behave this way until Swift 6 compatible frameworks come out? But this is not really a helpful answer. I even tried to ask about this problem in an Ask Apple: Swift session but it was not covered in the topics answered.