Possible to hide method implementation in library?

Question

I'd like to know if it is possible to hide library implementation from consumers of a static library.

This great thread spawned a few questions in regards to a licensing system for static libraries: http://stackoverflow.com/questions/1739373/licensing-system-for-static-library. The scheme I'd like to use is:

• Give consumer a license key they put into a plist
• plist is deployed
• strong key is generated off of bundle identifier and matched against key in plist

Here is why that system is flawed: I need to run an algorithm (for strong key generation on the fly) that then outputs some string. The problem is I must include header files for the library to be used. At this point, anyone using the library can step into implementations. If I have a method named checkLicense(), a consumer of the library can step into that method and see how the strong key is being generated.

Also, for static methods, am I to run the key generation every time since there isn't any state? I could probably use a singleton and call it in each static method call?

My main problem is that implementation can be seen within a static library if you have the header files. Is there some way of hiding implementation?

Answer 1

Assuming this static library you are creating is written in Objective-C, one method you could use is to create an anonymous category of your class in your implementation file (not your header). In that category, declare your sensitive methods and then just implement them in your class like normal. This makes it so you don't have to expose those methods in your public headers.

For example, in SomeClass.m:

@interface SomeClass (/*Secret stuff*/)
- (BOOL)validateRegistration:(NSData *)key;
@end


@implementation SomeClass

// Other methods....

- (BOOL)validateRegistration:(NSData *)key { /* ... */ }

@end

Notice that this is an anonymous category because I haven't given the category a name (that's just a comment inside the parentheses). This makes it so you don't have to declare a separate implementation block specifically for that category's implementation, which helps hide those methods a little further.