Hey y'all, I'm reaching out because of an observed issue that I am experience both in sandbox and in production environments. This issue does not occur when using the Local StoreKit configurations. For context, my app only implements auto-renewing subscriptions. I'm trying to track with my own analytics every time a successful purchase is made, whether in the app or externally through Subscription Settings. I'm seeming too many events for just one purchase. My app is observing Transaction.updates. When I make a purchase with Product.purchase(_:), I successfully handle the purchase result. After about 10-20 seconds, I receive 2-3 new transactions in my Transaction.updates, even though I already handled and finished the Purchase result. This happens on production, where renewals are one week. This also happens in Sandbox, where at minimum renewals are every 3 minutes. The transactions do not differ in transactionId, revocationDate, expirationDate, nor isUpgraded... so not sure why they're coming in through Transaction.updates if there are no "updates" to be processing. For purchases made outside the app, I get the same issue. Transaction gets handled in updates several times. Note that this is not an issue if a subscription renews. I use `Transaction.reason I want to assume that StoreKit is a perfect API and can do no wrong (I know, a poor assumption but hear me out)... so where am I going wrong? My current thought is a Swift concurrency issue. This is a contrived example: // Assume Task is on MainActor Task(priority: .background) { @MainActor in for await result in Transaction.updates in { // We suspend current process, // so will we go to next item in the `for-await-in` loop? // Because we didn't finish the first transaction, will we see it again in the updates queue? await self.handle(result) } } @MainActor func handle(result) async { ... await Analytics.sendEvent("purchase_success") transaction.finish() }

Context: Xcode 16.4, Appkit In a windowController, I need to create and send a mouseDown event (newMouseDownEvent). I create the event with: let newMouseDownEvent = NSEvent.mouseEvent( with: .leftMouseDown, location: clickPoint, // all other fields I also need to make window key and front, otherwise the event is not handled.   func simulateMouseDown() { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) }   As I have to delay the call( 0.5 s), I use asyncAfter: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: .userInteractive) { self.simulateMouseDown() }   It works as intended, but that generates the following (purple) warning at runtime: [Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions I have tried several solutions, change qos in await: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: ..default) call from a DispatchQueue let interactiveQueue = DispatchQueue.global(qos: .userInteractive) interactiveQueue.async { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) } But that's worse, it crashes with the following error: FAULT: NSInternalInconsistencyException: -[HIRunLoopSemaphore wait:] has been invoked on a secondary thread; the problem is likely in a much shallower frame in the backtrace; { NSAssertFile = "HIRunLoop.mm"; NSAssertLine = 709; }   How to eliminate the priority inversion risk (not just silencing the warning) ?

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?

I tried making a concurrency-safe data queue. It was going well, until memory check tests crashed. It's part of an unadvertised git project. Its location is: https://github.com/CTMacUser/SynchronizedQueue/commit/84a476e8f719506cbd4cc6ef513313e4e489cae3 It's the blocked-off method "`memorySafetyReferenceTypes'" in "SynchronizedQueueTests.swift." Note that the file and its tests were originally AI slop.

Hi everyone, I believe this should be a simple and expected default behavior in a real-world app, but I’m unable to make it work: I have a View (a screen/page in this case) that calls an endpoint using async/await. If the endpoint hasn’t finished, but I navigate forward to a DetailView, I want the endpoint to continue fetching data (i.e., inside the @StateObject ViewModel that the View owns). This way, when I go back, the View will have refreshed with the fetched data once it completes. If the endpoint hasn’t finished and I navigate back to the previous screen, I want it to be canceled, and the @StateObject ViewModel should be deinitialized. I can achieve 1 and 3 using the .task modifier, since it automatically cancels the asynchronous task when the view disappears: view .task { await vm.getData() } I can achieve 1 and 2 using a structured Task in the View (or in the ViewModel, its the same behavior), for example: .onFirstAppearOnly { Task { away vm.getData() } } onFirstAppearOnly is a custom modifier that I have for calling onAppear only once in view lifecycle. Just to clarify, I dont think that part is important for the purpose of the example My question is: How can I achieve all three behaviors? My minimum deployment target is iOS 15, and I’m using NavigationView + NavigationLink. However, I have also tried using NavigationStack + NavigationPath and still couldn’t get it to work. Any help would be much appreciated. Thank you!

Is the pseudocode below thread-safe? Imagine that the Main thread sets the CAMetalLayer's drawableSize to a new size meanwhile the rendering thread is in the middle of rendering into an existing MTLDrawable which does still have the old size. Is the change of metalLayer.drawableSize thread-safe in the sense that I can present an old MTLDrawable which has a different resolution than the current value of metalLayer.drawableSize? I assume that setting the drawableSize property informs Metal that the next MTLDrawable offered by the CAMetalLayer should have the new size, right? Is it valid to assume that "metalLayer.drawableSize = newSize" and "metalLayer.nextDrawable()" are internally synchronized, so it cannot happen that metalLayer.nextDrawable() would produce e.g. a MTLDrawable with the old width but with the new height (or a completely invalid resolution due to potential race conditions)? func onWindowResized(newSize: CGSize) { // Called on the Main thread metalLayer.drawableSize = newSize } func onVsync(drawable: MTLDrawable) { // Called on a background rendering thread renderer.renderInto(drawable: drawable) }

Hello, Regarding EKEventStore, the WWDC session mentions that “you should only have one of these for your application.” In my app, I need to use the instance on both the main thread and a background thread, and I would like to share a single instance across them. However, EKEventStore is a non-sendable type, so it cannot be shared across different isolation domains. I would like to know what the recommended best practice is for this situation. Also, do I need to protect the instance from data races by using a lock? Thank you.

I encountered a concurrency compilation warning when calling the TranslationSession.translations(from: [TranslationSession.Request]) API, and I'm don't know how to resolve it. I reviewed the official demo, but it appears identical.

Hi, I played around the last days with the new NetworkConnection API from Network framework that supports structured concurrency. I discovered a behavior, which is unexpected from my understanding. Let's say you have a dead endpoint or something that does not exist. Something where you receive a noSuchRecord error. When I then try to send data, I would expect that the send function throws an error but this does not happen. The function now suspends indefinitely which is well not a great behavior. Example simplified: func send() async { let connection = NetworkConnection(to: .hostPort(host: "apple.co.com", port: 8080)) { TCP() } do { try await connection.send("Hello World!".raw) } catch { print(error) } } I'm not sure if this is the intended behavior or how this should be handled. Thanks and best regards, Vinz

We're experiencing crashes in our production iOS app related to Apple's DeviceCheck framework. The crash occurs in DCAnalytics internal performance tracking, affecting some specific versions of iOS 18 (18.4.1, 18.5.0). Crash Signature CoreFoundation: -[__NSDictionaryM setObject:forKeyedSubscript:] + 460 DeviceCheck: -[DCAnalytics sendPerformanceForCategory:eventType:] + 236 Observed Patterns Scenario 1 - Token Generation: Crashed: com.appQueue EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010 DeviceCheck: -[DCDevice generateTokenWithCompletionHandler:] Thread: Background dispatch queue Scenario 2 - Support Check: Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008 DeviceCheck: -[DCDevice _isSupportedReturningError:] DeviceCheck: -[DCDevice isSupported] Thread: Main thread Root Cause Analysis The DCAnalytics component within DeviceCheck attempts to insert a nil value into an NSMutableDictionary when recording performance metrics, indicating missing nil validation before dictionary operations. Reproduction Context Crashes occur during standard DeviceCheck API usage: Calling DCDevice.isSupported property Calling DCDevice.generateToken(completionHandler:) (triggered by Firebase App Check SDK) Both operations invoke internal analytics that fail with nil insertion attempts. Concurrency Considerations We've implemented sequential access guards around DeviceCheck token generation to prevent race conditions, yet crashes persist. This suggests the issue likely originates within the DeviceCheck framework's internal implementation rather than concurrent access from our application code. Note: Scenario 2 occurs through Firebase SDK's App Check integration, which internally uses DeviceCheck for attestation. Request Can Apple engineering confirm if this is a known issue with DeviceCheck's analytics subsystem? Is there a recommended workaround to disable DCAnalytics or ensure thread-safe DeviceCheck API usage? Any guidance on preventing these crashes would be appreciated.

I have been working on an app for the past few months, and one issue that I have encountered a few times is an error where quick subsequent deletions cause issues with detached tasks that are triggered from some user actions. Inside a Task.detached, I am building an isolated model context, querying for LineItems, then iterating over those items. The crash happens when accessing a Transaction property through a relationship. var byTransactionId: [UUID: [LineItem]] { return Dictionary(grouping: self) { item in item.transaction?.id ?? UUID() } } In this case, the transaction has been deleted, but the relationship existed when the fetch occurred, so the transaction value is non-nil. The crash occurs when accessing the id. This is the error. SwiftData/BackingData.swift:1035: Fatal error: This model instance was invalidated because its backing data could no longer be found the store. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0xb43fea2c4bc3b3f5 <x-coredata://A9EFB8E3-CB47-48B2-A7C4-6EEA25D27E2E/Transaction/p1756>))) I see other posts about this error and am exploring some suggestions, but if anyone has any thoughts, they would be appreciated.

I got several reports about our TestFlight app crashing unconditionally on 2 devices (iOS 18.1 and iOS 18.3.1) on app start with the following reason: Termination Reason: DYLD 4 Symbol missing Symbol not found: _$sScIsE4next7ElementQzSgyYa7FailureQzYKF (terminated at launch; ignore backtrace) The symbol in question demangles to (extension in Swift):Swift.AsyncIteratorProtocol.next() async throws(A.Failure) -> A.Element? Our deploy target is iOS 18.0, this symbol was introduced in Swift 6.0, we're using latest Xcode 16 now - everything should be working, but for some reason aren't. Since this symbol is quite rarely used directly, I was able to pinpoint the exact place in code related to it. Few days ago I added the following code to our app library (details omitted): public struct AsyncRecoveringStream<Base: AsyncSequence>: AsyncSequence { ... public struct AsyncIterator: AsyncIteratorProtocol { ... public mutating func next(isolation actor: isolated (any Actor)? = #isolation) async throws(Failure) -> Element? { ... } } } I tried to switch to Xcode 26 - it was still crashing on affected phone. Then I changed next(isolation:) to its older version, next(): public mutating func next() async throws(Failure) -> Element? And there crashes are gone. However, this change is a somewhat problematic, since I either have to lower Swift version of our library from 6 to 5 and we loose concurrency checks and typed throws or I'm loosing tests due to Swift compiler crash. Performance is also affected, but it's not that critical for our case. Why is this crash happening? How can I solve this problem or elegantly work around it? Thank you! 2025-10-09_17-13-31.7885_+0100-23e00e377f9d43422558d069818879042d4c5c2e.crash

Hi everyone, I’m trying to register fonts system-wide using CTFontManagerRegisterFontURLs with the .persistent scope. The fonts are delivered through Apple-Hosted Background Assets (since On-Demand Resources are deprecated). Process-level registration works perfectly, but persistent registration triggers a system “Install Fonts” prompt, and tapping Install causes the app to crash immediately. I’m wondering if anyone has successfully used Apple-Hosted Background Assets to provide persistent, system-wide installable fonts, or if this is a current OS limitation/bug. What I Expect Fonts delivered through Apple-Hosted Background Assets should be eligible for system-wide installation Tap “Install” should install fonts into Settings → Fonts just like app-bundled or ODR fonts App should not crash Why This Matters According to: WWDC 2019: Font Management and Text Scaling Developers can build font provider apps that install fonts system-wide, using bundled or On-Demand Resources. WWDC 2025: Discover Apple-Hosted Background Assets On-Demand Resources are deprecated, and AHBAs are the modern replacement. Therefore, persistent font installation via Apple-Hosted Background Assets appears to be the intended path moving forward. Question Is this a known limitation or bug in iOS? Should .persistent font installation work with Apple-Hosted Background Assets? Do we need additional entitlement, manifest configuration, or packaging rules? Any guidance or confirmation from Apple engineers would be greatly appreciated. Additional Info I submitted a Feedback including a minimal reproducible sample project: FB21109320

Hi everyone, I'm looking for the correct architectural guidance for my SwiftData implementation. In my Swift project, I have dedicated async functions for adding, editing, and deleting each of my four models. I created these functions specifically to run certain logic whenever these operations occur. Since these functions are asynchronous, I call them from the UI (e.g., from a button press) by wrapping them in a Task. I've gone through three different approaches and am now stuck. Approach 1: @MainActor Functions Initially, my functions were marked with @MainActor and worked on the main ModelContext. This worked perfectly until I added support for App Intents and Widgets, which caused the app to crash with data race errors. Approach 2: Passing ModelContext as a Parameter To solve the crashes, I decided to have each function receive a ModelContext as a parameter. My SwiftUI views passed the main context (which they get from @Environment(\.modelContext)), while the App Intents and Widgets created and passed in their own private context. However, this approach still caused the app to crash sometimes due to data race errors, especially during actions triggered from the main UI. Approach 3: Creating a New Context in Each Function I moved to a third approach where each function creates its own ModelContext to work on. This has successfully stopped all crashes. However, now the UI actions don't always react or update. For example, when an object is added, deleted, or edited, the change isn't reflected in the UI. I suspect this is because the main context (driving the UI) hasn't been updated yet, or because the async function hasn't finished its work. My Question I'm not sure what to do or what the correct logic should be. How should I structure my data operations to support the main UI, Widgets, and App Intents without causing crashes or UI update failures? Here is the relevant code using my third (and current) approach. I've shortened the helper functions for brevity. // MARK: - SwiftData Operations extension DatabaseManager { /// Creates a new assignment and saves it to the database. public func createAssignment( name: String, deadline: Date, notes: AttributedString, forCourseID courseID: UUID, /*...other params...*/ ) async throws -> AssignmentModel { do { let context = ModelContext(container) guard let course = findCourse(byID: courseID, in: context) else { throw DatabaseManagerError.itemNotFound } let newAssignment = AssignmentModel( name: name, deadline: deadline, notes: notes, course: course, /*...other properties...*/ ) context.insert(newAssignment) try context.save() // Schedule notifications and add to calendar _ = try? await scheduleReminder(for: newAssignment) newAssignment.calendarEventIDs = await CalendarManager.shared.addEventToCalendar(for: newAssignment) try context.save() await MainActor.run { WidgetCenter.shared.reloadTimelines(ofKind: "AppWidget") } return newAssignment } catch { throw DatabaseManagerError.saveFailed } } /// Finds a specific course by its ID in a given context. public func findCourse(byID id: UUID, in context: ModelContext) -> CourseModel? { let predicate = #Predicate<CourseModel> { $0.id == id } let fetchDescriptor = FetchDescriptor<CourseModel>(predicate: predicate) return try? context.fetch(fetchDescriptor).first } } // MARK: - Helper Functions (Implementations omitted for brevity) /// Schedules a local user notification for an event. func scheduleReminder(for assignment: AssignmentModel) async throws -> String { // ... Full implementation to create and schedule a UNNotificationRequest return UUID().uuidString } /// Creates a new event in the user's selected calendars. extension CalendarManager { func addEventToCalendar(for assignment: AssignmentModel) async -> [String] { // ... Full implementation to create and save an EKEvent return [UUID().uuidString] } } Thank you for your help.

Hello! We are in the progress of migrating a large Swift 5.10 legacy code base over to use Swift 6.0 with Strict Concurrency checking. We have already stumbled across a few weird edge cases where the "guaranteed" @MainActor isolation is violated (such as with @objc #selector methods used with NotificationCenter). However, we recently found a new scenario where our app crashes accessing main actor isolated state on a background thread, and it was surprising that the compiler couldn't warn us. Minimal reproducible example: class ViewController: UIViewController { var isolatedStateString = "Some main actor isolated state" override func viewDidLoad() { exampleMethod() } /// Note: A `@MainActor` isolated method in a `@MainActor` isolated class. func exampleMethod() { testAsyncMethod() { [weak self] in // !!! Crash !!! MainActor.assertIsolated() // This callback inherits @MainActor from the class definition, but it is called on a background thread. // It is an error to mutate main actor isolated state off the main thread... self?.isolatedStateString = "Let me mutate my isolated state" } } func testAsyncMethod(completionHandler: (@escaping () -> Void)) { let group = DispatchGroup() let queue = DispatchQueue.global() // The compiler is totally fine with calling this on a background thread. group.notify(queue: queue) { completionHandler() } // The below code at least gives us a compiler warning to add `@Sendable` to our closure argument, which is helpful. // DispatchQueue.global().async { // completionHandler() // } } } The problem: In the above code, the completionHandler implementation inherits main actor isolation from the UIViewController class. However, when we call exampleMethod(), we crash because the completionHandler is called on a background thread via the DispatchGroup.notify(queue:). If were to instead use DispatchQueue.global().async (snippet at the bottom of the sample), the compiler helpfully warns us that completionHandler must be Sendable. Unfortunately, DispatchGroup's notify gives us no such compiler warnings. Thus, we crash at runtime. So my questions are: Why can't the compiler warn us about a potential problem with DispatchGroup().notify(queue:) like it can with DispatchQueue.global().async? How can we address this problem in a holistic way in our app, as it's a very simple mistake to make (with very bad consequences) while we migrate off GCD? I'm sure the broader answer here is "don't mix GCD and Concurrency", but unfortunately that's a little unavoidable as we migrate our large legacy code base! 🙂

I have a visionOS app where I instantiate ARKitSession and various providers (HandTrackingProvider and WorldTrackingProvider) in my appModel. That way, I can pass these providers to a Task which runs a gRPC server for sending the data from these providers to a client. When the users enters the immersive space of the app, the ARKitSession will run the providers if they are not running already. I am now trying to implement the AccessoryTrackingProvider with the PSVR sense controllers but it does not fit with my current framework because the controllers may not be connected when the ARKitSession.run function is called. So I need to find a new place to start the session. My question is, if I already have a session which is running the hand and world tracking providers, can I start another session to run the accessory tracking? Should they all be running on the same session? Is there a way to stop the session and restart it when the controllers are connected? When I tried this, I get an error that says "It is not possible to re-run a stopped data provider (<ar_hand_tracking_provider_t: " but if I instantiate a new HandTrackingProvider, then the one that got passed to the gRPC task would no longer be the one running in the new session. Any advice on how best to manage the various providers and ARKit sessions would be greatly appreciated.

Since Xcode 26 our tests are crashing due to the Main Thread not being able to deallocate WKNavigationResponse. Following an example: import Foundation import WebKit final class WKNavigationResponeMock: WKNavigationResponse { private let urlResponse: URLResponse override var response: URLResponse { urlResponse } init(urlResponse: URLResponse) { self.urlResponse = urlResponse super.init() } convenience init(httpUrlResponse: HTTPURLResponse) { self.init(urlResponse: httpUrlResponse) } convenience init?(url: URL, statusCode: Int) { guard let httpURLResponse = HTTPURLResponse(url: url, statusCode: statusCode, httpVersion: nil, headerFields: nil) else { return nil } self.init(httpUrlResponse: httpURLResponse) } } import WebKit import XCTest final class ExampleTests: XCTestCase { @MainActor func testAllocAndDeallocWKNavigationResponse() { let expectedURL = URL(string: "https://galaxus.ch/")! let expectedStatusCode = 404 let instance = WKNavigationResponeMock() // here it should dealloc/deinit `instance` automatically } Here the call stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x101f3dd54 CFRetain.cold.1 + 16 1 CoreFoundation 0x101e14860 CFRetain + 104 2 WebKit 0x10864dd24 -[WKNavigationResponse dealloc] + 52

Hi, I am programming in C and would like to use Grand Central Dispatch for parallel computing (I mostly do physics based simulations). I remember there used to be example codes provided by Apple, but can't find those now. Instead I get the plain documentation. May anyone point me to the correct resources? It will be greatly appreciated. Thanks ☺.

Error: "Attrubute can only be applied to types not declarations" on line 2 : @unchecked @unchecked enum ReminderRow : Hashable, Sendable { case date case notes case time case title var imageName : String? { switch self { case .date: return "calendar.circle" case .notes: return "square.and.pencil" case .time: return "clock" default : return nil } } var image : UIImage? { guard let imageName else { return nil } let configuration = UIImage.SymbolConfiguration(textStyle: .headline) return UIImage(systemName: imageName, withConfiguration: configuration) } var textStyle : UIFont.TextStyle { switch self { case .title : return .headline default : return .subheadline } } }

Hi, I've got this view model that will do a search using a database of keywords. It worked fine when the SearchEngine wasn't an actor but a regular class and the SearchResult wasn't a Sendable. But when I changed them, it returned Type of expression is ambiguous without a type annotation error at line 21 ( searchTask = Task {). What did I do wrong here? Thanks. protocol SearchableEngine: Actor { func searchOrSuggest(from query: String) -> SearchResult? func setValidTitles(_ validTitles: [String]) } @MainActor final class SearchViewModel: ObservableObject { @Published var showSuggestion: Bool = false @Published var searchedTitles: [String] = [] @Published var suggestedKeyword: String? = nil private var searchTask: Task<Void, Never>? private let searchEngine: SearchableEngine init(searchEngine: SearchableEngine) { self.searchEngine = searchEngine } func search(_ text: String) { searchTask?.cancel() searchTask = Task { guard !Task.isCancelled else { return } let searchResult = await searchEngine.searchOrSuggest(from: text) ?? .notFound guard !Task.isCancelled else { return } await MainActor.run { switch searchResult { case let .searchItems(_, items): showSuggestion = false searchedTitles = items.map(\.title) suggestedKeyword = nil case let .suggestion(keyword, _, items): showSuggestion = true searchedTitles = items.map(\.title) suggestedKeyword = keyword case .notFound: showSuggestion = false searchedTitles = [] suggestedKeyword = nil } } } } }