I understand the issues you have raised, and I can certainly see that there are pretty obvious security concerns in publicizing the use case. I will put together a feedback report about this and address these issues privately. The app in question is one which I wrote for myself (and offered to others who might be interested) — there ought to be a way that I can actually get to use my own app (i.e., synched between my own devices)... I'll post the FB number to this thread ASAP.

I submitted the following Feedback # FB22949727: I have need for sorting capabilities in @Query which cannot be met using the available SortDescriptors. (Example below) Toward that end, I used the SortComparator protocol to create conforming comparators, but could not use them in SortDescriptor because the comparator parameter in all SortDescriptor initializers are type String.StringComparator, not SortComparator. I.e., what I am looking for is a SortDescriptor initializer with a signature something like init(_ keyPath: any KeyPath<.> & Sendable, comparator: SortComparator, order: SortOrder) which is not available. Side Note: Actually, making SortDescriptor more flexible and powerful is generally a good idea because it is also applicable to sort(using:) and similar Foundation functions. My Actual Example: I have a SwiftData Model which contains a Date field and a Category field (implemented as an enumeration). A @Query over objects of this Model should result in an array of these objects. The sort of the query should have a primary and secondary SortDescriptor. The primary SortDescriptor sorts by date ignoring time. (I.e., objects with a date on the same day are considered equal — although the time components are relevant in other contexts) The secondary SortDescriptor sorts by category, but in an order that I define which is neither based on the category rawValues string order nor the order in which the enumeration cases are defined. I would like the sort to take place in the processing of the Query, because then I don’t need to worry about handling all cases where a change in an object should involve a re-sort.

Thank you! I've verified that your recommended change resolved my problem in my real app and on a real physical device. As with many things, once the solution was pointed out to me, I realized that I should have figured it out. The way I look at it is this: Session (for example) has a reference to Course. But since Schema090.Course and Schema100.Course are different, Schema090.Session and Schema100.Session are conceptually different types. Since I did not define Scheam090.Session and Schema100.Session explicitly, there was ambiguity as to which object should be used. This is not a problem in the app itself (since it only works with Schema100 models), but it is a problem for migration, which needs to work with both Schema090 models and Schema100 models (presumably simultaneously). And SwiftData recognized the ambiguity and dealt with it by throwing an error in migration. Lesson learned. Thank you.

I fully understand your current time pressures and priorities — no worries. I just sent the sample code off to Developer Tech Support. Instructions are in the email. If you have any questions, please feel free to give me a call or email.

I think I just uncovered something important. I have a simple sample app in which the v1 schema had a single Model. I was able to migrate it to v2 successfully. But then, I added a second Model to the v2 schema. And the migration crashed. That is, the v1 schema had one Model and the v2 schema had 2 Models. If, in fact, this is the source of the migration crash, the question then becomes, "How do I add a Model to an existing database without destroying all of the data previously stored in the database?" NOTE: In this simple case, the second Model is independent of the first Model. But in real life, I'd like to both add a new Model to the database, and add @Relationships between that Model and the other Models already present. Is this possible? And if so, can someone provide insight into how this could be done? (I note that I can't remember seeing any migrations that involved Relationships...)

I went through my entire schema and made sure that every attribute and every relationship in all 17 models was either optional or had a default value. I reloaded the app from TestFlight (restoring the old schema (v0.9.0) and populated it with some records. I then ran the new version of the app (with schema v1.0.0 and all the added default values) and got the same error: "Cannot use staged migration with an unknown model version." Is it possible that the lack of default values in the v0.9.0 schema is the problem? (I.e., migration just can't deal with a non-optional without a default value at all? Not just for changed attributes? Or is there something else that I'm missing?

I had the same issue on a M1-Max Studio (with installations of 26.4 beta 3, beta 4, and the RC). I finally solved it and reported the following as a appendix to FB22153797: SUCCESS!! First, what didn’t work — I booted in Safe Mode and tried to install Tahoe 26.4. This failed just as reported above. Then, I DEINSTALLED the F-Secure security suite (which came with my Spectrum Business ISP account). Then attempted the installation (in NORMAL mode, not Safe Mode). The installation worked. So it is clear that the install problem was related to something that F-Secure did to my system that was undone by de-installation.

Thank you. That's what I was hoping you'd say. Cheers

Thank you. I get it. I implemented a call to .fileExporter in the MacCatalyst case and it is an acceptable solution — only one extra mouse click. However, I would like to point out that I'm not "littering the Documents folder with random things by default". In this case, the user chooses a "Save to File" option, which causes a carefully curated folder of information to be zipped and placed in their Documents folder for the purpose of being accessible for sharing with others - for example, so they can place it in Google Docs or Dropbox. (I also implement a "Send as an email attachment" option...) ...just sayin'