“SwiftData inheritance relationship”

The companion sample code is this: Adopting SwiftData for a Core Data app, though it was updated for the SwiftData sessions in WWDC24 and WWDC25, and so is a bit different from the version published for WWDC23. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I've gotten OK, Bad-Gateway, Gateway Time-Out on four different systems. Even when OK is returned, it takes a while to get a response. This started almost exactly at 10am pacific time for me. Like many of you I used the security command line to check my certs, checked my firewall (PFSense), and even switch my build system and my target iPad to use my iPhone personal hot-spot, in order to bypass my infrastructure and still, no-joy. After reading your posts, I have become convinced that this is an Apple services issue, even though their status page says everything is working. More information. I have another project (Project-B) I'm working on, which is being developed on a different machine. Project-B installs on the same target iPad with no issues. I migrated the failing project (Project-A) over to this machine and added the missing certificates to the keychain so that the failing project would build. Even on this second system, I'm consistently getting the error for project-a but not for project-b. So, appare

Thanks for the research - unfortunately, this still doesn't allow me to migrate databases. If I create a new SwiftData database with the NSSecureCoding TestTransformable, I can save, load, and migrate it successfully. However, if I have an existing SwiftData database that wasn't created with the NSSecureCoding TestTransformable, things are strange: Once the codebase is recompiled with the NSSecureCoding conformance applied, I can load the old database successfully. However, it still fails in the same way when I go to migrate the database. To be clear - NSSecureCoding fixes save/load/migrate on a new database, but when applied to an existing database (such as the one I have deployed to iCloud), only save/load works, and migration still fails. Below are the changes made to test NSSecureCoding: @objc(TestTransformable) //toggle between these declarations for testing //final nonisolated class TestTransformable: NSObject, Codable, Sendable { final nonisolated class TestTransformable: NSObject, Co

I'm not sure what you mean here. If you want to know the current path location, then you ask the kernel to convert the reference to a path. [..] I'm not quite sure what you're thinking of here. If you're trying to display the contents of a directory hierarchy, then the process is exactly the same for paths and references. You start with the container and recursively iterate its contents, displaying whatever you find. What about changes? FSEventStreamRef reports changes on a directory. Does it work on file reference urls? I never even thought of trying. I can pick up changes on a subfolder 4 folders away from the root folder I'm watching, all using a single FSEventStreamRef. I'm not saying it isn't possible I just don't know? how can I parse a single change using current APIs in a deep tree with opaque file reference urls that don't have a concept of location without first converting to path to see what level I'm at? Sure. Why not? That's what the Carbon File Manager did. Well I'm not totally against the idea

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:..., Yes, and to be clear, that is very much a bug. More specifically, every URL should either be a file reference URL (in which case you'd reference the object in the trash) or a file path URL (in which case you'd reference the original path). You're ending up with a URL which is a mix of both, which is simply wrong. I'd need to test on older OS's, but I suspect this is actually a new bug, possibly introduced in Swift Foundation[1] [1] Much of the Objective C version of Foundation is actually written in Swift now. Yeah. You can't even create a file without a path, so there is that. Unfortunately, yes. I'm not claiming my radical idea is something that will ever be (again) implemented. Keep in mind that I'm not claiming that macOS is wrong about paths; I think EVERY operating system is wrong about paths. Well, every operating syst

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