In all honesty I'm not sure what its supposed to provide protection against. I think they just wan't to force a circle into a square hole. The Client as far as I'm aware are all C# junkies, and its considered good practice to seal classes and methods you don't want to be modified to protect them.
I thought it might be something like that.
Some things come to mind:
First, there are some easy things you can do on the "protection" front, such as use of @private for any/all ivars that don't need to be visible. Obj-C has no such visibility controls for methods, so don't bother with that.
Second, if it's an issue of published vs. unpublished API (not the same as public vs. non-public API), you can put the published API in the YourClass.h file, then define a protocol (YourUnpublishedMethods.h) or a category (YourClass+UnpublishedMethods.h). The implementation of YourClass.m then implements the protocol, if defined that way, or YourClass+UnpublishedMethods.m implements the category. Just remember that this is NOT a private or protected interface. Anyone who knows the method selector and can figure out the types can send a message. Or you can get selector names using a simple 'nm' command on the binary. It's even possible to figure this stuff out using reflection on an instance at runtime, and then invoke it or log the info for later use.
Third, try explaining to them the reason Objective-C doesn't have some of this stuff, and the reason it's so hard to make it act as if it does, is because Objective-C is a dynamic (late-binding) language, where Java, C#, and others are static (early-binding) languages. "Best practice" depends on the language and its design. The compiler is responsible for more things in static binding, and the runtime either assumes the compiler is correct (potential security issue), or the runtime does the additional checks every time (potential performance lossage). It's not hard to trick the Java compiler into compiling code that doesn't match what the runtime runs with (e.g. a virtual dispatch instead of a non-virtual one), and exciting things will happen at runtime. Depending on the runtime environment's settings, this may or may not cause a runtime error.
