Best approach for making an app that connects to sensitive information

SSL prevents an attacker on the network from being able to see or manipulate the data in transit. However, this makes no guarantee that the user of the application hasn't modified the application. Any value stored in memory on the device can be easily obtained using a debugger.

In short you can never trust the client, and this isn't a problem that cryptography can solve, period.

First, an attack where someone relays traffic between two parties is called a man-in-the-middle attack. SSL protects against them if the two sides have been authenticated. Authenticating the two sides requires that you use SSL in a particular way, either (preferably) with client certificates or some application-specific method.

In any case, if you want to ensure that only your application will talk with the server, you need to store a secret inside your application. There has to be something that your application knows and the attacker does not know. It is not impossible to store secrets in an application that you distribute, but it is very very hard; it requires obfuscation. Note that the word “obfuscation” has several meanings when it comes to software; here you want obfuscation not in the sense of source code that's hard to read but in the sense of hiding a secret inside an application. The obfuscation bible is Surreptitious software by Christian Collberg and Jasvir Nagra if you want to go down this route. All obfuscation methods are cracked eventually, so your only hope is to stay abreast of the attackers and keep changing your techniques. Developing for obfuscation will easily multiply your development time by two or three, after you've acquired the necessary background. If anyone tells you that you can get it more easily, they're misguided or lying.

In summary, you cannot trust the client. If you have sensitive data, keep it on the server. Treat any response from the client as untrusted.

1- You need to get yourself familiarized with the principles of secure communications. There is no escape here.
2- As others have said NEVER TRUST THE CLIENT, even if you are writing the client.
3- For every communication you need to make sure who is on either side (on client side you need to make sure you are talking to the correct server, on the server you need to make sure you are talking to the client you are expecting to talk too). One of the many ways to do this is to use a combination of asymmetric and symmetric encryption, on the server you need to know [each] client's public key, on client you need to know your servers public key then you can exchange an RSA key or some symmetric key (specially if performance is an issue).

This is just a suggestion, you need to tweak it based on what you need.