Continue using NSManagedObject types but migrate off Core Data

I am working with a massive, existing code base that uses Core Data.

I have types that extend NSManagedObject and are persisted in Core Data.

I need to migrate off of Core Data entirely (the reasons for this don't matter, but I have good reasons). However, I have a fundamental constraint.

I cannot change these types to NSObject (some use cases must continue using Core Data).
These NSManagedObject types are heavily passed around my business logic. I don't want to refactor that business logic and introduced a new/"unmanaged" type.

Let's say I have some type Foo that's an NSManagedObject. I tried something like:

Foo *foo = [[Foo alloc] init];
foo.name = "beebunny";

The foo.name call causes a crash.

name is @dynamic and has a custom set method, something like:

- (void)setFoo:(Foo *)fooIn
{
    [self setFoo:fooIn];
}

The [self setFoo:fooIn]; call causes an exception (unknown selector).

It seems like I have to use Core Data if I'm working with any type that extends NSManagedObject.

Is there a proper/recommended pattern for the type of migration I'm wanting to perform off of Core Data?

Solution

Instances of NSManagedObject depend very heavily on the data model. You don't have to save the instances with Core Data, but they must have a data model backing them up or they won't work. Your [[Foo alloc] init] doesn't work because (a) it doesn't use a designated initializer, and (b) it doesn't have a data model supporting it.

You can create instances that you don't save. For example you can use -initWithEntity:insertIntoManagedObjectContext: to create an instance, but have the context argument be NULL. It'll never be saved unless you insert it, but it sounds like you won't do that. But that initializer requires an NSEntityDescription, and you need to get that from a managed object model. (You can also create them in code, but that's not going to make it easier or remove the need to import Core Data into your code).

In short, you don't have to save these objects to Core Data, but you do need to have some Core Data support if you'll still be subclassing NSManagedObject. You can't use those classes independently of the data model.