openfl 3.6.1
The following code works on flash, windows, and android, but crashes ios:
var unserializer = new Unserializer( cast(nativeSaveFileString, String) );
var saveFile = cast(unserializer.unserialize(), SaveFile);
In particular, it seems to be the actual call to unserialize(). When the crash occurs, xcode points me toward Dynamic.h. There isn’t really an error message, but it makes a note of “EXC_BAD_ACCESS” on a line of code that says DYNAMIC_ARITH( - )
What’s interesting is that I use this exact same operation earlier in the program to unserialize a save file string that I store via a shared object. The only difference is that here, the string has been coded to base64, sent over the internet, downloaded, and decoded back to its native format. Again, this works 100% fine on the other platforms. Is there something relating to the coding of base64 or the sending of data over a connection that would affect iOS builds differently?
Small update: I tried spoofing the base64 data locally and still received the crash. so the issue is not related to the actual transportation of the base64 data.
While the game actually crashes on unserializer.unserialize(); it would appear that the root of the problem is closer to:
inBase64 = "//base 64 data string here";
var bytes:Bytes = Base64.decode(inBase64);
For some reason it seems that on ios openfl cannot decode my base64 string back to something that the unserializer recognizes.
Really at a loss for what to do here… in the call for base64.decode I can pass an additional “complement” param, but I have no idea how that affects the process.
Continued research:
When a file is both uploaded and downloaded on ios, there is no crash. This would indicate that there is simply a difference in file encodings between the two operating systems. I know that the line endings are different- windows uses \r\n while osx/ios uses only \n
That being said there should be no end of line characters present at all, but this has to be close to the root of the problem. will do some more digging.
My next lead is that I believe the way in which osx/windows serialize dates is different. Both versions will deserialize on windows, but only osx will deserialize on osx.
I’m 90% positive that it’s related to the storage of dates after inspecting the string readout of the save file byte array
Solved.
When serializing a date on windows/ios, openfl stores it as timestamp in the form of a number of seconds
on ios, it stores it as a plain text formatted string
2016-04-01 17:20:43
vs
1459545643000
So when the file is loaded on ios I had to regex out any numeric patterns that looked like a date, feed that sequence as a timestamp into the date object, and replace it with the formatted date’s output.
What version of Haxe are you using?
We should report this to https://github.com/haxefoundation/haxe/issues if this might still be an issue!
is “haxelib_client” my version of haxe? If so, it’s 3.1.0-rc.3
That would be your version of haxelib, though it’s synced (usually) with your Haxe installation. Run haxe or haxe -version from a command-prompt to get your Haxe version.
We support Haxe 3.2.1, and different people are testing 3.4, though there have still been issues with it
Ohhhh-
On windows, 3.3.0.
It looks like on my mac though, it’s 3.1.3. I’m guessing this is probably a big part of the problem?
Try and sync up the versions, and see what happens. I’ve never used different Haxe versions for serialization, but I imagine this could be an issue 
