If you wanted to support all of UIKit and Cocoa Touch, the problems would be insurmountable. You'd spend 2 years trying to get off the ground and then give up, while everyone else had fun developing apps for the iPhone and iPad and other devices. You would regret even trying it.
But if you wanted to create your own framework for making iPhone apps, built immediately on top of OpenGL, it might be possible. You would create a simulator that renders to an OpenGL view, and the final app would also render everything in an OpenGL view, touching none of UIKit. You would use pure C, or some robust cross-platform language like Lua, compiled or even interpreted. Incidentally, that's more or less how the Corona framework does it: built on top of OpenGL, touches little of the iPhone SDK, uses compiled Lua. They developed their own simulator, which only runs on OSX, but could probably relatively easily be ported to Linux.
You could even use Objective-C as the language, and make available a carefully chosen subset of the Cocoa API's by using (the iPhone compatible parts of) GNUstep Base. Then users could use standard classes like NSString.
Still, all of this is mostly interesting as a thought experiment, unless you got a team together to work on this as an Open Source project. It's harder than you think. Your simulator wouldn't be able to emulate the way that memory warnings are generated on the iPhone, for example.
If someone wants to develop iPhone apps on Linux, it makes more sense to just write the whole app in C/C++ using OpenGL, and then basically just smack that code onto a vanilla iPhone OpenGL project. That's the fastest path. The next possibility would be to use another language, which is also not too hard. But an "iPhone IDE" on top of that would be little more than putting an iPhone-like frame around the OpenGL view in Linux.