LIBRARY REJECTED: Unity 3D (3D Graphics Engine)
Unity3D just ran into the Storm8 controversy, and has seen all new Apps using Unity3D automatically rejected this past week. Ouch.
“I got off the phone with Apple, who stands by the rejection saying that the two calls they referred to as private APIs cannot be used. He said for our game to pass, we would need to have them removed from the binary. Unfortunately, we cannot do that as they are part of the Unity engine”
I recommend following the thread on Unity’s forums – http://forum.unity3d.com/viewtopic.php?t=35744&postdays=0&postorder=asc&start=0 – for details and more examples of direct experiences from individual developers. Also for examples on how Unity reacted – and how quickly.
As with Three20′s rejections, this appears to be falling foul of Apple’s recently-introduced (and incorrectly-used) in-house static analysis tools:
mantasp
“Nope. All Unity iPhone apps built with version prior 1.5.1 RC1 do have these references and this fact does not depend on any configuration settings. Probably Apple is testing their new static code analyzer on small reviewer base and this is why some applications pass, some not.”
Developer thoughts
A few months ago, we first started seeing apps get rejected in a new way. Using “unofficial” / private API calls that are embedded inside every iPhone was always technically illegal, but often almost impossible to detect by a normal user. (not always – some usages were so extreme that reviewers easily spotted them, and manually rejected them). Many apps got through with known “illegal” code simply because the reviewer didn’t realise it.
What changed was that apps containing illegal calls were being rejected *even if they never actually made the calls*. A few examples came to light where the app in question referenced the code but didn’t use it – e.g. debug code that would never run in the live app, but only on the developer’s test copy on their own desktop. This implied that Apple had started using static code analysis – i.e. running a special tool against each incoming app that would inspect the binary code itself and check for wrong-doing.
Unfortunately, static analysis cannot tell you exactly what WILL happen when the app runs, only what MIGHT happen. So, even if you believe you’ve ensured that your code won’t trigger, there are cases where the static analysis will throw it up as a “possible”.
In the end, Apple cannot win. A classic example is some of the Facebook scams recently, where developers wrote their (illegal) adverts so that they would check if the Facebook user was using a computer located in Northern California (where Facebook has its offices) – if so, the ads would display legal content. There’s really nothing you can do at the code level to guarantee tricks like this won’t work – unless you completely disable networking. While that’s an option, the tendency is for all iPhone apps to eventually require networking. That’s one of the core features of the phone – always-on, unmetered, internet access.
In the meantime … it’s time to be extra cautious about the builds you submit to Apple.
