Hi there, Had no issues with Core Data and Cloud Kit syncing. Then, when I updated my macOS to 13.3, I am getting the following error from cloud kit: reason=Can't find or automatically infer mapping model for migration, NSUnderlyingError=0x60000367b330 {Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={entity=Item, property=image, Reason=Unable to use inferred mapping to move external reference into store.}}} The reason I think it's due to the macOS update is because my cloud kit initialization and syncing has no trouble on my phone simulator or physical devices. Also, I didn't change my model in any significant way, and checking out old versions of my code lead to the same error. Has anyone else experienced issues with Core Data migration on macOS 13.3? Or can anyone explain why I might see this issue on macOS specifically?

Hi there, Following this tutorial for my own project: https://developer.apple.com/videos/play/wwdc2020/10650/?time=319 I noticed that I cannot mark modifiedAt index as queriable. It doesn't appear in a list, and I heard that it was renamed to modifiedTimestamp (can someone confirm?) Although I've managed to upload records to the public DB, my fetching has been unsuccessful. I'm getting this error: CoreData: warning: CoreData+CloudKit: -[NSCloudKitMirroringDelegate finishedAutomatedRequestWithResult:](3372): Finished request '<NSCloudKitMirroringExportRequest: 0x600000eb6df0> 33AA10FE-C31F-44BB-A693-D3DC06604D18' with result: <NSCloudKitMirroringResult: 0x6000023ee790> storeIdentifier: 65A47C2C-8591-4404-B39C-44635142C32E success: 0 madeChanges: 0 error: Error Domain=NSCocoaErrorDomain Code=134406 "Request '33AA10FE-C31F-44BB-A693-D3DC06604D18' was aborted because the mirroring delegate never successfully initialized due to error: <CKError 0x6000023ee670: "Invalid Arguments" (12/2016); server message = "Field '___modTime' is not marked sortable"; op = A78A2D1EA27AD7B2; uuid = 88F346ED-96BB-4607-B764-957C313B71C2; container ID = "iCloud.tchapman.test2">" UserInfo={NSLocalizedFailureReason=Request '33AA10FE-C31F-44BB-A693-D3DC06604D18' was aborted because the mirroring delegate never successfully initialized due to error: <CKError 0x6000023ee670: "Invalid Arguments" (12/2016); server message = "Field '___modTime' is not marked sortable"; op = A78A2D1EA27AD7B2; uuid = 88F346ED-96BB-4607-B764-957C313B71C2; container ID = "iCloud.tchapman.test2">} I don't know what this __modTime field is, but is it related to the missing modifiedAt index? I'll also provide my container init code for reference: let description = NSPersistentStoreDescription(url: storeURL) description.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.tchapman.test2") // MARK: Public Description let publicStoreURL = description.url!.deletingLastPathComponent().appendingPathComponent("AppleCloset-public2.sqlite") let publicDescription = NSPersistentStoreDescription(url: publicStoreURL) publicDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) publicDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) let publicOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: description.cloudKitContainerOptions!.containerIdentifier) publicOptions.databaseScope = .public publicDescription.cloudKitContainerOptions = publicOptions container.persistentStoreDescriptions = [publicDescription]

Hey all, I noticed a useful macro in the "What's new in Swift" WWDC2023 session called @CaseDetection. Seems like they used it in the presentation without defining it, so I assumed it was included in the Swift 5.9 installation? @CaseDetection is not a recognized attribute in my XCode 15 beta. Is that expected? Best, T

I’m receiving the error below in all cases where I try to install an app to my phone via Xcode - it seems like the upgrade leading to some sort of issue sourcing the included frameworks. Notably, the same thing happens when I try to install onto my macOS. dyld[2989]: Symbol not found: _$s21DeveloperToolsSupport7PreviewV7SwiftUIE_6traits4bodyACSSSg_AA0D5TraitVyAC10ViewTraitsOGdAD0J0_pyctcfC Referenced from: /private/var/containers/Bundle/Application/2C2F6084-1752-43A6-954C-528047EF9B76/Runway.app/Runway Expected in: <7978D7D2-5C77-3634-B74C-DBE4B15746FA> /System/Library/Frameworks/SwiftUI.framework/SwiftUI Already submitted a feedback report to Apple: FB12757584 Anyone find a workaround?

Feedback Report: FB12758649 Build Error Message: External macro implementation type 'ObservationMacros.ObservableMacro' could not be found for macro 'Observable' Introduced on upgrading from xCode 15 beta 4 to xCode beta 5. Only an issue for iOS (macOS builds and runs correctly) import CloudKit import Observation @Observable class AggregateModel { ... }

I'm having trouble understanding the use case for discardingTaskGroup. In my app, I want to submit 10 concurrent image upload requests; usually, I'd just fire off 10 unstructured Task {} instances (I'm assuming this is fine) for image in images { Task { do { try await uploadImage(item: item, image: image) } catch { // Handle any errors } } } But then I thought I'd actually like to have a max of ~3 uploads concurrently, where I would prioritize the images that appear to the user earlier first. I know using group.next() in a taskGroup we can await on previous results and add tasks as required. But my task does not return data, rather it performs an action. So, it seems like the new discardingTaskGroup could be a useful API. Task { do { try await withThrowingDiscardingTaskGroup { group in for image in images { group.addTask { try await uploadImage(item: item, image: image) } } } } catch { // Handle any errors } } How can I convert this discarding task group code to only include a max of n tasks running concurrently? And is this even a reasonable use of the new API to begin with? Best, T

The Sendable documentation says we can mark reference types as Sendable if they "internally manage access to their state." Adding Sendable conformance to my SwiftData classes silences warnings such as the following: "Non-sendable type '[Item]' returned by implicitly asynchronous call to nonisolated function cannot cross actor boundary" @Model final class Item: Sendable { var sampleProperty = "" } My understanding is that the compiler would complain if adding explicit Sendable conformance to a swift data model was breaking concurrency rules, but I wanted to check with the community to see what everyone thinks. Best, Taylor

In XCode Beta 7 I am getting a new error: Cannot convert value of type 'ModelConfiguration' to expected argument type 'any PersistentModel.Type' struct AppleClosetApp: App { let config = ModelConfiguration(url: AppGroup.facts.containerURL ?? URL(fileURLWithPath: "")) var body: some Scene { WindowGroup { ClosetNavigationView() .modelContainer(try! ModelContainer(for: Closet.self, config)) } } } Anyone else saving to a custom swift data URL getting this emergent issue?

Hi there, When using WidgetKit, should I should fetch my SwiftData main app's database in the TimelineProvider or directly on the widget's view? Also, my understanding is that the widget view's code is run during the archiving process and not when the view first appears on the user's device. So, is it true that accessing in the TimelineProvider vs. accessing in the view will both run at approximately the same time, and thus will return the same DB results? Best, Taylor

Hi there, Feedback ID: FB13479210 XCode 15.1. iOS 17.2 Inspector sheet is not shown as ultra thin material as expected. Full code: import SwiftUI @main struct InspectorExample: App { var body: some Scene { WindowGroup { InspectorExampleView() } } } struct InspectorExampleView: View { @State private var inspectorPresented = false @State private var departmentId: String? @State private var employeeIds: String? var body: some View { Button("Click") { inspectorPresented = true }.background(.white) .inspector(isPresented: $inspectorPresented) { Text("Sample Inspector") .presentationBackground(.ultraThinMaterial) }.background(.blue) } }

Feedback ID: FB13481459 Adding the presentationBackgroundInteraction(.disabled) to a sheet causes the sheet’s content (in the sample project, this is a button) to lose its default accentColor behaviour. import SwiftUI @main struct InspectorExample: App { var body: some Scene { WindowGroup { InspectorExampleView() } } } struct InspectorExampleView: View { @State private var inspectorPresented = false var body: some View { Button("Click") { inspectorPresented = true }.background(.white) .inspector(isPresented: $inspectorPresented) { Button("Sample Inspector") {} .presentationBackgroundInteraction(.disabled) // adding this modifier causes the Button view to lose its default accent color } } } #Preview { InspectorExampleView() } The images show the button with the default blue accent colour (expected) vs. the grey out version (actual).