Unity and iOS SDK 4.3

Many of you have reported troubles submitting your applications built with iOS SDK 4.3 to the iOS AppStore. At the time, the problem looked very complex and because all the troubles were happening after application gets post-processed for AppStore on Apple’s side, there were only a few ineffective ways to trace it down. We mailed all registered Unity iOS developers with a basic recipe of how to get their applications onto the AppStore:

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.

Regards,The Unity Team

Since then, we have spent many hours listening to your stories in forums, analyzing your builds, and trying out some ideas. We finally nailed the issue: iOS SDK 4.3 introduced a tiny problem with the native code linker improperly calculating how much code should be protected by the AppStore code protection system. The problem exposes itself only when AppStore protection is applied to the application.

Recently, a few forum users reported about successful submissions to the AppStore using iOS SDK 4.3. This led us to the solution (we would like to say big thanks to forum users “susantio” and “ratrodstudio”!). Our investigation of their projects revealed common use of the special linker flag “-all_load” (which is required by some 3rd party ObjC plugins). Using this flag forces iOS SDK 4.3 native linker to properly calculate protected code size and so it solves the problem.

Unity 3.4, which is just around the corner, will include this flag by default. If you can’t wait, you can try it sooner by applying few changes to your Xcode project by hand.

Instructions how to add this flag to your release build when using Xcode 3.2.6 (SDK 4.3):

1. Open your project in Xcode.
2. In the Xcode menu select Project->Edit Active Target.
3. In the Configuration drop down select “Release”.
4. In the Search field type “linker”.
5. Find the field named “Other Linker Flags” and double click on it.

6. Click “+” and add “-all_load”.

7. Clean all targets.

Instructions how to add this flag to your release build when using Xcode 4/4.0.2 (SDK 4.3):

1. Open your project in Xcode.
2. In the Project Navigator click on your project.
3. On the next pane select “Unity-iPhone” under TARGETS.
4. On the next pane select “Build Settings”.
5. In the Search field type “linker”.
6. Find the field named “Other Linker Flags” and double click on “Release” configuration near it.

7. Click “+” and add “-all_load”.

8. Clean all targets.
9. Make a distribution build by clicking “Product”->”Build For”->”Build For Archiving” (Note: don’t use Product->Build, because it will make “debug” build by default and won’t include “-all_load” flag).

We have received multiple confirmations from forum users that this helped them get into AppStore using iOS SDK 4.3. Also we are sharing all our findings with Apple, and we hope that this will help to get some fix included into SDK update.

As always please feel free to contact us if you have issues releasing your application to the AppStore or any platform.

My heart dropped last week when we submitted and were immediately rejected because of this issue. We too tested on our own devices it worked fine and we were perplexed. We struggled to figure it out, but narrowed it down to be a unity vs xcode 4 conflict. I’m glad this is resolved :)

This doesn’t seem related to the “ld: warning: ARM function mono_aot_version not 4-byte aligned issue”, unless I’m reading this wrong. Is there a fix for that issue? I recall a fix a few months ago, but for the life of me I can’t find the instructions.

1) Got it.
2) Two different iPads:
* iPad A: iOS 4.2, app compiled and deployed using XCode 3.2.5 and SDK 4.2.
* iPad B: iOS 4.3, app compiled and deployed using XCode 4.0.3 and SDK 4.3.
iPad A was where the app was initially developed until completion. Indeed the the framerate sank at the beginning. But was easily solved using expensive shaders only at small objects (screen-wise) , almost no transparency at all and to further avoid pixel overdraw the floor is ensured to be drawn almost last with an opaque shader that has a queue of “transparent-2” and the sky with “transparent-1” queue.
When testing the optimized app on iPad B the performance is again slow. Way slower, 3x slower… but thats blind fire, actually it is not known whether it is fillrate related, exception handling, cpu hog, etc. Internal and remote profiler for that! (never used them before, shame on me).

3) and 4) Thanks for the info and for the link, will take a look at that.

@Alejandro:
1) It is enough to clean “Unity-iPhone” target.
2) It’s not quite clear what you are comparing. iPad with one iOS version vs iPad with other iOS version? Usually people get bad performance on iPad when they kill fillrate with too much transparent things on screen or just ineffective shaders. You can try internal profiler or remote profiler to figure out where your performance is lost.
3) If your app crashes with “slow but safe” then something really bad happens: usually this happens when you add 3rd party native library, which is compiled with Thumb instructions and that triggers old iOS SDK linker bug.
4) Tapping crazy = crash? Usually this happens due some unforeseen corner case in user scripts. You can investigate your crash stack traces as described in Unity Manual page: http://unity3d.com/support/documentation/Manual/TroubleShooting.html#iPhoneTroubleShooting

– When you mean clean all targets, are you referring to the target builds? There are usually two targets when recently building from unity: Iphone target and Iphone simulator targets. Should we clean these two?

– When doing builds for testing in a dev iPad, the app crashes a whole lot more. And runs at about half the FPS. Is this a common issue for the time being? It ran perfectly fine on an iPad iOS 4.2 and XCode 3.2.5.

– In the Unity build settings, selecting Slow But Safe will make the app crash at startup instantly.

– Tapping on the screen like crazy with as many fingers as you can will sometimes make the app crash.

most of the times solving the problem with big companies like apple is hard but i think you should have a good relationship with them because your roots are in mac osx and unity is a really successful product as a middleware for ios and as something to force people to buy macbooks :)
it’s great that you work hard to help the community.

Can someone please edit this post? There are many missing words and it makes it difficult to understand what the author is trying to say. I understand that this is too urgent to nitpick before the first posting, but it would be unprofessional of Unity to leave it this way.