NattyNarwhal
commented
1 year ago My notes after trying (and failing) to do this within an hour:
These classes have no actual real code beyond their Core Data stubs and can probably be switched to fully generated:
SBDownloads (resources)
SBNowPlaying
SBHome
SBArtist
SBGroup
SBIndex
SBLibrary (resources)
SBPlaylist (resources)
SBResource
SBSection
SBTracklist (resources)The indices are weird and trigger a bug if built with Xcode 9+ mode, see https://stackoverflow.com/questions/44386614/ios-cant-compile-coredata-model-because-of-fetched-indexes-in-xcode-9 or https://developer.apple.com/forums/thread/130928 - switch tools version to 8
Xcode seems to have massively changed how it generates the code - we'd get an SBClass+CoreDataClass and SBClass+CoreDataProperties (and a .h if in Objective-C) per https://developer.apple.com/documentation/coredata/modeling_data/generating_code
The previous style used today is that the concrete class (SBClass) inherits from the "abstract" class (_SBClass) holding the boilerplate for Core Data. The new style has you inherit directly from your parent/NSManagedObject and the Core Data sludge is a category/extension.
Mixing and matching Swift and Objective-C is fraught with problems (can't inherit from a Swift class in ObjC, forward declarations are hellish). Stick with ObjC codegen until all models are Swift.
Even in ObjC, it's unclear how to convert these to the modern style of generation. How much renaming do we have to do?
Right now I have to edit these manually when I change the model, which seems a little strange, since the files I'm modifying mention the fact they were generated. I'm guessing after many Xcode jumps this broke.