That strikes me as a good example of where the kinds of features JetBrains is known for don't really mesh with Objective-C.
If doSomethingElse is a method defined in a category I expect to be loaded at runtime, or something I expect to be caught by foo's forwardInvocation method, having it turn red and bug me to provide an implementation in Foo is exactly the wrong thing to do.
It's the kind of little feature that really only makes sense in the context of a static language like C#, where a method call without a corresponding method implementation can be known definitively to be an error.
That's interesting but I'm confident in JetBrains getting this kind of detail right. I don't have appCode in front of me but I'm sure they'll implement something to handle it. They go to great lengths to understand your entire codebase including any libraries/sdks you might link with.
They've had to do similar things already with Javascript, Ruby, etc. Even Java has similar issues - for example you can use reflection to call methods. So it may mark a method as not being used in your project. But for 99% of cases it gets it right.
GCC would give a warning if you tried to compile this, and Xcode 4 would highlight the offending line with a yellow bubble. appCode's behavior doesn't seem too inappropriate in this case.
If doSomethingElse is a method defined in a category I expect to be loaded at runtime, or something I expect to be caught by foo's forwardInvocation method, having it turn red and bug me to provide an implementation in Foo is exactly the wrong thing to do.
It's the kind of little feature that really only makes sense in the context of a static language like C#, where a method call without a corresponding method implementation can be known definitively to be an error.