Inheritance is something you use when it makes sense to do so.
Using your example:
Class Console - Inherits from NSObject
Class Nintendo Console - Inherits from Console
Class Sega Console - Inherits from Console
You first have to decide what Console does, and what it will have for methods and properties. If something is common to all subclasses, then put it in Console and inherit it. If something isn't common, then don't put it in Console. I have no clear idea what you intend these classes to do, so I can't offer specific suggestions about inheritance.
A better example might be NSArray and its mutable subclass NSMutableArray. Or any other pair of immutable class and mutable subclass, such as NSData, NSString, etc. and their mutable counterparts.
The design relationship is pretty clear: a mutable NSMutableArray should be capable of everything its immutable superclass can do, plus the mutable subclass should be mutable. Since this is the clear intended relationship, it simply makes sense to use inheritance.
Thinking it through is the essence of software design. If using a feature makes sense for the design, use it. If it doesn't make sense, don't use it.
In my experience, having a clear design before starting to assign classes and inheritance will make the classes and their relationships clear. They should grow out of the design, not be pushed into the design.
Without a clear design, you get incomprehensible parts stitched together like a crazed combination of grain sack, circus tent, sailboat sail, and ballroom gown, where the only commonality is they're made of fabric and they have seams.