Technical Analysis
An update to RogueSheep’s Postage app was recently rejected by Apple because of a supposed overriding of a private method in a category. Apple most likely used a static analyzer to determine this problem. As far as I can tell, Apple has a bug in their static analyzer.

Three20 adds a category method -previousViewController to the UIKit class UIViewController. According to RogueSheep:

The notice from Apple indicated that we had used a private method of UIViewController called previousViewController.

As far as I can tell, there is no private method in UIViewController called -previousViewController. There is, however, a private method on UINavigationController (a subclass of UIViewController) called -previousViewController.

However, this should not be a problem. Subclasses of UIViewController which implement -previousViewController themselves will override the category method defined on UIViewController by Three20. This includes UINavigationController and whatever other Apple-defined subclasses exist for UIViewController.

I have filed this as Radar #7414099 (rdar://7414099 for Apple employees). The test project is available at: CategoryBehavior.zip

Opinion
Ultimately, if my analysis is correct, this is just a bug. They happen. Static analyzers are especially difficult to get right, especially when the source isn’t available. This shouldn’t be read as an indictment of Apple, or of Apple’s intentions. They’re just trying to protect the user experience of their products and head off binary compatibility problems.

However, I personally think they’re going to have a difficult time trying to detect private methods with a static analyzer. They might have better luck doing analysis at runtime — checking the actual class hierarchy and interposing on method calls.

Meanwhile, there will be a lot of false positives caused by this, which is going to be frustrating for a lot of iPhone app developers.

Tonight, while writing another blog post, I tried clicking on the bit.ly link to go to my app’s page, and instead saw this:

Somehow, my link had been flagged as malicious and I’ve been missing out on potential sales because bit.ly decided to break my link. Why though?

Looking at bit.ly’s FAQ, they say:

Bit.ly filters all links through several independent services to check for spam, suspected phishing scams, malware, and other objectionable content. We currently include Google Safe Browsing, SURBL, and SpamCop in our operations.

Checking Google Safe Browsing, SURBL, and SpamCop, I see neither planetaryscale.com nor itunes.apple.com are blacklisted.

Okay, that’s weird… but wait! It looks like when I originally created the link, it was actually a link to a tinyurl.com link. That was kind of dumb of me. However, as a sanity check, I’ve created a link to Disney.com with tinyurl to see if it too will be blacklisted by bit.ly. Unsuprisingly, it is. Checking Google Safe Browsing, tinyurl.com is listed as an intermediary to malware, as is bit.ly.

So, the takeaway from all of this is: as far as I can tell bit.ly is flagging all links to tinyurl.com as malware, even just a link to the tinyurl homepage.

Why is this worse than just a screwup on my part? Consider that bit.ly is used to automatically shorten URLs in a lot of services, such as Twitter. A quick check shows bit.ly also flags links to the homepage of is.gd, tr.im, cli.gs, tiny.cc, BudURL.com, snipr.com, snipurl.com, and kl.am, all of which are competitors. In fact, if I tried to link to the Enterprise Edition of BudURL in a tweet, it would be automatically converted to a bit.ly link. Clicking on that link would take someone to a giant warning page, rather than the product of a competitor.

I realize bit.ly is trying to do this as a safety feature, but as it stands I’m moving my web links to direct URLs. The added value of their statistics tracking just isn’t enough to offset the risk of them breaking my links.