Can you try changing the CloudKit container to a completely different one? I did this and suddenly it started working.
FuzzyCap
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
User for
Post
Replies
Boosts
Views
Activity
I'm also having the the exact same issue and get the Server Rejected error while trying to follow Apple's documentation: https://developer.apple.com/documentation/swiftdata/syncing-model-data-across-a-persons-devices
Environment: Xcode 16.1 on MacOS 15.1.
Attempted solutions:
I've tried specifying the exact container in the setup:
ModelConfiguration(schema: schema, isStoredInMemoryOnly: false, cloudKitDatabase: .private("iCloud.com.MyCompany.MyApp"))
Tried reseting the container environment.
Signed out/in of iCloud and restarted computer.
Made sure iCloud storage isn't full.
Added the CloudKit framework manually to the target.
Initialized schema manually as shown in the documentation (this causes a crash with the same error).
Tried removing the CloudKit permission from the Certificates, Identifiers & Profiles in my developer account then re-adding it.
None of that has worked, and the CloudKit dashboard doesn't show that any schema was created.
Error:
CoreData: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _recoverFromError:withZoneIDs:forStore:inMonitor:](2620): <NSCloudKitMirroringDelegate: 0x600000938000> - Failed to recover from error: CKErrorDomain:15
Recovery encountered the following error: (null):0
CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _finishedRequest:withResult:](3582): Finished request: <NSCloudKitMirroringDelegateSetupRequest: 0x60000152c960> 31BF786C-8AD8-48F4-A8A3-328A17A51019 with result: <NSCloudKitMirroringResult: 0x6000038c82a0> storeIdentifier: F3647739-ECCB-4106-AD56-1C4D329C954C success: 0 madeChanges: 0 error: <CKError 0x60000385fae0: "Partial Failure" (2/1011); "Failed to modify some record zones"; uuid = 517D53B7-C0E1-4EFB-AEB9-D3339C122DFE; container ID = "iCloud.com.MyCompany.MyApp"; partial errors: {
com.apple.coredata.cloudkit.zone:__defaultOwner__ = <CKError 0x6000038d3150: "Server Rejected Request" (15/2000); op = A473375D93C18793; uuid = 517D53B7-C0E1-4EFB-AEB9-D3339C122DFE>
}>
I'm also interested in figuring out how to do this. Our app uses a lot of WebViews, so having to manually open it every time we rebuild the app is very time consuming.
I'm also wondering if this is possible. I'd like my iOS app to be free, while the Mac app stays paid.
Thanks everyone,
I understand why that's happening way better now.
The problem is that I need state because the view is draggable. Specifically I'm attempting to create a draggable box that is positioned by percentages within its container. So just initializing its size in the init without state doesn't work.
Is there a way to force update state? Or some method that can be called outside of the init (such as a resize event from the container)? I tried using on appear but just like state it only gets called once.
Here's an example that better shows what I need to accomplish, and the problem:
struct ContentView: View {
		var body: some View {
				GeometryReader { geo in
						ZStack(alignment: .topLeading) {
							 /* There are multiple of these: */
								DraggableBox(containerSize: geo.size)
						}
						.frame(maxWidth: .infinity, maxHeight: .infinity)
						.border(Color.green, width: 1)
				}
		}
}
struct DraggableBox: View {
		var containerSize: CGSize
		@State var realSize: CGRect = .zero
		/* This needs to be called when the parent changes size */
		/* It's called when the view appears, but doesn't udpate when the window changes size */
		func updateSize() {
				let newSize = CGRect(x: realSize.minX, y: realSize.minY, width: containerSize.width * 0.4, height: containerSize.height * 0.4)
				realSize = newSize
		}
		func onDrag(mousePos: CGPoint, startPos: CGPoint) {
				/* Minimal working example of how the drag stuff works */
				/* In reality the x and y position are also a percentage relative to the container like the width */
				let x = mousePos.x
				let y = mousePos.y
				let newSize = CGRect(x: x, y: y, width: containerSize.width * 0.4, height: containerSize.height * 0.4)
				self.realSize = newSize
		}
		var body: some View {
				VStack {
						Text("Drag me!")
						Button(action: { self.updateSize() }, label: { Text("Fix relative size") })
				}
				.frame(width: realSize.width, height: realSize.height)
				.background(Color.blue)
				.offset(x: realSize.minX, y: realSize.minY)
				.gesture(
						DragGesture()
								.onChanged({ (value) in
										self.onDrag(mousePos: value.location, startPos: value.startLocation)
								})
				)
				.onAppear {
						self.updateSize()
				}
		}
}
Thanks Eskimo!I'll cross my fingers when it goes into review!
Thanks for the reply Eskimo,I didn't realize that full disk access still won't allow reading the desktop image, but after more testing I guess that's the case.Is there any other way the app could do this without a user-initiated open dialog? It just won't work well for what we're attempting to do.Specifically, one of the app's features will be to allow a user to place widgets (boxes with different information) on their desktop.The way we were going about this is to create a transparent window on the desktop level that displays the widgets. The widgets need to interact with the desktop wallpaper visually in multiple ways. So we were getting the wallpaper as I showed above, and placing it within the transparent window. This mimicked the user's desktop exactly. I also created a file change listener for the file /Library/Application Support/Dock/desktoppicture.db so the app knew when the desktop changed. I know it's a little brittle since its a system file, but I couldn't find another way to do it.This worked great until I enabled app sandbox.Do you happen to have any other suggestions? Or are we out of luck?I suppose that maybe the solution is to have the app manage the wallpaper itself, instead of following the system wallpaper.