I did some research and understand the basic issue. My question here is on strategy.
Background: I submitted an app designed to help soccer coaches manage their lineups. It got rejected for reason 2.23: On launch, it creates default core data entities for positions and formations. It also creates an example team for new users to step through as a tutorial. These entities are all stored in the persistent store in the app's documents directory, which gets backed up to iCloud automatically. They say it was 4MB of data--I was only able to recreate 60kB, which sounds right--either way, Apple doesn't want default data going to iCloud, hence the rejection.
Issue: The fix is to exclude the default data from backup with the NSURLIsExcludedFromBackupKey. That leaves me two choices:
-- Easy choice: On first launch, just set NSURLIsExcludedFromBackupKey for the app's documents directory to YES. Then, after the user enters any of their own data, set it to NO, and use an NSUserDefault to maintain that setting on subsequent launches. This would let me keep everything in one persistent store, although the default data would be backed up at that point... which technically still busts the rules, I guess. But with such a small amount of default data, is Apple going to catch it? Or care?
-- Hard choice: Use two persistent stores, one for default data that is excluded from backup and one for user-entered data that isn't, and implement fetched properties to merge the data for the app to run. Probably the "right" answer but it sounds like a pain and I really want to avoid learning how to do this and reworking my data model and all my fetches.
So before I gamble another week of review time, any thoughts on whether the easy approach will work? Or any other ideas?
Well, I took a chance on the easy approach... and it worked! The app was approved on resubmission. Again, I suspect the minuscule size of the seed data probably helped. If that data was big enough to have a significant impact on a user's iCloud storage, I would have felt an ethical obligation to take the hard approach with multiple persistent stores.