Great service!
Does that just mean the crash isn’t happening on iOS and just on Android (see attached)? Would the stripping level in Android have an effect on this? Currently set to use micro mscorlib.
Thanks
I’m having the same issue. I understand that it might not be able to report the crash the same session since it just crashes to OS and not as on Android where it just continues running. It would be nice to have it upload the report on the next startup though.
Might not catch all report but at least most of them.
Ah yes, that makes sense.
Anyone from Unity able to respond to say if this is how it works?
Thanks
I read a response in a different thread in this forum section where they said they were working on it.
Currently we store the exceptions in memory, so we don’t currently have a way to send them next session. I’d have to ask Will if there is a way we could flush this data to disk before the program exited (on crash).
Provided we saved the data to disk, it would be pretty easy to check for things to send next start.
Chris Lundquist
That would be great since the performance loss of releasing a app as slow-with-exceptions on iOS is unbearable 
But CrashReport doc says:
“If compiled with appropriate settings, Unity will try to gather useful information, like location and thread stack traces, when your application crashes. Upon the next application start, if the data gathering was successful, all crash information will be accessible using this API.”
So I guess in @coshea_1 case data gathering wasn’t successful?
Flurry for example does store the data locally, even on a crash, and sends it when next online. Any news on this?
Thanks
My personal best guess would be Unity 5.5 or 5.6.
Chris Lundquist
Thanks Chris, Unity crash reporting is better than others on the market because its specific to Unity code, but not being able to see crashes on iOS makes it the worst out of all them sadly.
Looking forward to the update. Thanks