One way to add an extra level of security would be a type of key exchange.
In one of my apps, though we don't encrypt the payload (though it is over https), this is how it works:
1. The app has a key in it, which is common to all installations; this is known as the app key
2. On first run, the app generates a unique ID from the device info, and sends that, plus the app key to the server
3. The user authorises the app on the web site, and the app can then retrieve a unique user authorisation key for that device
4. When the app wants a session with the server, it transmits the user key and the app key
5. The server returns a session key, which is used to authorise all subsequent transactions until logout or
6. If the IP address changes, or a timeout occurs, the session key is invalidated and the app has to go back to step 4
So, yes, someone could grab the app key, even after obfuscation, and use that to write something that talks to the server
However, on the server side, we have mechanisms to revoke the app key too, as well as the individual user/device keys.
That gives us the flexibility to, for instance, disable any app that breaches our terms and conditions, as well as allowing a user to revoke access via a device that they've lost.
If you wanted to beef up your security, I'd suggest that you do something similar to this, where the login process returns a new secret key that will be used for that specific session.
You might include some error response that the app can use to indicate to the user that its request has been denied, and an update must be downloaded, which would contain a new initial key. And it may be a good idea to include some form of device id as well, so you can block devices, as well as app versions.
How complicated you make it all depends rather on how likely you think it is that people might want to do this - if talking to your server gives a way to access people's money, or to send a spam message to thousands of people, it might be appealing. If it allows them to fake the location of a bicycle, perhaps less so.