Short answer:
No, this is optional.
Long answer:
Objective-C is a dynamic collection, a late binding programming language. In short form, this means that a solution of any type can be executed at runtime instead of compilation time, and you can access the properties and send messages to the object without knowing its type (class).
But there is no need for the main database, and you, as a user of Core Data and your model, know the type of managed object for the type of entity. There is also no need to have a specific type for an object type. (I don't generate classes very often, and if so, I do it manually). Therefore, unlike other programming languages, these generated classes are not needed to give the compiler a type.
However, the compiler wants to see at least every method at least once in order to get a signature (input of parameters). Otherwise, it would warn. It’s even possible to have working code like this ...
NSManagedObject *person = … NSString *firstName = [person firstName];
... for the entity type Person with the firstName property, the compiler will warn you that it does not know anything about the –firstName method.
Instead, you can enter something like this:
NSManagedObject *person = … NSString *firstName = [person valueForKey:@"firstName"];
(The compiler knows -valueForKey: since this is a method declared in NSObject .)
In addition, you get benefits such as code completion, error checking, etc. But you do not need to use the Xcode code generation tool. Just declare such a class and properties in the interface. Accessors can be dynamically generated using @dynamic . (Personally, I almost never use static code generation.)
Edit: Added discussion result in comments.
Thus, having an interface (".h-file") category, the compiler knows enough to compile all the code without warning. This will work at run time if it is guaranteed - or checked at run time - that you can send the appropriate message. This makes sense in many situations from the start of Objective-C, i. e. for forwarding and informal protocols. In the context of Core Data, it is used to dynamically create standard access methods. Everything works fine without any implementation.
However, for some reason, you need to have an implementation, i.e. e. housekeeping with a change in value. In this case, it is useful to have a stub implementation that you can edit. But for standard behavior this is not necessary.