I got pointed in the right direction. In the CloudKit Console, click CloudKit Database. Select the correct Container in the top left corner. Click "Deploy Schema Changes" in the bottom left corner and confirm that. That fixed my issue.

So apparently something is wrong in this function. A timer makes the problem more obvious but seems to not have a direct effect. I want to change a property of a swiftdata object without using @query. In this case insert does not add a new item but updates the existing one, exactly the behavior I am looking for. func doManually() { let descriptor = FetchDescriptor<Item>() let results = (try? Helper.shared.modelContext?.fetch(FetchDescriptor<Item>())) ?? [] let element = results.first! element.timestamp = Date.now Helper.shared.modelContext?.insert(element) }

You have to be more specific about what you need help for. I don't even understand what you mean with TestFlight Code or what it has to do with Code Signing and Xcode Server.

A SwiftData Model cannot cross actor boundaries to avoid data races. You shouldn't make your model conform to Sendable because it still doesn't. I am currently in the same situation and as far as I can tell the best option to migrate to Swift 6 when using SwiftData is using ModelActor There are not as many tutorials and articles about it as other SwiftData topics but I believe this is the way to go. Do not return SwiftData Models from your ModelActor. This may result in data races when these models are accessed from different threads. Only return sole properties and the persistentModelIDto identify models. This is what my actor looks like: @ModelActor actor DataHandler { public func fetch<T>(_ descriptor: FetchDescriptor<T>) throws -> [PersistentIdentifier] { return try self.modelContext.fetchIdentifiers(descriptor) } public func update<T>(_ persistentIdentifier: PersistentIdentifier, keypath: ReferenceWritableKeyPath<YourModel, T>, to value: T) throws { guard let model = modelContext.model(for: persistentIdentifier) as? YourModel else { // Error handling } model[keyPath: keypath] = value } public func read<T>(_ persistentIdentifier: PersistentIdentifier, keypath: ReferenceWritableKeyPath<YourModel, T>) throws -> T { guard let result = modelContext.model(for: persistentIdentifier) as? Hoerspiel else { // Error Handling } return result[keyPath: keypath] } // And others like delete fetchCount etc. I think you get the point } You can also return a struct that has the same properties as your model if you need to read properties in a synchronous context. This struct will automatically conform to Sendable if you only use standard data types like Ints and Bools etc. Otherwise make it conform to Sendable. You will probably also have the error Passing argument of non-sendable type FetchDescriptor outside of outside main actor-isolated context may introduce data races You can either just never modify the fetch descriptor inside the modelActor (which there is no reason to do anyway) and mark the FetchDescriptor @unchecked Senable. I think the better option is to define your fetchDescriptor, modify it to your needs and then create a let constant that copies the previous fetchDescriptor. This way it cannot be mutated and therefore no data races can occur. I hope you were able to follow. Happy to provide clarifications or corrections if someone has found a better option.

You have to do the rounding of the corners yourself if you are building an app for macOS. (Except Mac Catalyst iirc) Your entire app icon document should have a size of 1024 x 1024. The icon itself should be 824 x 824 with a corner radius of 185.4 so it looks like you desire. Source: https://forums.developer.apple.com/forums/thread/670578?answerId=739409022#739409022

This sounds more like a bug report. You can file on at https://feedbackassistant.apple.com

You shouldn't mark your SwiftData model Sendable because it isn't. I suggest you use @MainActor. Instead of passing around your @Model you should only pass around the persistentModelID. If it works, you could also mark all of your views with SwiftData @MainActor. That might work for your project. Otherwise go with @ModelActor.

That is your display name. You can change that in Xcode -> Your Target -> General -> Identity -> Displayname

@SpaceMan You should use this instead: public func fetch<T>(_ descriptor: @Sendable () -> FetchDescriptor<T>) throws -> [PersistentIdentifier] { return try self.modelContext.fetchIdentifiers(descriptor()) } and you use that like: guard let loaded = try? await dataHandler.handler.fetch( { FetchDescriptor<MyModel>(predicate: #Predicate { model in model.somebool }, sortBy: [SortDescriptor(\.someKeypath)]) }) else { return }

Great that you were able to fix the problem yourself. It would be great if you could file a bug report since this does not look like correct behavior.

Just a quick idea: Can you access that relationship programmatically? So if you add a button that tries to print that relationship, does that work? Currently there is a bug that @Query does not update the view after an iCloud Sync. I filed a bug report for that. FB14619787 If you can indeed access that relationship you might be able to work around that by using this package (https://github.com/ggruen/CloudKitSyncMonitor) that can update your view whenever the iCloud sync status changes.

You need to infer a type manually and tell which property should match yours. MusicCatalogResourceRequest<Song>(matching: \.id, equalTo: song.id.rawValue) This is what you are looking for. Apart from that I strongly advise you to switch using IRSC (or UPC for albums) instead of the song id. The song id (or album id) can change at any time. Read the explanation here

This looks like a bug to me. You should definitely file a bug report for that. In my app I am using musicPlayer.setQueuer(with:)You can test whether that makes a difference.

Beta App Review is not as strict as App Review but why do you have a problem with being reviewed in the first place? Usually it takes less than 12 hours to get your app approved for TestFlight and if you do not have a malicious app you should have absolutely no problem passing the beta app review from my experience.

There is no need to act as a dummy switch. What you describe might be possible using Scenes in the Home app, meaning no code at all. It is definitely possible to directly adjust these devices using HomeKit (the developer kit, not the app). That will be possible on all platforms, but you might have to use Mac Catalyst.