Short answer: No.

It helps to have an appropriate mental model of the problem you’re facing. Imagine that your app is a filing clerk (program binary) working in a rented office (the user’s phone). He’s got his own computer, desk and phone (process running on the user’s phone), but the filing system (file system) is controlled by the landlord of the office building (the user). You can trust the landlord to keep providing your office equipment, but you know they have an agenda of their own, which may include messing with the work you’re doing.

The important point to see is that the clerk can work unimpeded, but he goes home every night (when the app is closed), and the next day he’ll only be able to remember where he was and what to do by reading instructions from the filing system – which may be compromised by the hostile landlord.

This explains why it is ultimately impossible to guarantee a secure workflow while completely depending on a hostile persistence provider. You can leave yourself notes, but the landlord might intercept and alter them. You can encrypt the notes so that others can’t read them, but the landlord can apply cryptanalysis. You can sign the notes so that they can’t be altered, but cryptanalysis can be applied to that problem as well. Worse, the landlord is able to scan the clerk’s brain (program binary) while he sleeps and analyse its workings, including the part where he stores the secret encryption key. The landlord can even simulate running the program in a secret environment and observe how it does the encryption (here the metaphor breaks down).

Therefore, all you can do to make your workflow secure is to try and make countermeasures more expensive. Encryption can help with this, but it depends on the situation whether you can make it expensive enough to actually prevent what you want prevented. Probably no one will employ virtualization and cryptanalysis just to generate a fake online high score in a small casual game. But you never know – maybe your app will go go viral, and high-level profiles become worth a lot of money. All you can do is estimate how much effort someone would expend to subvert your program, and plan for this amount of countermeasures.

Well this indeed requires another approach. Normally with https you would like to get unknown attackers away from the user. But this time you need application to protect the user from attacking. Hacking games requires different levels of hacking

Well first of all you should protect that the game could run in an emulator mode (or something like that). With an application like bit slicer you can easily lookup current amount of money (or any other property) and search again when the value has changed. Then they change the value in your memory to whatever value they like. Solution to this is an algorithm can be used to store a value and have an checksum stored in memory somewhere else. This way you prevent users trying to hack locally on the iOS device itself running your game on jailbreaked devices as well.

The second security that’s needed is to avoid using a proxy hack, again not to protect the application from outside hackers but inside again. https doesn’t provide this protection at all. What happens is that a user download an application like Charles on they Mac. Then on their iOS device they go to network settings and set the proxy settings so every request goes to the Mac. Then they startup the game and look on the mac for all communication between the iOS device and internet. An app like Charles can changes values of headers and body of HTTP requests and responses using regular expressions in real time. So even when the server replies that someone has 100 gold, a simply regular expression in Charles could make the device receive an reply from the server as the user would have 100k gold for example.

The best way to protect against proxy hacks is that you code sign everything. That means that all values, or group/array of values does have a certain checksum that only applies for that device. The algorithm depends on certain keys, liek device id, session id and type of property. So when a value of 100 gold is send to the client, a code sign value is send with it as well. The same keys are on the device which makes that when he encrypts the value of 100 it would have the same code sign value as send from the server. When someone would change the value 100 using a proxy hack, the outcome of the encryption would be different from the server and you’ll notice that the user is trying to hack or is being hacked by someone else. At least, the device shouldn’t accept the value.

You will need to have code on the server that detects attempts at tampering and deals with them.
So don’t calculate whether that gun hit something on the client, don’t calculate how much damage that sword did on the client, don’t even calculate whether your user sees something on the client. Do ALL of that on the server, the client is only for displaying data and generating input.
Also don’t let the client tell the server “I moved 5 meters forward”. No, let the client tell the server “move forward for 2 seconds” and then the server calculates how far that is, or if it’s even possible (prevents speed hacks and people walking through solid obstacles).

That’s just a few things you should do, I’m sure you can think of a lot more yourself based on what your game is going to do.