REJECTED: Postage (but Apple’s claims are “impossible”)
This is what happens when unskilled staff (Apple’s app-reviewers) are given a technical tool (the secret static-analyer) which they don’t understand – but trust 100%: Reject apps that haven’t done anything wrong, but which the tool (incorrectly) flags, in this case Postage [
]:
The notice from Apple indicated that we had used a private method of UIViewController called previousViewController.
…
After looking at a class-dump of the 3.0 frameworks It looks like previousViewController isn’t a private API method, but actually a public method on UINavigationController.
Developer thoughts
So, it seems this is actually a case of “there’s a bug in the static analyser”.
This is no surprise – Apple have repeatedly shown that they have no idea how to write modern software (they appear NOT to do Unit Testing for their OS releases, nor for their toolchains – there are so many basic bugs that slip through which UT would have identified early).
November 26th, 2009 at 5:18 pm
I just at UIViewController.h right now. previousViewController is not there. I also just looked at the documentation for UIViewController. It’s not there, either.
Not in the header or the documentation? Clearly private, whatever scope Apple put on it internally.
November 26th, 2009 at 5:37 pm
There’s some good followup over on the three20 google-groups page; people investigating more closely what – precisely – was wrong here.
http://groups.google.com/group/three20/browse_thread/thread/bcae33d8108ea573#
I recommend watching the google-group / joining the mailing list to keep up to date on three20 in general.
November 27th, 2009 at 4:04 pm
Is it possible for me as an iPhone developer to run this static analyser tool before submitting my app?
I guess this would save some time for Apple as well…
November 28th, 2009 at 3:54 am
I have to agree with Steven, nowhere in the documentation nor the header files for either UIViewController or UINavigationController is previousViewController. And, from the name, it seems there would be no reason to need to utilize it.
November 28th, 2009 at 8:51 pm
The author of the site SHOULD monetize this blog. I think he or she has stumbled on a quickly-growing segment of the App Store market.
Not that I think a developer’s chances of getting their app rejected is actually SIGNIFICANT, mind you. After all, Apple has approved more than 100,000 apps, which means that even if the author can rustle up 1,000 rejected apps, that would add up to a mere 1% rejection rate–hardly news at any other scale.
Of course, a rejection is a devastating blow to any developer’s pride, especially after months of painstaking toil and suffering. Still, one needs to keep things in their proper perspective. In most cases the solutions are simple: Fix your description or artwork; if you declare categories on Apple’s classes, prefix your method names.
A particular note on category methods: Apple is right to reject apps that contain symbols that clash with Apple’s internal code. How else do you expect Apple’s code to work when your App causes symbol collisions? Any Cocoa developer knows: always prefix your categories, especially if you’re declaring them on system APIs! Rename your methods and resubmit. Problem solved.
That said, I have great expectations for this site. I do hope you start taking ads and pocket some change in the process.