I had actually had this same discussion with basher when he proposed the original changes from just yk_JSON to yk_JSONString and yk_JSONObject, since i think there can be some confusion.

yk_JSONObject's intended function is to parse out a string and give you an object representation, but yk_JSONString's intended function is to take an object (and not a string) and return a string representation.  All strings are not valid JSON.  I.e. @"Some string" is obviously not valid.  If you want to check that a string is valid JSON, then you should do yk_JSONObject, which will return an object representation or nil if it is not valid JSON.  

The reason I have decided to draw the boundary like that is that I think there might be an implication (as you thought) that if I give yk_JSONString a string it should be able to give me back a JSON representation of that string, but what happens when I don't give yk_JSONString a valid string?  And why would you want to produce a NOOP on a JSON string in the first place?  So the reason why all strings return nil is because some strings are JSON and some aren't, and if you want to figure that out then use yk_JSONObject. Otherwise [@"Some String" yk_JSONString] would first try and parse this string as JSON (which is what yk_JSONObject already does), and if it is not JSON it would convert it to JSON by simply wrapping it as @"['Some String']"? or would it return nil in that case?  To eliminate confusion, yk_JSONString does not operate on strings, it operates on object representations only.