Well, unless the server check every single step of the battle, there is not any way for the server to distinguish a trustworthy app from a malicious hack. And also in this case, unless the battle is played entirely on the server but displayed on the app there is no way to trust the remote client.
AFAIK, we must esclude that the battle is played into the server otherwise loosing a connection would stop the battle BUT data would not lost.
Unfortunately, playing the battle on the server is a huge load for the server compared being played on the app AND the response times might be unacceptable for many players. These are the main reasons because the battle is played into the remote application.
Unless the items could not be traded among users or into an indipendent makert to be sold for money, then the effort of having a full-functional hack would be quite small. Quite small unless the communication were very plain and man-in-the-middle attack prone.
*** ALTERNATIVE ***
So far, the battle is played by the application with the data sent by the server. When the battle is finished, all the data battle would go to the server. Treasure should decided by the server at the end of the battle OR decided at the beginning of the battle but in such a case it stays cryptographically locked and the server would send back the key to open the treasure which otherwise would be lost.
In both of these cases it might be not a valid reason to wait for the network OR after several tries to stop application and every time it restarts try to complete the deal with the server. In any case the application should reconnect with the server at the restart.
*** BEHIND THE CURTAINS ***
What’s the problem could be behind the courtains? Obviously, there is no a single server but a large number of servers (whatever the platform exists on the cloud or it is real).
No all the server keep all the battles treasure keys but just the one that begins the transaction (and its mirror, but we might forget about such a details because redundancy is transparent also for this issue – it is clearly not a problem of fault redundancy).
The app have a lists of servers? The IP of the last server? Usually no. Why? Usually, because it exists a domain name which is resolved by DNS in few many IPs Addresses and every of this machine is a dispatcher to the back-end servers.
The probably to get the same dispatcher and the same server is quite null. Thus, the transaction could not complete unless the battle key is not stored as global information which usually is not but a peer-session information.
This for security reasons (hard to hack and exploit) and to avoid IT resources waste because a global key should be syncronised into all distributed database nodes.
On the client side the peer-session key would kept in memory to avoid the dump onto a disk. Because saving on disk sensitive information increases the chance that could be collected or corrupted by 3rd party malicious software.
Much probably, this is the reason because at the restart of the application the session is lost and thus the chance to retrieve the treasure / reward lost as well.
*** CONCLUSION ***
Is there any GENERAL solution that could keep together security with resilience (the ability to resume a previous state)? It might be.
For sure, the app could spawn a thread notification-like that would try to handle the session longer and the application go to sleep until the player decides to abort the retries and loose the transaction OR a time-out expires.
It would work? Depending on the server side ability to keep an open a session which do not respond from the other side.
Obviously, this policy would expose the system to a DOS/DDOS risk by opening sessions and leave them open forever. As we can imagine, no any open session that would not respond properly should keep open forever (some others tricks are used to even mitigate the risk and these kind of attack, but this is off-topic).
Unfortunately, with the information we have as users we cannot get into deeper of this problem nor of the solution – unless we hacking the app but in that case we would do it in such a way we would able to win everything! 
However, the Game Editor could know how many transactions are cancelled by network problems and this could estimate which impact this issue have into the players experience.
