I have own static library that include Reachability for checking internet connection.
I use Reachability 2.2 version in my static library http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html
Other developer added my static library to his(3rd party project) which already has other Reachability (tag 3.0 in Pod's spec)
He installed it through Cocoa Pods. see the spec.
As you see, this is last version in pods.
Ok, project was builded without errors.
BUT we got error:
+[Reachability reachabilityWithHostName:]: unrecognized selector sent to class 0x2c77fc
I spent lot of time to find out the issue.
So Reachability 2.2 has declaration:
+ (Reachability*) reachabilityWithHostName: (NSString*) hostName;
But, Reachability 3.0 has following declaration:
+(Reachability*)reachabilityWithHostname:(NSString*)hostname;
Is it different?! Compiling was successful! Look at "HostName"... yeap, small "n". And when we check host reachability inside static library we get unrecognized selector.
My question is - what best way to avoid this issue? Should I force other developers who want to build my static library use Apple's Reachability or something else?
Thanks
I know this is WAY late, but its a problem I also face, as I am sure anyone else who is trying to build a redistributable library.
There isn't a "best way" to avoid this issue unfortunately, but there are ways to do it, just depends on your use case.
A low-tech, possibly high maintenance and effort way is to rename all of the classes in all of the pods you use. By giving all of the classes a unique prefix, you almost guarantee that your "customers" integrating your static lib will not use the same name, and specifically in your case, if they use pods, then the will not have the same class names, avoiding the conflict.
Other methods would involve post compilation class name munging which would be more maintainable, but required deeper technical knowledge in how to do such a thing to an object file and linker mapping. Sorry, i don't have this productized yet!
Hopefully I am not overlooking a more simple and elegant solution, but this is where I am at.