I know this thread is old, but I just ran into this and thought I'd leave this here for future googlers. I'm really using cocos2d-x, so mostly writing C++, but it's the same issue biting me. I named a file Block.h. It's for blocks. Like in a game. That has blocks, among other thing. No big deal, blocks are a time honored concept in video games, right?
It worked fine for several days. My blocks blocked things. Then I was trying to add an external library and needed to add a header search path. Poof. Several hundred errors before I even tried to #include anything from it. "That's odd, it must have some conflicting header in it." Take search path back out, everything builds again. After trying a couple of things and always getting the same errors, I added an empty directory, completely empty, to my header search path, and got the same issue. WTF! It would still work fine if I put the header search paths back the way they were. So I spent some time googling "too many header search paths xcode" and the like and found nothing. Then I tried just changing the order of my existing search paths and it all broke again.
Eventually I got down into manually deleting all the shared cached precompiled headers. That finally broke it consistently everywhere, even with my original configuration. Progress!
At some point, I managed to get an error out of it that showed Prefix.pch was the file being compiled when I actually had problems. Still no "Block.h" apparent. But I added a syntax error to another header it was telling me about a random name conflict from (which there was no reason for it to be grabbing from Prefix.pch!) and finally got a header path showing my Block.h being included from the system CFBase.h. Crazy! It's not even in any of my search paths, it's in a subdirectory of my project and I don't have recursive searching turned on for anything, but it's doing so anyway.
The reason it worked for me for a while when I first added that file must be that it never thought it needed to rebuild the precompiled header when I first added it (which ought to be true), so I was happily building with an old pch cache that had the correct system Block.h in it. Only when I changed something (adding a header search path) that required a new PCH to be built did everything blow up. And the caching of PCHs was "smart" enough when I changed my header paths back to exactly how they started that things worked again in that case too.
I guess at this point my solution is to rename my Block.h. There doesn't seem to be another way around it. Also, I did find another page with the same problem building on MacOS, so it's not just the iOS SDK with this issue. I didn't see a real solution in that thread either though.