I found something interesting. In the demo I uploaded, if MigrationPlan is enabled when the version is updated, an error will always be reported. If MigrationPlan is not used when ModelCotainer is initialized, no matter how the Model is modified between different versions, no error will be reported. So I deleted MigrationPlan in my App and uploaded it to TestFlight. Unfortunately, the error of SwiftData.SwiftDataError._Error.loadIssueModelContainer appeared.

Hello, first of all, thank you for your reply. The headache of this problem is that it cannot be reproduced in Xcode. However, I seem to have found some clues recently. In enum MeSchemaV5: VersionedSchema { ... } , I listed all the Model definition codes. But outside this enum, I also defined all the Models (all the codes are exactly the same), and did not use typealias to specify the Model. I guess it may be due to this reason that when the ModelContainer is initialized, the Model of the schema all points to the Model outside the enum, and the Model corresponding to SchemaV5 is not found during the execution of MigraitonPlan, so the error "Error.loadIssueModelContainer" is reported. I tried to delete the Model definition code outside the enum and use typealias to specify the corresponding Model. typealias HealthDataList = MeSchemaV5.HealthDataList typealias HealthDataStatistics = MeSchemaV5.HealthDataStatistics typealias HeartZoneData = MeSchemaV5.HeartZoneData typealias UserSettingTypeFor = MeSchemaV5.UserSettingTypeFor typealias SleepDataSource = MeSchemaV5.SleepDataSource ... The problem seems to have improved. Most of the time, the migration operation can be completed normally without crashes. However, there are still a small number of users who report that "Error.loadIssueModelContainer" sometimes appears. But I'm not sure if it is related to this. At the same time, I don't know if you can provide a sample code on how to use MigraitonPlan correctly. There is really little content in the official documentation for this area. I hope to get your help to learn how to use MigraitonPlan correctly, as well as some related precautions. In addition, I have never encountered the error you mentioned, "error: Attempting to retrieve an NSManagedObjectModel version checksum while the model is still editable. This may result in an unstable verison checksum. Add model to NSPersistentStoreCoordinator and try again.". However, when I initialized ModelContainer using the new method, this error appeared and can be reproduced in Xcode. How do I submit a feedback report? Finally, thank you again for your help.

Thank you for sharing this article — it directly touches on the issue I’m currently facing. I have actually tried both approaches mentioned: 1.Using .distanceWalkingRunning or .distanceCycling samples to accumulate distance and determine per-kilometer (or per-mile) ranges. This is a reasonable suggestion, but it comes with a major drawback. For example, processing a 100 km cycling workout produces a very large number of samples, and the overhead becomes even greater when handling multiple workouts in bulk. In other words, this method is valid but not efficient. 2.As edorphy pointed out, Apple Watch’s Activity app does record per-kilometer and per-mile split points as HKWorkoutEvents. In my own testing, these event markers are actually more accurate than the splits derived from accumulating .distanceWalkingRunning or .distanceCycling samples. This leads to a simple but important question: how can developers make effective use of the HKWorkoutEvents that Apple Watch already records and stores in HealthKit? In other words, is there a way to reliably distinguish these events — even when they sometimes overlap — so that they can be used as accurate split markers? I strongly believe that the iOS Fitness app is not inefficiently recalculating splits by iterating through every distance sample. There must be a more optimal solution. I would greatly appreciate more professional guidance on this point, and I believe a clear answer here could benefit many HealthKit developers who want to implement split statistics more efficiently.