The Xcode generated NSManagedObject subclasses are annoying me. While they generate as a pair of files where you can add things to the main class and the @NSManaged variables are generated in an extension in a separate file so that they can be be overwritten and replaced as the model is updated without affecting the file where you make your changes unfortunately there is a big deficiency from my point of view in that the model type information does not get fully carried through to the Swift objects.
Insufficiently Typed
There are two generation options, with "Use scalar properties for primitive data types" you get usefully typed integers, floats, doubles and bools but lose the expression to express optionals/nil values. This is presumably due to the limitations of the Objective-C based API. It also expresses date types as NSTimeIntervals (Doubles) rather than NSDates. The other option will generate with objects so you will get NSDates but for number values and Booleans you will get NSNumbers which lose information about whether it is a floating point type, integer or boolean.
Other Issues
Other Core Data issues can largely be worked around or mitigated by adding protocols and methods to provide convienient fetch methods and other utility methods so I don't yet think code generation is required for them.
MyDataModel.xcdatamodeld
The Core Data model file is actually a very simple XML file and parsing it is relatively straightforward. I've written a quick (but brittle so far) parser using NSXMLParser. This means that I can easily get at the key information (Entities, Attributes and the relationships) to generate the code I need. The XML file itself is hidden within a small directory structure like this: MyDataModel.xcdatamodeld/MyDataModel.xcdatamodel/contents
What Code to Generate?
There are three main options that I'm considering. I don't yet feel that I am a Core Data expert so I would very much welcome any help or advice about whether there are any issues that I haven't considered
1. Replace the Xcode Generated Files Completely
In this option I would replace the Xcode generated extension with my own. Instead of @NSManaged properties I think the generated file would include computed properties using the key value coding calls on the superclass (NSManagedObject) to actually set the real properties. I think that this is my preferred option but there may be an issue that I've missed.
2. Extend with additional computed properties
In this option the Xcode generated file would still exist and the generated files would further extend it with computed properties that then called through to the @NSManaged variables in the Xcode generated extension. The downside here is having to ensure that the varible names don't collide which I think would make it too messy.
3. Generate Additional Class
Do the normal Xcode generation and have my generator create a separate class that contains/wraps the NSManagedObject subclass and passes the calls through to the real NSManagedObject. This would probably require more boilerplate code to sufficiently expose the underlying NSManagedObject but it would allow the some of the NSManagedObject details to be somewhat hidden. This could probably be a good approach but would mean major changes to existing code and could be a lot of upfront work so I don't think it is the right way to go at this moment.
My current feeling is that (1) is the right way to go. I don't want to do too much to hide the essential nature of the NSManagedObject until I have a full design for how it should work and I don't want to be presenting variables in different forms and dealing with naming clashes.
As mentioned, advice and suggestions welcomed.