Interview: Jared Brown, iPhone developer about having his app rejected

http://www.crunchgear.com/2009/06/22/interview-jared-brown-iphone-developer-about-having-his-app-rejected/

by terpua • 17 years ago

13 13 17 years ago

ankhmoop4• 17 years ago

Unlike the usual arbitrary, capricious, and infuriating appstore rejections, _the developer deserved this._

In order to implement something like Quick Shot, you have to muck around in the undocumented innards (private API) of the Apple-provided camera view widget. This is clearly forbidden by the developer agreement, and will easily result in your application breaking across minor and major releases. This breakage is evidenced by Jared Brown having to submit a new update for 3.0.

I take umbrage with his characterization of Apple leaving his users in the lurch. This is incorrect. Apple's minor culpability is only in choosing to not provide a better camera API.

Knowingly selling a product that clearly violates the developer agreement and will break in the near future is dishonest. The product is defective. I have sharp words for the App Store, and Apple's ridiculously arbitrary revue process, however, in this case the developer is clearly in the wrong.

cstone3• 17 years ago

You're wrong. You don't have to use a single method or class that is undocumented to add or remove stuff to the camera control's UI.

Here is a link to the documentation of the class in question: http://developer.apple.com/iphone/library/documentation/uiki...

As you can see, UIImageController is a subclass of UIViewController. UIViewControllers contain a property named "view" (http://developer.apple.com/iphone/library/documentation/uiki...), which is a reference to type UIView (http://developer.apple.com/iphone/library/documentation/uiki...). UIViews contain subviews, which are conveniently accessible through the "subviews" property. Every class in subviews must also be a UIView.

Just like in any other modal UINavigationController, to modify what's visible you use the public provided methods to traverse the hierarchy of UIViews. You don't need to know anything about the classes inside; you can remove them at will, just like you can remove any other subview from any other parent. This works in 2.0 and up.

So there's no private API here. The dude even says so in the article. Now ultimately, your application will break if you rely on UIImagePickerController's view hierarchy staying constant (doing stuff like "remove the third view from the image picker's subviews array", for instance) and aren't careful about checking results. In 3.0, the UIImagePickerController's view hierarchy looks significantly different from the way it did in 2.2.1, so a lot of people's apps blew up. (On the flip side, if you were being careful, things worked just fine.)

Forget all the blathering about who is culpable to who. This guy's app (and presumably others) were defective. But platform makers make changes that break apps all the time; why should this guy get his app banned forever?

ankhmoop4• 17 years ago

You're wrong. You don't have to use a single method or class that is undocumented to add or remove stuff to the camera control's UI.

No. You do everyone reading a remarkable disservice. The UIView hierarchy itself is undocumented. The contents and ordering thereof are undefined, may change at any future date, and can not be relied upon. The application did, in fact, break when the OS was upgraded.

Apple's use of "Private or Unpublished API" isn't intended to leave room for semantic arguments about the true meaning of "private", "unpublished", or "API", and they've clearly applied the standard industry definition in this particular instance.

But platform makers make changes that break apps all the time; why should this guy get his app banned forever?

Apple guarantees that their published, documented behavior (eg, API) will work across releases, and they strive to meet this guarantee. Where they fail they assume responsibility for fixing the issue -- file a bug.

greyfade• 17 years ago

I said it on another posting here, but it bears repeating, in my mind:

This is yet another example of why it's stupid to continue developing apps for the iPhone. The developer agreement and the review process need to be completely rethought and replaced. This is unethical, immoral, stupid, and outright anti-developer.

Developers should stop developing for the iPhone until Apple gets their heads out of their asses and stops doing this shit. If you're developing for the iPhone, you're just setting yourself up for financial losses, wasted time, and heartbreak.

zimbabwe• 17 years ago

It's unethical and immoral only if Apple isn't currently attempting to make the system better, and we have no evidence of that. I agree that it's stupid of them, I agree they're not supporting developers like they should, I agree that lots of people are getting hurt, but not every awful system is intentionally awful. It's been only a year since the program opened: I'm going to give Apple the benefit of the doubt for the time being and assume they're hauling ass to fix things.

99% of iPhone developers don't see these problems, and don't have their hard work rejected. Wanting the system changed is certainly a fine thing, but calling iPhone developers stupid is a stupid and meaningless insult that belies your one good point.

jerf• 17 years ago

Patient: "Doctor, it hurts when I do this."

Doctor: "Don't do that."

Yes, we get it, Apple rejects apps. The only news about this is that people still think it is news. News flash: When you cede 100% control to a third party, you have ceded 100% control to a third party. Next time, don't do that.

colins_pride• 17 years ago

At least this is just an app, I shudder when I think of the guys who are trying build businesses around Twitter. Good for Twitter, not so good for them.

rewind• 17 years ago

It's news to me because it's another different example of why they're rejecting an app. Is the news shocking? No, not at all. But these stories have actually been helpful to read because I'm getting a better and better sense of what to avoid. It's not news when it's the same reason over and over again, but reading about the different reasons apps are being rejected is giving me a better overall "feel" for the whole approval system and what to avoid.

pierattt• 17 years ago

I'd take him a lot more seriously if he'd stop using the phrase "are now ticking time bombs."

Interview: Jared Brown, iPhone developer about having his app rejected

Related Stories