I recently ran into the problem of submitting an app to Apple that used Unity and iOS 4.3 as base SDK. It ran perfectly on our own devices but it crashed immediately after launch on Steve’s iphone. They added a couple of crash logs for me to check out.
Of course to symbolicate the crash log I need DWARF symbols, but apparently Unity by default turns off generating debug info (why?). I switched it on in my project settings and rebuilt the app. Fortunately the UUID hadn’t changed so I should be able to use the newly generated symbols with the crash log, right?
Turns out the dSYM files didn’t contain any debug info at all. After some inspection I found out that Unity adds some extra linker flags “-Wl,-S,-x”. This strips the binary of debug symbols before xcode exports the dSYM folder.
Removing this flag unfortunately changes the UUID of the app, so using these symbols to make sense of the crash log that was sent might be a bad idea.
I since found out that I wasn’t the only one with the problem so I just resubmitted our game with iOS 4.2. But it has left me wondering why Unity by default makes it impossible for us to make sense of crash logs. Is there some other way we should be debugging our apps?
And why does Unity set those specific flags? Could I not remove those flags and just enable “Strip Debug Symbols During Copy” option to do the same thing but at the appropriate stage?
These flags save you couple of megabytes on distribution size. When you need to analyze crash just rebuild app without that flag. Code symbol locations will remain the same.
I do not know about the reasoning of why these flags are set, but the crash with iOS SDK 4.3 is a known issue currently being investigated. We sent an email to all iOS developers about this:
Dear Unity iOS Developers,
Unfortunately, many (and probably all)
Unity iOS applications built with iOS
SDK 4.3 are crashing during the App
Store Review process while still
running successfully on developer’s
devices. We have contacted Apple
regarding this issue and received
confirmation that this is of highest
priority to them. Our iOS team is
working on a solution as well, but due
to complex nature of the problem it
will take longer than expected to
properly resolve. A currently known
workaround is to keep using iOS SDK
4.2.
Many users reported that applications
built with Xcode 3.2.5 + iOS SDK 4.2
successfully pass the Apple App Store
review process currently. OS SDK 4.2
is not publicly available on the iOS
Developer site anymore, but it still
can be downloaded via direct link. We
want to assure you that building final
applications with iOS SDK 4.2 provides
all the features the Unity iOS
run-time supports and is proven to
work fine with devices running older
generation iOS (3.x-4.2.x) as well as
the newer devices running iOS 4.3.x
(like iPad 2).
Please feel free to contact us if you
have issues releasing your application
to the App Store.