Data Management

I'd like to be able to save data (consisting of either a large C struct or an array of C structs) to my computer's desktop from my cocoa editor program and then drag that file over to my iOS app's resource bundle. I find that with certain types of data this works but for other types it doesn't - I tried using both fread()/fwrite() as well as NSData and the results remained the same. Is this the result of some difference between architectures?

That's not very safe, but since ARM and x86 are both little-endian, it can be made to work with some care. I'd suggest adding assertions that sizeof(yourStruct) == whatYouExpect and offsetof(yourStruct, eachField) == whatYouExpect. Sticking to the [u]int[n]_t types from <stdint.h> + float/double and sorting the fields of your structs by size, largest first, will help too.

...From what your telling me this was poor planning on my part
and trying to do what you describe to all of my data seems unrealistic especially considering that I'm not a great programmer and have little experience with really low-level C stuff.

Is there any way out of or around this without having to parse every single struct?

This is a shot in the dark, but might it be possible to reorder all of the structs' fields using bit fields in order to eliminate paddings?

There's nothing ridiculously bad about this struct. Replace "int" with "int32_t" (or smaller if you like); replace BOOL with uint8_t; ensure time_interval_t is a typedef off an explicitly sized type, and sort the fields big to small and it should start working... (and of course do the same to the nested struct types).

I really do suggest adding at least the sizeof() assertion though. Better to crash at startup when the assertion fails than corrupt memory or data later.

So for simplicity's sake let's just say that I'm only saving game data from the OS app into the iOS app's docs directory. Should I be concerned about the future portability of this data (i.e. if apple changes the arm architecture in some way that somehow affects the memory mapping or whatever)? ...Or are there other concerns I'm missing? Also, how likely a scenario (the architectual change) do you personally think this is? I'm not adverse to gambling if I feel fairly certain (say 80%+) of its unlikelihood.

You will always be able to write code to read whatever format you decide on now. Just be aware that taking the shortcut now does not necessarily mean you will get away without writing the hard code forever.

Also, always write a few sanity bytes and a version number at the start of each of your custom file formats. Makes it easy to change the format in the future, and to read multiple versions of the format.