After much testing and trial and error it appears I have solved this issue.
I thought I would post my solution.
On my startup script I had been loading several small graphics into global vars. After greatly reducing the size of the global vars it worked fine.
So it appears there is a limitation on how much global storage Go can hold in its frozen state.
If anybody knows where there is some docs mentioning this it would be good to reference. I didn't find any.
I don't believe it's necessarily a FM Go issue. I've seen some traffic on similar issues before, and I believe it has to do with how iOS manages the memory when applications move to the background. Might be wrong, but I believe that's where the issue lies.
Perhaps consider using global fields instead of variables?
I figure global fields would be the same because when hosted globals are not saved so if its going to restore it would need to save them the same way.
Just thought I would add a little more info...
I had about 1MB total info in all the globals. Most were custom graphics used in calculated containers. Case ( setting = 1 ; $$graphic1 ; $$graphic2 ) type of thing. Thanks to FM13 ability to hide objects I just took the graphics and overplayed them on each other using the hide calc to show the one on top or not.
This kept the size of the globals memory under 500k where it was a little over 1MB before.
I know when Go will go into the background or any iOS app for that matter there is a method called applicationWillResigActive that runs. Unless its got some background feature enabled like streaming music or whatnot, and Go does not. This gives the program time to save its state to a file like a .plist.
At this point I am wondering if they have a limit in Go on how large the .plist would be. As far as I know there is not a firm limit on how much data you save to it in xcode .
Just some thoughts and speculation.
No, I don't believe it is the same. Global fields are part of the database schema and therefore part of the local disk cache. Variables are memory-only storage.
Again, could be wrong, but I'm pretty sure the storage is handled differently.
I would think only the minimal amount of data would be saved to restore a files state.
That would be
global vars names and values
global table-field names and values
Im sure the cache is dumped. Even so we are really talking about the same thing here its just local saved data.
It would be interesting to test out sometime but for now I guess only a FM Go engineer with know for sure.