RogueSheep’s Postage App Flagged by Apple’s Static Analysis Tool | Hacker News Reader

RogueSheep’s Postage App Flagged by Apple’s Static Analysis Tool

daringfireball.net

6 pointsmatty12 comments

I just had a app rejected for this same reason.

Although the API was never called, the static analyzer throws a flag when you override any private framework. Joe was doing this for some debugging purposes and accidentally let it through for some release builds a while ago. Just updating to the newest Three20 should fix it.

The relevant changeset in Three20 where Joe resolves this should answer your questions:

http://github.com/facebook/three20/commit/8183ae25528bbc575a...

This commit was an incomplete fix (i.e. you'd still get autorejected after 2 weeks of waiting). Looks like the complete fix was merged in from the uprise78 fork yesterday, so Three20 is safe for the app store once again.

See http://github.com/facebook/three20/commit/c62a4cfd26c19d9248...

Waiting 2 weeks for an Apple reviewer to press the "run static analyzer" button sucks.

This is getting ridiculous. The Objective-C runtime allows dynamic method calls, using performSelector: which takes a selector name, which can be constructed from any random string. This basically means any static analysis tool can be trivially fooled. Apple might as well start rejecting all apps which use any "features" of their runtime.

Who cares whether a method was overridden or called or whatever -- if it's in the runtime it can be invoked.

Who cares whether a method was overridden or called or whatever -- if it's in the runtime it can be invoked.

API's aren't hidden to make developers lives harder, but rather because they may not be stable and may or may not exist in future releases. And if they do exist, they may not do the same thing anymore.

So, users care. Not about the method itself, but about why their app that they may have paid money for has stopped working after they upgraded their iPhone.

I wasn't implying that we should all start using hidden APIs. Personally, I have a hard enough time using the documented API. My point was that a tool to catch such uses is pretty pointless, as it can be defeated using other entirely "legitimate" API calls.

To your second point, even apps that stick to using only documented API methods have known to fail after iPhone OS upgrades. So, let's not delude ourselves (or the users) into thinking we're writing robust (or worse, future proof) software simply by adhering to Apple's guidelines. All I would ask from Apple is that they get out of my way of getting an update to my users as quickly as I can.

Did I read this correctly? They overrode a private API call, but then never called the method that they overrode? Or did they only call the method they overrode, and never call the private method.

I don't see why you would override a method but never call it, and if you override it, shouldn't you call [super methodX] (thereby calling the private method)?

RogueSheep used the Three20 framework, which overrode the method.

Nice. Just thought I would point out that on Android, I can write applications in my language of choice, and I can use any construct I want. If I break something, I get to keep both pieces.

Why do you iPhone guys put up with arbitrary restrictions?

40,000,000 more potential customers.

And forty million other apps to compete with for attention.

100,000, actually: http://www.apple.com/pr/library/2009/11/04appstore.html

Reply on news.ycombinator.com