For applications where connection loss is an issue, redesigning the application to run without a persistent connection to the server with the assistance of a tool like GoZync is the first answer that comes to mind.
It seems that the connection loss happens all the time unless the device is on a wifi connection and set to never sleep. Connection loss is always an issue.
What you are suggesting is that mobile devices will not ever properly work unless something like gozync is used.
I looked at gozync and it looks clunky. It would be great for long distance access for info that does not change rapidly with access to many users.
In my case we are used to having ios devices connected over wifi and need the speed of having data updated quickly. Needing a sync plugin in a local network environment is not what we expected when FM said it works for mobile devices.
The point that has been made is that FM should be addressing this connection issue as an internal fix.
I think this is a huge problem. In a nutshell the problem is if fmgo gets disconnected from the network, when it tries to reconnect, FM server doesn't handle the disconnect well. When fmgo reconnects, FM server thinks there are two sessions working on the same record. You end up getting the dreaded Revert message. At a minimum, you'll lose any uncommitted records and possible a whole found set of records. There are ways to minimize the impact. In my testing I found the iPad going to sleep was not the problem. The real problem was wifi disconnects that might happen when the iPad is asleep.
I am not suggesting that mobile devices will not ever work properly unless something like GoZync is used. I have deployed FileMaker Go applications running on cellular data networks on devices that sleep without running into the sorts of problems you describe — at DevCon to a large audience of other developers, no less.
Perhaps there's room for FileMaker to improve the handling of intermittent connections from FileMaker Go to Server over poor quality networks, but that's hardly the most expedient solution. By all means, ask for the improvement; but don't wait for it.
Is there any room in your application to limit the opportunities users have to leave records open? iOS user interface idioms allow much greater latitude for distinguishing between very different "view" and "edit" modes in applications, which developers can take advantage of to keep records closed as much as possible. The OnRecordOpen trigger can be particularly helpful for keeping users from opening records on layouts where you don't intend for them to, by exiting with a False (0) script result, thereby canceling the action of opening the record. Data entry on iOS works best when it's quickly in-and-out, not dawdling. This does not removing the possibility of encountering the issue you describe, but it should reduce the frequency, which is better than nothing.
One of the issues is the way most users interact with their iPad isn't the best way to interact with a FileMaker database. Most user will simple tap their home button or close their cover when they are finished. I've minimized this problem by using Get(RecordOpenState) in script triggers to commit records. This is especially helpful if you are entering data into a portal.