This is an interesting question and one that I've thought about a bit -- without much luck, though.
The basic problem is that any client which connects to your server is indistinguishable from any other app. Your authentication must therefore be based entirely on the data the client transmits to your server. Given that your client app resides on the remote machine, it is vulnerable to reverse engineering. I don't have any definitive, hard-core math proofs or anything, but I would imagine that it is probably impossible to construct a client that is proof against reverse engineering. Hackers access the binary code of your client application by reading the file system of their iPhone. They can decompile it into source code. They can copy the executable into a virtual machine running on a desktop and monitor its behavior there. Any encryption you might want to perform in the client could be monitored by the hackers and deconstructed and reverse engineered. You may have noticed that pretty much all attempts at DRM ultimately fail: DVDs, Bluray, securom, etc. They can all be detected, understood, and beaten.
It may, however, be helpful to generate key pairs or something? Perhaps build each instance of your app with its own key pair? This would allow you to encrypt all data in transit such that no two clients would be able to decrypt each other's communications. This would require you to store one private key / public key pair for each instance of your application. Going through all this trouble doesn't really gain you much in terms of security or authentication, but if you found that one of your apps had been reverse engineered or compromised, you could disable its key pair which would prevent anyone from using its credentials for communication with your server.
That's about as far as I've gotten in my thoughts on the matter. I'd be happy to hear some discussion on it.