I have a Settings class that conform to the TestProtocol. From the function of the protocol I need to call the setString function and this function needs to be on the MainActor. Is there a way of make this work in Swift6, without making the protocol functions running on @MainActor The calls are as follows: class Settings: TestProtocol{ var value:String = "" @MainActor func setString( _ string:String ){ value = string } func passString(string: String) { Task{ await setString(string) } } } protocol TestProtocol{ func passString( string:String ) }

Crashed: com.apple.root.user-initiated-qos.cooperative 0 libswift_Concurrency.dylib 0x67f40 swift_task_create_commonImpl(unsigned long, swift::TaskOptionRecord*, swift::TargetMetadataswift::InProcess const*, void (swift::AsyncContext* swift_async_context) swiftasynccall*, void*, unsigned long) + 528 1 libswift_Concurrency.dylib 0x64d78 swift_asyncLet_begin + 40 2 AAAA 0x47aef28 (1) suspend resume partial function for ActivityContextModule.fetchRecord(startDate:endDate:) + 50786796 3 libswift_Concurrency.dylib 0x60f5c swift::runJobInEstablishedExecutorContext(swift::Job*) + 252 4 libswift_Concurrency.dylib 0x62514 swift_job_runImpl(swift::Job*, swift::SerialExecutorRef) + 144 5 libdispatch.dylib 0x15ec0 _dispatch_root_queue_drain + 392 6 libdispatch.dylib 0x166c4 _dispatch_worker_thread2 + 156 7 libsystem_pthread.dylib 0x3644 _pthread_wqthread + 228 8 libsystem_pthread.dylib 0x1474 start_wqthread + 8

I am aware the USB / HID devices can come and go, if you have a long running application that's what you want to monitor. But for a "one-shot" command-line tool for example, I would like to enumerate the devices present on a system at a certain point in time, interact with a subset of them (and this interaction can fail since the device may have been disconnected in-between enumerating and me creating the HIDDeviceClient), and then exit the application. It seems that HIDDeviceManager only allows monitoring an Async[Throwing]Stream which provides the initial devices matching the query but then continues to deliver updates, and I have no idea when this initial list is done. I could sleep for a while and then cancel the stream and see what was received up to then, but that seems like the wrong way to go about this, if I just want to know "which devices are connected", so I can maybe list them in a "usage" or help screen. Am I missing something?

I'm trying to switch to UIKit's document lifecycle due to serious bugs with SwiftUI's version. However I'm noticing the template project from Xcode isn't compatible with Swift 6 (I already migrated my app to Swift 6.). To reproduce: File -> New -> Project Select "Document App" under iOS Set "Interface: UIKit" In Build Settings, change Swift Language Version to Swift 6 Run app Tap "Create Document" Observe: crash in _dispatch_assert_queue_fail Does anyone know of a work around other than downgrading to Swift 5?

Here’s the situation: • You’re downloading a huge list of data from iCloud. • You’re saving it one by one (sequentially) into SwiftData. • You don’t want the SwiftUI view to refresh until all the data is imported. • After all the import is finished, SwiftUI should show the new data. The Problem If you insert into the same ModelContext that SwiftUI’s @Environment(.modelContext) is watching, each insert may cause SwiftUI to start reloading immediately. That will make the UI feel slow, and glitchy, because SwiftUI will keep trying to re-render while you’re still importing. How to achieve this in Swift Data ?

We're in the process of migrating our app to the Swift 6 language mode. I have hit a road block that I cannot wrap my head around, and it concerns Core Data and how we work with NSManagedObject instances. Greatly simplied, our Core Data stack looks like this: class CoreDataStack { private let persistentContainer: NSPersistentContainer var viewContext: NSManagedObjectContext { persistentContainer.viewContext } } For accessing the database, we provide Controller classes such as e.g. class PersonController { private let coreDataStack: CoreDataStack func fetchPerson(byName name: String) async throws -> Person? { try await coreDataStack.viewContext.perform { let fetchRequest = NSFetchRequest<Person>() fetchRequest.predicate = NSPredicate(format: "name == %@", name) return try fetchRequest.execute().first } } } Our view controllers use such controllers to fetch objects and populate their UI with it: class MyViewController: UIViewController { private let chatController: PersonController private let ageLabel: UILabel func populateAgeLabel(name: String) { Task { let person = try? await chatController.fetchPerson(byName: name) ageLabel.text = "\(person?.age ?? 0)" } } } This works very well, and there are no concurrency problems since the managed objects are fetched from the view context and accessed only in the main thread. When turning on Swift 6 language mode, however, the compiler complains about the line calling the controller method: Non-sendable result type 'Person?' cannot be sent from nonisolated context in call to instance method 'fetchPerson(byName:)' Ok, fair enough, NSManagedObject is not Sendable. No biggie, just add @MainActor to the controller method, so it can be called from view controllers which are also main actor. However, now the compiler shows the same error at the controller method calling viewContext.perform: Non-sendable result type 'Person?' cannot be sent from nonisolated context in call to instance method 'perform(schedule:_:)' And now I'm stumped. Does this mean NSManageObject instances cannot even be returned from calls to NSManagedObjectContext.perform? Ever? Even though in this case, @MainActor matches the context's actor isolation (since it's the view context)? Of course, in this simple example the controller method could just return the age directly, and more complex scenarios could return Sendable data structures that are instantiated inside the perform closure. But is that really the only legal solution? That would mean a huge refactoring challenge for our app, since we use NSManageObject instances fetched from the view context everywhere. That's what the view context is for, right? tl;dr: is it possible to return NSManagedObject instances fetched from the view context with Swift 6 strict concurrency enabled, and if so how?

I'm working on implementing file moving with NSFileCoordinator. I'm using the slightly newer asynchronous API with the NSFileAccessIntents. My question is, how do I go about notifying the coordinator about the item move? Should I simply create a new instance in the asynchronous block? Or does it need to be the same coordinator instance? let writeQueue = OperationQueue() public func saveAndMove(data: String, to newURL: URL) { let oldURL = presentedItemURL! let sourceIntent = NSFileAccessIntent.writingIntent(with: oldURL, options: .forMoving) let destinationIntent = NSFileAccessIntent.writingIntent(with: newURL, options: .forReplacing) let coordinator = NSFileCoordinator() coordinator.coordinate(with: [sourceIntent, destinationIntent], queue: writeQueue) { error in if let error { return } do { // ERROR: Can't access NSFileCoordinator because it is not Sendable (Swift 6) coordinator.item(at: oldURL, willMoveTo: newURL) try FileManager.default.moveItem(at: oldURL, to: newURL) coordinator.item(at: oldURL, didMoveTo: newURL) } catch { print("Failed to move to \(newURL)") } } }

Hi, DataScannerViewController does't recognize currencies less than 1.00 (e.g. 0.59 USD, 0.99 EUR, etc.). Why? How to solve the problem? This feature is not described in Apple documentation, is there a solution? This is my code: func makeUIViewController(context: Context) -&gt; DataScannerViewController { let dataScanner = DataScannerViewController(recognizedDataTypes: [ .text(textContentType: .currency)]) return dataScanner }

How can I return the results of a Spotlight query synchronously from a Swift function? I want to return a [String] that contains the items that match the query, one item per array element. I specifically want to find all data for Spotlight items in the /Applications folder that have a kMDItemAppStoreAdamID (if there is a better predicate than kMDItemAppStoreAdamID > 0, please let me know). The following should be the correct query: let query = NSMetadataQuery() query.predicate = NSPredicate(format: "kMDItemAppStoreAdamID > 0") query.searchScopes = ["/Applications"] I would like to do this for code that can run on macOS 10.13+, which precludes using Swift Concurrency. My project already uses the latest PromiseKit, so I assume that the solution should use that. A bonus solution using Swift Concurrency wouldn't hurt as I will probably switch over sometime in the future, but won't be able to switch soon. I have written code that can retrieve the Spotlight data as the [String], but I don't know how to return it synchronously from a function; whatever I tried, the query hangs, presumably because I've called various run loop functions at the wrong places. In case it matters, the app is a macOS command-line app using Swift 5.7 & Swift Argument Parser 1.5.0. The Spotlight data will be output only as text to stdout & stderr, not to any Apple UI elements.

Hello, I am developing an application which is communicating with external device using BLE and L2CAP. I wonder what are the best practices of using Input & Output streams that are established with L2CAP connection when working with Swift 6 concurrency model. I've been trying to find some examples and hints for some time now but unfortunately there isn't much available. One useful thread I've found is: https://developer.apple.com/forums/thread/756281 but it does not offer much insight into using eg. actor model with streams. I wonder if something has changed in this regards? Also, are there any plans to migrate eg. CoreBluetooth stack to new swift 6 concurrency ?

Hi Apple Developer Community, I'm facing a crash when updating an array of tuples from both a background thread and the main thread simultaneously. Here's a simplified version of the code in a macOS app using AppKit: class ViewController: NSViewController { var mainthreadButton = NSButton(title: "test", target: self, action: nil) var numbers = Array(repeating: (dim: Int, key: String)(0, "default"), count: 1000) override func viewDidLoad() { super.viewDidLoad() view.addSubview(mainthreadButton) mainthreadButton.translatesAutoresizingMaskIntoConstraints = false mainthreadButton.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true mainthreadButton.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true mainthreadButton.widthAnchor.constraint(equalToConstant: 100).isActive = true mainthreadButton.heightAnchor.constraint(equalToConstant: 100).isActive = true mainthreadButton.target = self mainthreadButton.action = #selector(arraytest(_:)) } @objc func arraytest(_ sender: NSButton) { print("array update started") // Background update DispatchQueue.global().async { for i in 0..&lt;1000 { self.numbers[i].dim = i } } // Main thread update var sum = 0 for i in 0..&lt;1000 { numbers[i].dim = i + 1 sum += numbers[i].dim print("test \(sum)") } mainthreadButton.title = "test = \(sum)" } } This results in a crash with the following message: malloc: double free for ptr 0x136040c00 malloc: *** set a breakpoint in malloc_error_break to debug What's interesting: This crash only happens when the tuple contains a String ((dim: Int, key: String)) If I change the tuple type to use two Int values ((dim: Int, key: Int)), the crash does not occur My Questions: Why does mutating an array of tuples containing a String crash when accessed from multiple threads? Why is the crash avoided when the tuple contains only primitive types like Int? Is there an underlying memory management issue with value types containing reference types like String? Any explanation about this behavior and best practices for thread-safe mutation of such arrays would be much appreciated. Thanks in advance!

I get many warnings like this when I build an old project. I asked AI chatbot which gave me several solutions, the recommended one is: var hashBag = [String: Int]() func updateHashBag() async { var tempHashBag = hashBag // make copy await withTaskGroup(of: Void.self) { group in group.addTask { tempHashBag["key1"] = 1 } group.addTask { tempHashBag["key2"] = 2 } } hashBag = tempHashBag // copy back? } My understanding is that in the task group, the concurrency engine ensures synchronized modifications on the temp copy in multiple tasks. I should not worry about this. My question is about performance. What if I want to put a lot of data into the bag? Does the compiler do some kind of magics to optimize low level memory allocations? For example, the temp copy actually is not a real copy, it is a special reference to the original hash bag; it is only grammar glue that I am modifying the copy.

Hi all, I'm running into a Swift Concurrency issue and would appreciate some help understanding what's going on. I have a protocol and an actor set up like this: protocol PersistenceListener: AnyObject { func persistenceDidUpdate(key: String, newValue: Any?) } actor Persistence { func addListener(_ listener: PersistenceListener) { listeners.add(listener) } /// Removes a listener. func removeListener(_ listener: PersistenceListener) { listeners.remove(listener) } // MARK: - Private Properties private var listeners = NSHashTable<AnyObject>.weakObjects() // MARK: - Private Methods /// Notifies all registered listeners on the main actor. private func notifyListeners(key: String, value: Any?) async { let currentListeners = listeners.allObjects.compactMap { $0 as? PersistenceListener } for listener in currentListeners { await MainActor.run { listener.persistenceDidUpdate(key: key, newValue: value) } } } } When I compile this code, I get a concurrency error: "Sending 'listener' risks causing data races"

Swift concurrency is an important part of my day-to-day job. I created the following document for an internal presentation, and I figured that it might be helpful for others. If you have questions or comments, put them in a new thread here on DevForums. Use the App & System Services > Processes & Concurrency topic area and tag it with both Swift and Concurrency. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Swift Concurrency Proposal Index This post summarises the Swift Evolution proposals that went into the Swift concurrency design. It covers the proposal that are implemented in Swift 6.2, plus a few additional ones that aren’t currently available. The focus is here is the Swift Evolution proposals. For general information about Swift concurrency, see the documentation referenced by Concurrency Resources. Early Days Some early high-level discussions of concurrency on Swift Evolution: Swift Concurrency Manifesto (Aug 2017) — Introduces async and await and actors, including the main actor. If you’re curious, you can read the Swift Evolution thread that introduced this. Swift Concurrency Roadmap (Oct 2020) — This extended the design to include Task, structured concurrency, and Objective-C interoperability. Each subsystem had its own pitch thread [Concurrency] Asynchronous functions [Concurrency] Structured concurrency [Concurrency] Actors & actor isolation [Concurrency] Interoperability with Objective-C Swift 6.0 The following Swift Evolution proposals form the basis of the Swift 6.0 concurrency design. SE-0176 Enforce Exclusive Access to Memory link: SE-0176 notes: This defines the “Law of Exclusivity”, a critical foundation for both serial and concurrent code. SE-0282 Clarify the Swift memory consistency model ⚛︎ link: SE-0282 notes: This defines Swift’s memory model, that is, the rules about what is and isn’t allowed when it comes to concurrent memory access. SE-0296 Async/await link: SE-0296 introduces: async functions, async, await SE-0297 Concurrency Interoperability with Objective-C link: SE-0297 notes: Specifies how Swift imports an Objective-C method with a completion handler as an async method. Explicitly allows @objc actors. SE-0298 Async/Await: Sequences link: SE-0298 introduces: AsyncSequence, for await syntax notes: This just defines the AsyncSequence protocol. For one concrete implementation of that protocol, see SE-0314. SE-0300 Continuations for interfacing async tasks with synchronous code link: SE-0300 introduces: CheckedContinuation, UnsafeContinuation notes: Use these to create an async function that wraps a legacy request-reply concurrency construct. SE-0302 Sendable and @Sendable closures link: SE-0302 introduces: Sendable, @Sendable closures, marker protocols SE-0304 Structured concurrency link: SE-0304, third-party commentary introduces: unstructured and structured concurrency, Task, cancellation, CancellationError, withTaskCancellationHandler(…), sleep(…), withTaskGroup(…), withThrowingTaskGroup(…) notes: For the async let syntax, see SE-0317. For more ways to sleep, see SE-0329 and SE-0374. For discarding task groups, see SE-0381. SE-0306 Actors link: SE-0306 introduces: actor syntax notes: For actor-isolated parameters and the nonisolated keyword, see SE-0313. For global actors, see SE-0316. For custom executors and the Actor protocol, see SE-0392. SE-0311 Task Local Values link: SE-0311 introduces: TaskLocal SE-0313 Improved control over actor isolation link: SE-0313 introduces: isolated parameters, nonisolated SE-0314 AsyncStream and AsyncThrowingStream link: SE-0314 introduces: AsyncStream, AsyncThrowingStream, onTermination notes: These are super helpful when you need to publish a legacy notification construct as an async stream. For a simpler API to create a stream, see SE-0388. SE-0316 Global actors link: SE-0316 introduces: GlobalActor, MainActor notes: This includes the @MainActor syntax for closures. SE-0317 async let bindings link: SE-0317 introduces: async let syntax SE-0323 Asynchronous Main Semantics link: SE-0323 SE-0327 On Actors and Initialization link: SE-0327 notes: For a proposal to allow access to non-sendable isolated state in a deinitialiser, see SE-0371. SE-0329 Clock, Instant, and Duration link: SE-0329 introduces: Clock, InstantProtocol, DurationProtocol, Duration, ContinuousClock, SuspendingClock notes: For another way to sleep, see SE-0374. SE-0331 Remove Sendable conformance from unsafe pointer types link: SE-0331 SE-0337 Incremental migration to concurrency checking link: SE-0337 introduces: @preconcurrency, explicit unavailability of Sendable notes: This introduces @preconcurrency on declarations, on imports, and on Sendable protocols. For @preconcurrency conformances, see SE-0423. SE-0338 Clarify the Execution of Non-Actor-Isolated Async Functions link: SE-0338 note: This change has caught a bunch of folks by surprise and there’s a discussion underway as to whether to adjust it. SE-0340 Unavailable From Async Attribute link: SE-0340 introduces: noasync availability kind SE-0343 Concurrency in Top-level Code link: SE-0343 notes: For how strict concurrency applies to global variables, see SE-0412. SE-0374 Add sleep(for:) to Clock link: SE-0374 notes: This builds on SE-0329. SE-0381 DiscardingTaskGroups link: SE-0381 introduces: DiscardingTaskGroup, ThrowingDiscardingTaskGroup notes: Use this for task groups that can run indefinitely, for example, a network server. SE-0388 Convenience Async[Throwing]Stream.makeStream methods link: SE-0388 notes: This builds on SE-0314. SE-0392 Custom Actor Executors link: SE-0392 introduces: Actor protocol, Executor, SerialExecutor, ExecutorJob, assumeIsolated(…) notes: For task executors, a closely related concept, see SE-0417. For custom isolation checking, see SE-0424. SE-0395 Observation link: SE-0395 introduces: Observation module, Observable notes: While this isn’t directly related to concurrency, it’s relationship to Combine, which is an important exising concurrency construct, means I’ve included it in this list. SE-0401 Remove Actor Isolation Inference caused by Property Wrappers link: SE-0401, third-party commentary availability: upcoming feature flag: DisableOutwardActorInference SE-0410 Low-Level Atomic Operations ⚛︎ link: SE-0410 introduces: Synchronization module, Atomic, AtomicLazyReference, WordPair SE-0411 Isolated default value expressions link: SE-0411, third-party commentary SE-0412 Strict concurrency for global variables link: SE-0412 introduces: nonisolated(unsafe) notes: While this is a proposal about globals, the introduction of nonisolated(unsafe) applies to “any form of storage”. SE-0414 Region based Isolation link: SE-0414, third-party commentary notes: To send parameters and results across isolation regions, see SE-0430. SE-0417 Task Executor Preference link: SE-0417, third-party commentary introduces: withTaskExecutorPreference(…), TaskExecutor, globalConcurrentExecutor notes: This is closely related to the custom actor executors defined in SE-0392. SE-0418 Inferring Sendable for methods and key path literals link: SE-0418, third-party commentary availability: upcoming feature flag: InferSendableFromCaptures notes: The methods part of this is for “partial and unapplied methods”. SE-0420 Inheritance of actor isolation link: SE-0420, third-party commentary introduces: #isolation, optional isolated parameters notes: This is what makes it possible to iterate over an async stream in an isolated async function. SE-0421 Generalize effect polymorphism for AsyncSequence and AsyncIteratorProtocol link: SE-0421, third-party commentary notes: Previously AsyncSequence used an experimental mechanism to support throwing and non-throwing sequences. This moves it off that. Instead, it uses an extra Failure generic parameter and typed throws to achieve the same result. This allows it to finally support a primary associated type. Yay! SE-0423 Dynamic actor isolation enforcement from non-strict-concurrency contexts link: SE-0423, third-party commentary introduces: @preconcurrency conformance notes: This adds a number of dynamic actor isolation checks (think assumeIsolated(…)) to close strict concurrency holes that arise when you interact with legacy code. SE-0424 Custom isolation checking for SerialExecutor link: SE-0424, third-party commentary introduces: checkIsolation() notes: This extends the custom actor executors introduced in SE-0392 to support isolation checking. SE-0430 sending parameter and result values link: SE-0430, third-party commentary introduces: sending notes: Adds the ability to send parameters and results between the isolation regions introduced by SE-0414. SE-0431 @isolated(any) Function Types link: SE-0431, third-party commentary, third-party commentary introduces: @isolated(any) attribute on function types, isolation property of functions values notes: This is laying the groundwork for SE-NNNN Closure isolation control. That, in turn, aims to bring the currently experimental @_inheritActorContext attribute into the language officially. SE-0433 Synchronous Mutual Exclusion Lock 🔒 link: SE-0433 introduces: Mutex SE-0434 Usability of global-actor-isolated types link: SE-0434, third-party commentary availability: upcoming feature flag: GlobalActorIsolatedTypesUsability notes: This loosen strict concurrency checking in a number of subtle ways. Swift 6.1 Swift 6.1 has the following additions. Vision: Improving the approachability of data-race safety link: vision SE-0442 Allow TaskGroup’s ChildTaskResult Type To Be Inferred link: SE-0442, third-party commentary notes: This represents a small quality of life improvement for withTaskGroup(…) and withThrowingTaskGroup(…). SE-0449 Allow nonisolated to prevent global actor inference link: SE-0449, third-party commentary notes: This is a straightforward extension to the number of places you can apply nonisolated. Swift 6.2 Xcode 26 beta has two new build settings: Approachable Concurrency enables the following feature flags: DisableOutwardActorInference, GlobalActorIsolatedTypesUsability, InferIsolatedConformances, InferSendableFromCaptures, and NonisolatedNonsendingByDefault. Default Actor Isolation controls SE-0466 Swift 6.2, still in beta, has the following additions. SE-0371 Isolated synchronous deinit link: SE-0371, third-party commentary introduces: isolated deinit notes: Allows a deinitialiser to access non-sendable isolated state, lifting a restriction imposed by SE-0327. SE-0457 Expose attosecond representation of Duration link: SE-0457 introduces: attoseconds, init(attoseconds:) SE-0461 Run nonisolated async functions on the caller’s actor by default link: SE-0461 availability: upcoming feature flag: NonisolatedNonsendingByDefault introduces: nonisolated(nonsending), @concurrent notes: This represents a significant change to how Swift handles actor isolation by default, and introduces syntax to override that default. SE-0462 Task Priority Escalation APIs link: SE-0462 introduces: withTaskPriorityEscalationHandler(…) notes: Code that uses structured concurrency benefits from priority boosts automatically. This proposal exposes APIs so that code using unstructured concurrency can do the same. SE-0463 Import Objective-C completion handler parameters as @Sendable link: SE-0463 notes: This is a welcome resolution to a source of much confusion. SE-0466 Control default actor isolation inference link: SE-0466, third-party commentary availability: not officially approved, but a de facto part of Swift 6.2 introduces: -default-isolation compiler flag notes: This is a major component of the above-mentioned vision document. SE-0468 Hashable conformance for Async(Throwing)Stream.Continuation link: SE-0468 notes: This is an obvious benefit when you’re juggling a bunch of different async streams. SE-0469 Task Naming link: SE-0469 introduces: name, init(name:…) SE-0470 Global-actor isolated conformances link: SE-0470 availability: upcoming feature flag: InferIsolatedConformances introduces: @SomeActor protocol conformance notes: This is particularly useful when you want to conform an @MainActor type to Equatable, Hashable, and so on. SE-0471 Improved Custom SerialExecutor isolation checking for Concurrency Runtime link: SE-0471 notes: This is a welcome extension to SE-0424. SE-0472 Starting tasks synchronously from caller context link: SE-0472 introduces: immediate[Detached](…), addImmediateTask[UnlessCancelled](…), notes: This introduces the concept of an immediate task, one that initially uses the calling execution context. This is one of those things where, when you need it, you really need it. But it’s hard to summary when you might need it, so you’ll just have to read the proposal (-: In Progress The proposals in this section didn’t make Swift 6.2. SE-0406 Backpressure support for AsyncStream link: SE-0406 availability: returned for revision notes: Currently AsyncStream has very limited buffering options. This was a proposal to improve that. This feature is still very much needed, but the outlook for this proposal is hazy. My best guess is that something like this will land first in the Swift Async Algorithms package. See this thread. SE-NNNN Closure isolation control link: SE-NNNN introduces: @inheritsIsolation availability: not yet approved notes: This aims to bring the currently experimental @_inheritActorContext attribute into the language officially. It’s not clear how this will play out given the changes in SE-0461. Revision History 2026-02-16 Added the Early Days section. 2026-01-07 Added another third-party commentary links. 2025-09-02 Updated for the upcoming release Swift 6.2. 2025-04-07 Updated for the release of Swift 6.1, including a number of things that are still in progress. 2024-11-09 First post.

I am building a MacOS desktop app (https://anukari.com) that is using Metal compute to do real-time audio/DSP processing, as I have a problem that is highly parallelizable and too computationally expensive for the CPU. However it seems that the way in which I am using the GPU, even when my app is fully compute-limited, the OS never increases the power/performance state. Because this is a real-time audio synthesis application, it's a huge problem to not be able to take advantage of the full clock speeds that the GPU is capable of, because the app can't keep up with real-time. I discovered this issue while profiling the app using Instrument's Metal tracing (and Game tracing) modes. In the profiling configuration under "Metal Application" there is a drop-down to select the "Performance State." If I run the application under Instruments with Performance State set to Maximum, it runs amazingly well, and all my problems go away. For comparison, when I run the app on its own, outside of Instruments, the expensive GPU computation it's doing takes around 2x as long to complete, meaning that the app performs half as well. I've done a ton of work to micro-optimize my Metal compute code, based on every scrap of information from the WWDC videos, etc. A problem I'm running into is that I think that the more efficient I make my code, the less it signals to the OS that I want high GPU clock speeds! I think part of why the OS is confused is that in most use cases, my computation can be done using only a small number of Metal threadgroups. I'm guessing that the OS heuristics see that only a small fraction of the GPU is saturated and fail to scale up the power/clock state. I'm not sure what to do here; I'm in a bit of a bind. One possibility is that I intentionally schedule busy work -- spin threadgroups just to waste energy and signal to the OS that I need higher clock speeds. This is obviously a really bad idea, but it might work. Is there any other (better) way for my app to signal to the OS that it is doing real-time latency-sensitive computation on the GPU and needs the clock speeds to be scaled up? Note that game mode is not really an option, as my app also runs as an AU plugin inside hosts like Garageband, so it can't be made fullscreen, etc.

This is not a question but more of a hint where I was having trouble with. In my SwiftData App I wanted to move from Swift 5 to Swift 6, for that, as recommended, I stayed in Swift 5 language mode and set 'Strict Concurrency Checking' to 'Complete' within my build settings. It marked all the places where I was using predicates with the following warning: Type '' does not conform to the 'Sendable' protocol; this is an error in the Swift 6 language mode I had the same warnings for SortDescriptors. I spend quite some time searching the web and wrapping my head around how to solve that issue to be able to move to Swift 6. In the end I found this existing issue in the repository of the Swift Language https://github.com/swiftlang/swift/issues/68943. It says that this is not a warning that should be seen by the developer and in fact when turning Swift 6 language mode on those issues are not marked as errors. So if anyone is encountering this when trying to fix all issues while staying in Swift 5 language mode, ignore those, fix the other issues and turn on Swift 6 language mode and hopefully they are gone.

We are getting a crash _dispatch_assert_queue_fail when the cancellationHandler on NSProgress is called. We do not see this with iOS 17.x, only on iOS 18. We are building in Swift 6 language mode and do not have any compiler warnings. We have a type whose init looks something like this: init( request: URLRequest, destinationURL: URL, session: URLSession ) { progress = Progress() progress.kind = .file progress.fileOperationKind = .downloading progress.fileURL = destinationURL progress.pausingHandler = { [weak self] in self?.setIsPaused(true) } progress.resumingHandler = { [weak self] in self?.setIsPaused(false) } progress.cancellationHandler = { [weak self] in self?.cancel() } When the progress is cancelled, and the cancellation handler is invoked. We get the crash. The crash is not reproducible 100% of the time, but it happens significantly often. Especially after cleaning and rebuilding and running our tests. * thread #4, queue = 'com.apple.root.default-qos', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18017b0e8) * frame #0: 0x000000018017b0e8 libdispatch.dylib`_dispatch_assert_queue_fail + 116 frame #1: 0x000000018017b074 libdispatch.dylib`dispatch_assert_queue + 188 frame #2: 0x00000002444c63e0 libswift_Concurrency.dylib`swift_task_isCurrentExecutorImpl(swift::SerialExecutorRef) + 284 frame #3: 0x000000010b80bd84 MyTests`closure #3 in MyController.init() at MyController.swift:0 frame #4: 0x000000010b80bb04 MyTests`thunk for @escaping @callee_guaranteed @Sendable () -&gt; () at &lt;compiler-generated&gt;:0 frame #5: 0x00000001810276b0 Foundation`__20-[NSProgress cancel]_block_invoke_3 + 28 frame #6: 0x00000001801774ec libdispatch.dylib`_dispatch_call_block_and_release + 24 frame #7: 0x0000000180178de0 libdispatch.dylib`_dispatch_client_callout + 16 frame #8: 0x000000018018b7dc libdispatch.dylib`_dispatch_root_queue_drain + 1072 frame #9: 0x000000018018bf60 libdispatch.dylib`_dispatch_worker_thread2 + 232 frame #10: 0x00000001012a77d8 libsystem_pthread.dylib`_pthread_wqthread + 224 Any thoughts on why this is crashing and what we can do to work-around it? I have not been able to extract our code into a simple reproducible case yet. And I mostly see it when running our code in a testing environment (XCTest). Although I have been able to reproduce it running an app a few times, it's just less common.

Hey all! in my personal quest to make future proof apps moving to Swift 6, one of my app has a problem when setting an artwork image in MPNowPlayingInfoCenter Here's what I'm using to set the metadata func setMetadata(title: String? = nil, artist: String? = nil, artwork: String? = nil) async throws { let defaultArtwork = UIImage(named: "logo")! var nowPlayingInfo = [ MPMediaItemPropertyTitle: title ?? "***", MPMediaItemPropertyArtist: artist ?? "***", MPMediaItemPropertyArtwork: MPMediaItemArtwork(boundsSize: defaultArtwork.size) { _ in defaultArtwork } ] as [String: Any] if let artwork = artwork { guard let url = URL(string: artwork) else { return } let (data, response) = try await URLSession.shared.data(from: url) guard (response as? HTTPURLResponse)?.statusCode == 200 else { return } guard let image = UIImage(data: data) else { return } nowPlayingInfo[MPMediaItemPropertyArtwork] = MPMediaItemArtwork(boundsSize: image.size) { _ in image } } MPNowPlayingInfoCenter.default().nowPlayingInfo = nowPlayingInfo } the app crashes when hitting MPMediaItemPropertyArtwork: MPMediaItemArtwork(boundsSize: defaultArtwork.size) { _ in defaultArtwork } or nowPlayingInfo[MPMediaItemPropertyArtwork] = MPMediaItemArtwork(boundsSize: image.size) { _ in image } commenting out these two make the app work again. Again, no clue on why. Thanks in advance

AVAudioFormat has no Swift concurrency annotations but the documentation states "Instances of this class are immutable." This made me always assume it was safe to pass AVAudioFormat instances around. Is this the case? If so can it be marked as Sendable? Am I missing something?

Hey, I am just about to prepare my app for Swift 6, and facing the issue that UserDefaults is not Sendable. The documentation states that its thread safe, so I am wondering, why is it not marked as Sendable? Was it just forgotten? Is it safe to mark it as nonisolated(unsafe) or @unchecked Sendable?