“SwiftData inheritance relationship”

Alright, so I'm gonna send an email out to Eddy, Matt and Susan. If anyone wants to be copied, paste your email address here. This is just beyond belief. It is unfortunate we have to let Apple leadership know this service is broken and most probably call out people (sadly). This sort of delay is severely severed my relationship with customers and users. I plan to send the email out over the week-end

Alright, so I'm gonna send an email out to Eddy, Matt and Susan. If anyone wants to be copied, paste your email address here. This is just beyond belief. It is unfortunate we have to let Apple leadership know this service is broken and most probably call out people (sadly). This sort of delay is severely severed my relationship with customers and users. I plan to send the email out over the week-end.

Very interesting info! I can understand that thinking, but it's not the system’s perspective. The system’s view here is that the file reference is considered more authoritative than the path. I actually don't have a strong opinion about file reference urls vs. file path urls but from my perspective in the sample it is clear after the second call to createDirectoryAtURL:..., when that method returns, the fileReferenceURL left lingering in that untitleFour instance is pointing to to the wrong folder based on the fact that I fed that URL directly into a method to create a folder, the operation succeeded, yet there is still a chance to accidentally access a completely different folder through that very same instance going through the cached fileReferenceURL. MacOS itself is heavily still reliant on path, but fileReferenceURLs are the closest construct we have to an API that doesn't fall into this trap. Yea. You can't even create a file without a path so there is that. File reference urls are great at certain thin

Out of curiosity, I just tested this, and I still see the bug. To see it yourself, just use the code from my first post but change the savingURL accessor to use a security-scoped bookmark, as follows: To be honest, that was basically a blind (well, slightly educated...) guess. To be honest, the whole combination of factors is fairly odd (timing is random, failure self-corrects, etc.). One thing to pass along— I just did a bit of testing with retrying the copy, and clearing the error seems to be tied to TIME, not retry count. If you decide to go the retry route, you may want to delay the save for a second or so instead of just retrying over and over. I’m actually doing (b), since this is very fast on copy-on-write volumes such as APFS even for large files. (Copy-to-temp file is almost instant.) I think very fast actually understates how significant the performance difference is. As an industry, I'm not sure we've really processed how constant-time copying should change file management. For slower volumes, much

I want to share all the content of a CloudKit database at once between different iCloud accounts. For example, to manage products storage between users. Once the database has been shared or an invitation has been accepted, any additions/modifications/deletions to storage or products must be shared between all users without additional sharing. To be short after the first sharing, everything must be shared without additional new sharing. I think I can't do this in SwiftData (would be the best solution for me as all the current app is based on SwiftDaa) and that I need to use move to CoreData. Is that correct? Or does a mixed solution may be possible (ie .storage with SWiftData and sharing with CoreData)? It seems that “Zone Wide Sharing” could be the solution? But I can't find a sufficiently comprehensive example and I wasn't able to make something working. Ultimately, I realize that this is not a very common use case. With the ZoneWide Sharing does it means that we must do a affectedStores or

Just to confirm that @Attribute(.preserveValueOnDeletion) doesn't preserve relationships. It only works for attributes. Given that, I don't see anything in the SwiftData history that can help restore a relationship between two SwiftData objects after they are deleted. Best, —— Ziqiao Chen  Worldwide Developer Relations.

First, I wanted to apologize for not replying for a full month, as well as thank you very much for your reply. I was pulled away from this project for a couple weeks, and when I got back I was still spinning my wheels getting the driver installed. Not a problem at all. It was 67 characters and, apparently the maximum is 63. Seems like an arbitrarily short max in this day and age, and you'd think both XCode and the Developer Portal would catch that, but that's what it was. Sigh... I'm sorry I didn't think of that, as I'm aware of that limitation and actually posted about it here. FYI, you should also be aware of the version number limitation described here, which is another arbitrary restriction the kernel enforces. So, on to my current problem. The driver installs... but doesn't load. Probably because it's not matching. So I'm going to give more detailed information in the hope you can help me with this. If you haven't seen it already, I have a post here that does an extended run down of the matching and load

For a large dataset, the initial synchronization with CloudKit, which can happen in several cases, including on-boarding a new device, can indeed be slow, or even failed. A similar issue was discussed in this thread as well. Depending on your concrete use case, you might address the issue in the following way: Have your app functional before the dataset is fully synchronized. Synchronize the data in batches in the background, until the whole data set is done. As an example, an email app that is just installed on a new device allows users to compose a new email, while synchronizing existing emails in the background. When using the CloudKit framework, you control what kind and amount of data to be synchronized with CloudKit, and hence can implement the strategy, though the implementation can be quite involved. Now that you are using SwiftData + CloudKit integration, NSPersistentCloudKitContainer takes care the synchronization process. I don't really see anything to work around or mitigate the issue in

Same problem for me !!!! use SwiftData, build great apps and POC… Then when you'll need sharing rewrite everything with coredata (that you may not mastered). As an independent developer it is really a pain. At least If I was sure that the sharing feature is schedule!

The run loop itself doesn't actually turn at a predictable rate. Depending on how your app is architected and the overall app state, it's entirely possible for an app to go seconds or even minutes without the main thread ever running. Doesn't appear to be what's going on in this case. I made this dumb little test which can easily reproduce the issue (sorry can't get code to format well on these forums). +(MachoManURLTester*)sharedTester { static MachoManURLTester *sharedTester = nil; static dispatch_once_t token; dispatch_once(&token,^{ sharedTester = [[self alloc]init]; }); return sharedTester; } -(void)startURLTrashDance { NSAssert(NSThread.currentThread.isMainThread, @Main thread only.); NSFileManager *fm = [NSFileManager defaultManager]; NSURL *wrapperDir = [[NSURL fileURLWithPath:NSTemporaryDirectory() isDirectory:YES] URLByAppendingPathComponent:NSUUID.UUID.UUIDString isDirectory:YES]; if (![fm createDirectoryAtURL:wrapperDir withIntermediateDirectories:YES attributes:nil error:nil]) { NSLog(@Test f