Categories & Tags
Archive

Unity and iOS SDK 4.3

June 15, 2011 in Demos, Tutorials and Tips, Tech by

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.

Xcode3_config

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

Xcode3_linkerflags

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.

Xcode4_config

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

Xcode4_linkerflags

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.

Share this post

Comments (19)

Comments are closed.

Jason Amstrad
15 Jun 2011, 9:19 am

Thanks Mantas Puida.
And what will be “new” in Unity 3.4 ?

15 Jun 2011, 11:33 am

Well…a new version number for one :D

Keith
15 Jun 2011, 12:26 pm

woot, new version number ;)

15 Jun 2011, 2:54 pm

I would like to read more about new upcoming unity version.

15 Jun 2011, 4:06 pm

Thanks mantasp!

Jean
15 Jun 2011, 5:17 pm

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.

Ashkan
15 Jun 2011, 11:40 pm

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.

Alejandro
17 Jun 2011, 2:28 pm

Hi, thanks a lot for these tips!.
A couple of questions:

- 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.

Mantas
20 Jun 2011, 3:53 am

@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

Alejandro
20 Jun 2011, 9:20 am

@Mantas:
Thanks for the reply!

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.

Thanks again!

Alejandro
20 Jun 2011, 9:22 am

Sorry. On the previous post the XCode version for “iPad B” is 4.0.2.

5 Jul 2011, 7:28 pm

Just got rejected by the AppStore. Going to try this fix and resubmit…

6 Jul 2011, 5:41 pm

It worked! PlazaLingua Spanish was approved this morning. Good work troubleshooting this guys. There is NO way I would have been able to figure that out. Thanks!

shumno
22 Jul 2011, 1:37 pm

Thanks this is all good information but the build process still fails for me.

26 Jul 2011, 5:12 pm

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.

6 Aug 2011, 9:55 pm

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 :)

Shri
20 Sep 2011, 11:55 am

Thanks a bunch. I faced this issue with publishing my game in AppStore and I’m so glad I came across this link. I did exactly what’s described here and my game got approved right away.

status of this ?
30 Sep 2011, 4:21 am

Its this issue resolved, if so in what version, where is the official info on this ?

Mantas
30 Sep 2011, 4:54 am

Workarounds were included into Unity 3.4 and it is safe to use now without need to manually tweak the Xcode project.

Leave a Reply

Comments are closed.