I am implementing a custom migration, and facing an issue while implementing a WAL checkpointing.
Here is the code for WAL checkpointing
func forceWALCheckpointingForStore(at storeURL: URL, model: NSManagedObjectModel) throws {
let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: model)
let options = [NSSQLitePragmasOption: ["journal_mode": "DELETE"]]
let store = try persistentStoreCoordinator.addPersistentStore(type: .sqlite, at: storeURL, options: options)
try persistentStoreCoordinator.remove(store)
}
When the coordinator tries to add the store I am getting the following error
fault: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store
My questions are
Is it really necessary to force WAL checkpointing before migration? I am expecting NSMigrationManager to handle it internally. I am assuming this because the migrateStore function asks for the sourceType where I am passing StoreType.sqlite
If checkpointing is required, then how do I address the original issue
Note:
Since my app supports macOS 13, I am not able to use the newly introduced Staged migrations.
There is similar question on Stackoverflow that remains unanswered. https://stackoverflow.com/q/69131577/1311902
iCloud & Data
RSS for tagLearn how to integrate your app with iCloud and data frameworks for effective data storage
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm working on a macOS app with a Safari web extension. I'm trying to share a SwiftData model between devices using CloudKit synchronization. I am able to get synchronization in the main app on the same device, CloudKit sync works correctly — changes appear in the CloudKit Dashboard under com.apple.coredata.cloudkit.zone.
However, in the Safari App Extension, data is saved locally and persists across launches, but never syncs to CloudKit.
I have followed the recommended practices for configuring the App Group and entitlements, but the issue persists.
Questions:
Is there an official limitation preventing Safari App Extensions from connecting to the CloudKit daemon (cloudd)?
If not, what entitlements or configuration changes are required for a Safari App Extension to successfully sync with CloudKit?
Is the xpc_error=159 from bootstrap_look_up() a known sandbox restriction for this extension type?
Any guidance from Apple engineers or others who have successfully used CloudKit from a Safari App Extension would be appreciated.
What I’ve confirmed:
The extension’s .entitlements includes:
com.apple.security.app-sandbox
com.apple.developer.icloud-services
CloudKit
com.apple.developer.icloud-container-identifiers
iCloud.dev.example.myapp
Same iCloud container ID for both app and extension
CloudKit container exists and is initialized in CloudKit Console
Running in :Sandbox environment during development
Database name in SwiftData matches container identifier (without the iCloud. prefix)
The extension’s codesign output shows correct entitlements
App Group is configured (although in this case, extension and app use separate stores intentionally)
Observed behavior in Console.app logs:
CloudKit sync engine initializes in the extension
XPC activities are registered for import/export:
_xpc_activity_register: com.apple.coredata.cloudkit.activity.export.
xpc_activity_set_criteria: ... import.
Then a bootstrap lookup fails:
failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159]
CloudKit daemon connection error:
CKErrorDomain Code=6 "Error connecting to CloudKit daemon"
NSCocoaErrorDomain Code=4099
There is no “Will attempt to upload transactions” or “Upload succeeded” logs are ever seen.
Symptoms
When the extension is run, I see logs like the following in Console.app:
[0x13e215820] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159]
CoreData+CloudKit: -[PFCloudKitSetupAssistant _checkAccountStatus:]_block_invoke(342): Fetched account info for store : (null)
Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon. This could happen for many reasons..."
Hello,
In our app, we’ve modeled our schema using inheritance introduced in iOS 26.0, and we’re implementing SwiftData History to re-fetch models only when necessary.
@Model public class Transaction {
@Attribute(.preserveValueOnDeletion)
public var date: Date = Date()
public var amount: Double = 0
public var memo: String?
}
@Model public final class Spending: Transaction {
public var installmentIndex: Int = 1
public var installment: Int = 1
public var installmentID: UUID?
}
If data has been deleted from database, we need to check a date property to determine whether to re-fetch datas.
To do this, we added the preserveValueOnDeletion attribute to date property so we could retrieve it from the History tombstone value.
However, after adding this attribute, a crash occurs. There is a console log
Could not cast value of type 'Swift.ReferenceWritableKeyPath<Shared.ModelSchemaV5.Transaction, Foundation.Date>' (0x106bf8328) to 'Swift.PartialKeyPath<Shared.ModelSchemaV5.Spending>' (0x1094f21d8).
and error log attached
StrictMoneyChecking-2025-11-07-105108.txt
I also tried this in the recent SampleTrip app, and fetching all history after a deletion causes the same crash.
Is this issue currently being worked on or under investigation?
I am trying to save to cloud kit shared database. The shared database does not allow zones to be set up.
How do I save to sharedCloudDatabase without a zone?
private func addItem(recordType: String, name: String) {
let record = CKRecord(recordType: recordType)
record[Constances.field.name] = name as CKRecordValue
record[Constances.field.done] = false as CKRecordValue
record[Constances.field.priority] = 0 as CKRecordValue
CKContainer.default().sharedCloudDatabase.save(record) { [weak self] returnRecord, error in
if let error = error {
print("Error saving record: \(record[Constances.field.name] as? String ?? "No Name"): \n \(error)")
return
}
}
}
The following error message prints out:
Error saving record: Milk:
<CKError 0x15af87900: "Server Rejected Request" (15/2027); server message = "Default zone is not accessible in shared DB"; op = B085F7BA703D4A08; uuid = 87AEFB09-4386-4E43-81D7-971AAE8BA9E0; container ID = "iCloud.com.sfw-consulting.Family-List">
I'm writing some tests to confirm the behavior of my app. White creating a model actor to delete objects I realized that ModelContext.model(for:) does return objects that are deleted. I was able to reproduces this with this minimal test case:
@Model class Activity {
init() {}
}
struct MyLibraryTests {
let modelContainer = try! ModelContainer(
for: Activity.self,
configurations: ModelConfiguration(
isStoredInMemoryOnly: true
)
)
init() throws {
let context = ModelContext(modelContainer)
context.insert(Activity())
try context.save()
}
@Test func modelForIdAfterDelete() async throws {
let context = ModelContext(modelContainer)
let id = try context.fetch(FetchDescriptor<Activity>()).first!.id
context.delete(context.model(for: id) as! Activity)
try context.save()
let result = context.model(for: id) as? Activity
#expect(result == nil) // Expectation failed: (result → MyLibrary.Activity) == nil
}
@Test func fetchDescriptorAfterDelete() async throws {
let context = ModelContext(modelContainer)
let id = try context.fetch(FetchDescriptor<Activity>()).first!.id
context.delete(context.model(for: id) as! Activity)
try context.save()
let result = try context.fetch(
FetchDescriptor<Activity>(predicate: #Predicate { $0.id == id })
).first
#expect(result == nil)
}
}
Here I create a new context, insert an model and save it.
The test modelForIdAfterDelete does fail, as result still contains the deleted object.
I also tried to check #expect(result!.isDeleted), but it is also false.
With the second test I use a FetchDescriptor to retrieve the object by ID and it correctly returns nil.
Shouldn't both methods use a consistent behavior?
Greetings i have an app that uses three different SwiftData models and i want to know what is the best way to use the them accross the app. I though a centralized behaviour and i want to know if it a correct approach.First let's suppose that the first view of the app will load the three models using the @Enviroment that work with @Observation. Then to other views that add data to the swiftModels again with the @Environment. Another View that will use the swiftData models with graph and datas for average and min and max.Is this a corrent way? or i should use @Query in every view that i want and ModelContext when i add the data.
@Observable
class CentralizedDataModels {
var firstDataModel: [FirstDataModel] = []
var secondDataModel: [SecondDataModel] = []
var thirdDataModel: [ThirdDataModel] = []
let context: ModelContext
init(context:ModelContext) {
self.context = context
}
}
Hello,
I have 3 model versions and I'm trying to step through migration.
Version 2 makes significant changes to v1. As a result, I've renamed the entities in question by appending _v2 to their name, as the data isn't important to retain.
v3, remove's the appended version number from v2.
Setting the .xcdatamodeld to v3 and the migrations steps array as follows causes the app to error
[
NSLightweightMigrationStage([v1]),
NSLightweightMigrationStage([v2]),
NSLightweightMigrationStage([v3]),
]
CoreData: error: <NSPersistentStoreCoordinator: 0x10740d680>: Attempting recovery from error encountered during addPersistentStore: 0x10770f8a0 Error Domain=NSCocoaErrorDomain Code=134110 "An error occurred during persistent store migration."
An error occurred during persistent store migration. Cannot merge multiple root entity source tables into one destination entity root table.
I find this odd because if I run the migration independently across app launches, the migration appears to drop the no longer used tables in v2, then re-add them back in v3. So it seems to me that something is not finishing completely with the fully stepped through migration.
--
I'm also unable to understand how to use NSCustomMigrationStage I've tried setting it to migrate from v1, to v2, but I'm getting a crash with error
Duplicate version checksums across stages detected
My client is using iCloud Mail with his custom domain and he communicated with many govt organizations which seem to all be using Barracuda Email Protection for their spam prevention. I have properly configured his SPF, DKIM & DMARC DNS records however his emails were still being rejected. (Email header below)
I contacted Barracuda support with the email header and they replied saying that the emails were rejected becuase Apple Mail has missing PTR records.
I have sent dozens of emails for testing and looking at all their headers I can see (ms-asmtp-me-k8s.p00.prod.me.com [17.57.154.37]) which does not have a PTR record.
----FULL EMAIL HEADER WITH 3RD PARTY DOMAINS REMOVED-----
<recipient_email_address>: host
d329469a.ess.barracudanetworks.com[209.222.82.255] said: 550 permanent
failure for one or more recipients (recipient_email_address:blocked)
(in reply to end of DATA command)
Reporting-MTA: dns; p00-icloudmta-asmtp-us-west-3a-100-percent-10.p00-icloudmta-asmtp-vip.icloud-mail-production.svc.kube.us-west-3a.k8s.cloud.apple.com
X-Postfix-Queue-ID: 8979C18013F8
X-Postfix-Sender: rfc822; sender_email_address
Arrival-Date: Thu, 20 Mar 2025 12:30:05 +0000 (UTC)
Final-Recipient: rfc822; @******
Original-Recipient: rfc822;recipient_email_address
Action: failed
Status: 5.0.0
Remote-MTA: dns; d329469a.ess.barracudanetworks.com
Diagnostic-Code: smtp; 550 permanent failure for one or more recipients
(recipient_email_address:blocked)
Return-Path: <sender_email_address>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sender_domain;
s=sig1; bh=CyUt/U7mIHwXB5OQctPjRH/OxLH7GsLR54JjGuRkj9Y=;
h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To:x-icloud-hme;
b=hwEbggsctiCRlMlEgovBTjB/0sPRCb2k+1wzHRZ2dZNrZdOqvFSNWU+Aki9Bl8nfv
eEOoXz5qWxO2b2rEBl08lmRQ3hCyroayIn4keBRrgkxL1uu4zMTaDUHyau2vVnzC3h
ZmwQtQxiu7QvTS/Sp8jjJ/niOPSzlfhphqMxnQAZi/jmJGcZPadT8K+7+PhRllVnI+
TElJarN1ORQu+CaPGhEs9/F7AIcjJNemnVg1cude7EUuO9va8ou49oFExWTLt7YSMl
s+88hxxGu3GugD3eBnitzVo7s7/O9qkIbDUjk3w04/p/VOJ+35Mvi+v/zB9brpYwC1
B4dZP+AhwJDYA==
Received: from smtpclient.apple (ms-asmtp-me-k8s.p00.prod.me.com [17.57.154.37])
by p00-icloudmta-asmtp-us-west-3a-100-percent-10.p00-icloudmta-asmtp-vip.icloud-mail-production.svc.kube.us-west-3a.k8s.cloud.apple.com (Postfix) with ESMTPSA id 8979C18013F8;
Thu, 20 Mar 2025 12:30:05 +0000 (UTC)
From: Marcel Brunel <sender_email_address>
Message-Id: <2E8D69EA-FCA6-4F5D-9D42-22A955C073F6@sender_domain>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_F9AC7D29-8520-4B25-9362-950CB20ADEC5"
Mime-Version: 1.0 (Mac OS X Mail 16.0 (3826.400.131.1.6))
Subject: Re: [EXTERNAL] - Re: Brunel - 2024 taxes
Date: Thu, 20 Mar 2025 07:29:27 -0500
In-Reply-To: <SA0PR18MB350300DE7274C018F66EEA24F2D82@SA0PR18MB3503_namprd18_prod_outlook_com>
To: Troy Womack <recipient_email_address>
References: <SA0PR18MB350314D0B88E283C5C8E1BB6F2DE2@SA0PR18MB3503_namprd18_prod_outlook_com>
<9B337A3E-D373-48C5-816F-C1884BDA6F42@sender_domain>
<SA0PR18MB350341A7172E8632D018A910F2D82@SA0PR18MB3503_namprd18_prod_outlook_com>
<SA0PR18MB350300DE7274C018F66EEA24F2D82@SA0PR18MB3503_namprd18_prod_outlook_com>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
X-Proofpoint-ORIG-GUID: uqebp2OIbPqBr3dYsAxdFVkCNbM5Cxyl
X-Proofpoint-GUID: uqebp2OIbPqBr3dYsAxdFVkCNbM5Cxyl
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1093,Hydra:6.0.680,FMLib:17.12.68.34
definitions=2025-03-20_03,2025-03-19_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1030
suspectscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0
spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.19.0-2411120000 definitions=main-2503200077
Topic:
App & System Services
SubTopic:
iCloud & Data
Using SwiftData and this is the simplest example I could boil down:
@Model
final class Item {
var timestamp: Date
var tag: Tag?
init(timestamp: Date) {
self.timestamp = timestamp
}
}
@Model
final class Tag {
var timestamp: Date
init(timestamp: Date) {
self.timestamp = timestamp
}
}
Notice Tag has no reference to Item.
So if I create a bunch of items and set their Tag. Later on I add the ability to delete a Tag. Since I haven't added inverse relationship Item now references a tag that no longer exists so so I get these types of errors:
SwiftData/BackingData.swift:875: Fatal error: This model instance was invalidated because its backing data could no longer be found the store. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata://EEC1D410-F87E-4F1F-B82D-8F2153A0B23C/Tag/p1), implementation: SwiftData.PersistentIdentifierImplementation)
I think I understand now that I just need to add the item reference to Tag and SwiftData will nullify all Item references to that tag when a Tag is deleted.
But, the damage is already done. How can I iterate through all Items that referenced a deleted tag and set them to nil or to a placeholder Tag? Or how can I catch that error and fix it when it comes up?
The crash doesn't occur when loading an Item, only when accessing item.tag?.timestamp, in fact, item.tag?.id is still ok and doesn't crash since it doesn't have to load the backing data.
I've tried things like just looping through all items and setting tag to nil, but saving the model context fails because somewhere in there it still tries to validate the old value.
Thanks!
Hi all,
I have setup my app to use SwiftData with CloudKit sync. I have a production environment and development environment. I can reset the development environment for myself and all users in CloudKit console, but I can't reset the production one as it's tried to users' iCloud accounts, so I've added a button in-app for that feature. In the onboarding of my app, I pre-seed the DB with some default objects, which should be persisted between app install. The issue I'm running into is that I'm unable to force-pull these models from iCloud during the onboarding of a clean re-install, which leads to the models later appearing as duplicates once the user has been on the app for a few minutes and it has pulled from their iCloud account. If anyone has any suggestions on how to handle this issue, I would greatly appreciate it.
I am trying out the new AttributedString binding with SwiftUI’s TextEditor in iOS26. I need to save this to a Core Data database. Core Data has no AttributedString type, so I set the type of the field to “Transformable”, give it a custom class of NSAttributedString, and set the transformer to NSSecureUnarchiveFromData
When I try to save, I first convert the Swift AttributedString to NSAttributedString, and then save the context. Unfortunately I get this error when saving the context, and the save isn't persisted:
CoreData: error: SQLCore dispatchRequest: exception handling request: <NSSQLSaveChangesRequestContext: 0x600003721140> , <shared NSSecureUnarchiveFromData transformer> threw while encoding a value. with userInfo of (null)
Here's the code that tries to save the attributed string:
struct AttributedDetailView: View {
@ObservedObject var item: Item
@State private var notesText = AttributedString()
var body: some View {
VStack {
TextEditor(text: $notesText)
.padding()
.onChange(of: notesText) {
item.attributedString = NSAttributedString(notesText)
}
}
.onAppear {
if let nsattributed = item.attributedString {
notesText = AttributedString(nsattributed)
} else {
notesText = ""
}
}
.task {
item.attributedString = NSAttributedString(notesText)
do {
try item.managedObjectContext?.save()
} catch {
print("core data save error = \(error)")
}
}
}
}
This is the attribute setup in the Core Data model editor:
Is there a workaround for this?
I filed FB17943846 if someone can take a look.
Thanks.
I would like to have a SwiftData predicate that filters against an array of PersistentIdentifiers.
A trivial use case could filtering Posts by one or more Categories. This sounds like something that must be trivial to do.
When doing the following, however:
let categoryIds: [PersistentIdentifier] = categoryFilter.map { $0.id }
let pred = #Predicate<Post> {
if let catId = $0.category?.persistentModelID {
return categoryIds.contains(catId)
} else {
return false
}
}
The code compiles, but produces the following runtime exception (XCode 26 beta, iOS 26 simulator):
'NSInvalidArgumentException', reason: 'unimplemented SQL generation for predicate : (TERNARY(item != nil, item, nil) IN {}) (bad LHS)'
Strangely, the same code works if the array to filter against is an array of a primitive type, e.g. String or Int.
What is going wrong here and what could be a possible workaround?
I currently have a schema in production (cloudKit and local files) containing non-optional transformable values, e.g.
@Attribute(.transformable(by: TestTransformer.self))
var number: TestTransformable = TestTransformable.init(value: 100)
Unfortunately, this is preventing any migration from succeeding (documented at length in FB22151570).
Briefly summarized, any migration from a Schema containing non-optional transformable values fails between willMigrate and didMigrate with the error "Can't find model for source store". This occurs for all migrations, including lightweight with a migration plan, lightweight without a plan, and custom migrations. Worst of all, this also prevents migration to optional transformable values, or the elimination of the transformable value entirely, leaving us completely stuck.
(note: optional transformable values only work when they have a default value set to nil, otherwise even these have issues migrating)
We already have features being blocked by this issue, and would like to preserve user-data while restoring our ability to move forwards with database.
Are there any known workarounds for using SwiftData (+CloudKit) when schema migration is non-operational?
Hi. I am having this error when trying to write to CloudKit public database.
<CKError 0x600000dbc4e0: "Permission Failure" (10/2007); server message = "Invalid bundle ID for container";
On app launch, I check for account status and ensure that the correct bundle identifier and container is being used. When the account status is checked, I do get the correct bundle id and container id printed in the console but trying to read or write to the container would throw that "Invalid bundle ID for container" error.
private init() {
container = CKContainer.default()
publicDB = container.publicCloudDatabase
// Check iCloud account status
checkAccountStatus()
}
func checkAccountStatus() {
print("🔍 CloudKit Debug:")
print("🔍 Bundle identifier from app: (Bundle.main.bundleIdentifier ?? "unknown")")
print("🔍 Container identifier: (container.containerIdentifier ?? "unknown")")
container.accountStatus { [weak self] status, error in
DispatchQueue.main.async {
switch status {
case .available:
self?.isSignedIn = true
self?.fetchUserID()
case .noAccount, .restricted, .couldNotDetermine:
self?.isSignedIn = false
self?.errorMessage = "Please sign in to iCloud in Settings to use this app."
default:
self?.isSignedIn = false
self?.errorMessage = "Unknown iCloud account status."
}
print("User is signed into iCloud: \(self?.isSignedIn ?? false)")
print("Account status: \(status.rawValue)")
}
}
}
I have tried:
Creating a new container
Unselecting and selecting the container in signing & capabilities
Unselecting and selecting the container in App ID Configuration
I used to have swift data models in my code and read that swift data is not compatible with CloudKit public data so I removed all the models and any swift data codes and only uses CloudKit public database.
let savedRecord = try await publicDB.save(record)
Nothing seems to work. If anyone could help please?
Rgds,
Hans
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags:
CloudKit
Cloud and Local Storage
CloudKit Console
Hello,
I recently published an app that uses Swift Data as its primary data storage. The app uses concurrency, background threads, async await, and BLE communication.
Sadly, I see my app incurs many fringe crashes, involving EXC_BAD_ACCESS, KERN_INVALID_ADDRESS, EXC_BREAKPOINT, etc.
I followed these guidelines:
One ModelContainer that is stored as a global variable and used throughout.
ModelContexts are created separately for each task, changes are saved manually, and models are not passed around.
Threads with different ModelContexts might manipulate and/or read the same data simultaneously.
I was under the impression this meets the usage requirements.
I suspect perhaps the issue lies in my usage of contexts in a single await function, that might be paused and resumed on a different thread (although same execution path). Is that the case? If so, how should SwiftData be used in async scopes?
Is there anything else particularly wrong in my approach?
About 4 months ago, I shipped the first version of my app with 4 versioned schemas that, unintentionally, had the same versionIdentifier of 1.2.0 in 2 of them:
V1: 1.0.0
V2: 1.1.0
V3: 1.2.0
V4: 1.2.0
They are ordered correctly in the MigrationPlan, and they are all lightweight.
Migration works, SwiftData doesn't crash on init and I haven't encountered any issues related to this. The app syncs with iCloud.
Questions, preferable for anybody with knowledge of SwiftData internals:
What will break in SwiftData when there are 2 duplicate numbers?
Not that I would expect it to be safe, but does it happen to be safe to ship an update that changes V4's version to 1.3.0, what was originally intended?
Topic:
App & System Services
SubTopic:
iCloud & Data
When creating a new project in Xcode 26, the default for defaultIsolation is MainActor.
Core Data creates classes for each entity using code gen, but now those classes are also internally marked as MainActor, which causes issues when accessing managed object from a background thread like this.
Is there a way to fix this warning or should Xcode actually mark these auto generated classes as nonisolated to make this better? Filed as FB13840800.
nonisolated
struct BackgroundDataHandler {
@concurrent
func saveItem() async throws {
let context = await PersistenceController.shared.container.newBackgroundContext()
try await context.perform {
let newGame = Item(context: context)
newGame.timestamp = Date.now // Main actor-isolated property 'timestamp' can not be mutated from a nonisolated context; this is an error in the Swift 6 language mode
try context.save()
}
}
}
Turning code gen off inside the model and creating it manually, with the nonisolated keyword, gets rid of the warning and still works fine. So I guess the auto generated class could adopt this as well?
public import Foundation
public import CoreData
public typealias ItemCoreDataClassSet = NSSet
@objc(Item)
nonisolated
public class Item: NSManagedObject {
}
Is there a way to view the data saved when using swiftdata? Even after deleting all models, the storage space taken up by the app in Settings is too large.
Hi,
I am experiencing main thread freezes from fetching on Main Actor. Attempting to move the function to a background thread, but whenever I reference the TestModel in a nonisolated context or in another model actor, I get this warning:
Main actor-isolated conformance of 'TestModel' to 'PersistentModel' cannot be used in actor-isolated context; this is an error in the Swift 6 language mode
Is there a way to do this correctly?
Recreation, warning on line 13:
class TestModel {
var property: Bool = true
init() {}
}
struct SendableTestModel: Sendable {
let property: Bool
}
@ModelActor
actor BackgroundActor {
func fetch() throws -> [SendableTestModel] {
try modelContext.fetch(FetchDescriptor<TestModel>()).map { SendableTestModel(property: $0.property) }
}
}
If use a SortDescriptor for a model and sort by some attribute from a relationship, in DEBUG mode it all works fine and sorts. However, in release mode, it is an instant crash.
SortDescriptor(.name, order: .reverse) ---- works
SortDescriptor(.assignedUser?.name, order: .reverse) ---- works in debug but crash in release.
What is the issue here, is it that SwiftData just incompetent to do this?