Forget about abstract classes in Objective-C (there are none). Forget about protocols in connection with class hierarchy.

A protocol describes a set of methods that an object needs to implement to be usable for some purposes. For example, if a protocol has two required methods "color" and "setColor", then any instance of any class implementing these two methods can be used. In addition, the class must claim that it supports the protocol - this avoids a class being used by coincidence. On the other hand, all methods in a protocol could be optional and a class could claim to support the protocol without implementing any of the methods.

There will usually be a description of what happens when optional methods are not implemented. For example, the documentation for an optional method returning BOOL might say "if not implemented, it is assumed that the method returns YES". In other cases the documentation might say under which circumstances an optional method will be called. In any case, the caller must check that an optional method is implemented before calling it using "respondsToSelector". (Of course, the documentation might say for example that if wantsComplexBehaviour returns YES, then doComplexBehaviour1 and doComplexThings2 must be implemented, and not implementing that would be a programmer error punished with an exception when the methods get called).

This is usually all done in a very pragmatic way. Many classes that you use need delegate objects which implement some protocol, so you either add the protocol methods to your implementation and make yourself the delegate, or you create a class for the sole purpose of creating these delegates and implement all the protocol methods in the implementation of that class.