Hello, I just redownloaded the sample project this morning. It's now updated to use the new Observation and builds without failure. But I'm still having issues with Assert line 204 during reconstruction. Xcode: Version 15.0 beta 8 (15A5229m) iPhone 12 Pro Max - iOS 17.0 (21A5291h)

Thank you Ziqiao. I had filed a feedback but thought there could be a quicker response here to get it to the correct team. Please feel free to reach out for any further questions. Feedback: FB16214848 (CKShare Fails with quotaExceeded Error on Family iCloud Plan)

Doesn't appear to work on simulator. Use a device

The system effectively merges all of your asset packs into a single directory hierarchy. You can think of it as your app’s single, shared asset-pack namespace. The system expects that every individual file have a relative path from the root of that shared namespace that’s unique across all of your app’s asset packs (though not necessarily across multiple apps). An asset pack’s ID is not part of the unique path, but every other path component is. In your case, Foo/10/239/414.png and Bar/10/239/414.png are distinct paths that shouldn’t collide. This is also what I suspected from observation. That also actually works out great for something like map tiles, unless there are duplicate files. I would much prefer to just list the images as z/x/y.png, but duplicates appear to resolve in an error. I suspect that you’re testing your app on OS 26, not OS 26.1. There’s a known issue with AssetPackManager.url(for:) in OS 26 that we fixed in OS 26.1 beta I was testing with 26.0.1. I'll upgrade and give it a go! Thank you for the quick reply!

Hi Albert, To be fair the Developer Support Team completely missed the mark on what I was asking and referred me to a code signing guide. If you could kindly help guide the query to the appropriate team, that would be very helpful. Thank you, Tanner

This is still an issue with 26.1 Beta 3

This is also still an issue with 26.1 Beta 4

To test with Xcode you have to run a local server. https://developer.apple.com/documentation/backgroundassets/testing-asset-packs-locally

Thank you for those detailed answers!

Can we please update the alert message to clarify that? All versions of this asset will no longer be accessible by your app. Is not clear

Unfortunately I don't know what the cause is. It happened a few times around the time I posted this thread, but I haven't seen it happen since.

There was a few issues here. None of which are documented very well. And all crash with the same error message. (1) My orginal .xcdatamodel file didn't have a Core Data Model Identifier. Which lead to a crash with NSCustomMigrationStage, even though the versionChecksum are different. (2) The steps passed into NSStagedMigrationManager are not clear or documented. But it appears that if you pass the first version of the model into the steps, it crashes. (3) I'm using manual code generation for the model classes. So my goal was to switch the model names, then switch them back, so I didn't have to change anything. For some reason, stepping through the one migration step per app launch instead of all at once allowed for a successful migration. But running all steps threw an error. Turns out I could just rename the model classes with the _v2 suffix, and the only thing I needed to update was the string in the fetch request. Overall, to resolve this I added a model version identifier I duplicated the model version and incremented the model version identifier Deleted the final migration step that removed the entity versioning

None of the steps are using NSLightweightMigrationStage and they are all NSCustomMigrationStage. I ended up just adding a version to the end of the entity.

Further, I archived this Asset Pack in the Test Flight section for App B, but the Asset Pack was in production for App A. If an Asset Pack is in production, it shouldn't have the option to be archived from the Test Flight section.

After thinking about this some more, I'm not sure reading a store directly from the asset pack will solve my issue. The database get's updated regularly, so if there's an update that finishes downloading while the app is running, the original linked store will be destroyed and replaced with the new one. Which probably will crash the app.