1
votes

I've just started working on an app that uses UIManagedDocument for persistence. As far as I can tell, the only reason UIManagedDocument was used was to take advantage of it automatically setting up a core data stack.

Now, I need to change the data model to implement some new features. The changes to the data model are going to be drastic, and I'm thinking about switching away from UIManagedDocument to a normal core data stack. I've been reading a lot about core data migrations and UIManagedDocument, but to go from UIManagedDocument to a normal CoreData stack, it looks like I'll have to write a class that would migrate the data? I'm just wondering what the best/safest way to do this is.

1

1 Answers

0
votes

What migration(s) you need depend only on how the data model changes. Moving from a stack created by UIManagedDocument to one that you create should have no significance as far as data migration goes. If there were multiple documents, you'd have to figure out how you wanted to handle that, but if UIManagedDocument was used solely to avoid writing boilerplate stack setup code, that's not an issue.

Since you describe the model changes as "drastic", you'll have to look into configuring the migration. You might just need a custom mapping model, or you might need to go for full custom migration code. It really depends on the details of how the model is changing.