Interview: Jared Brown, iPhone developer about having his app rejected | Hacker News Reader

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

crunchgear.com

13 pointsterpua13 comments

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.

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?

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.

"The UIView hierarchy itself is undocumented. The ordering of the contents is undefined, may change at any future date, and can not be relied upon."

This is exactly what I said above. If you expect a certain structure, your app will almost certainly blow up, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, with public methods, regardless of what's inside (or not inside) it. Because that fact is documented.

This is exactly what I said above. If you expect a certain structure, your app will almost certainly, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, regardless of what's inside (or not inside) it. Because that fact is documented.

No, you can not rely on that undocumented assumption:

1) You can not know what to modify in an opaque set of views, because the contents of that opaque view hierarchy is undocumented.

2) You can not know that it is safe to modify the opaque view hierarchy, as doing so may break the undocumented invariants of the opaque view hierarchy.

3) You can not assume that the members of the view hierarchy meet your assumptions regarding structure, subclass, or nature, as the view hierarchy is opaque and not subject to declared API invariants.

If it's not documented, it is not a defined invariant, and it can not be assumed.

To claim otherwise is to simply fail to understand the purpose of defined invariants. Software development is no place to rely upon empirically-derived knowledge.

You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview. Then you can call the public removeFromSubview method on that view, and it will remove it from its subview. Then you can attach your own. Apple doesn't say you can in the documentation, but they say that UIImagePickerController is a UINavigationController, and you can do that to any UINavigationController.

You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.

I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?

You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview.

The facilities necessary to modify the hierarchy are defined.

The content of that hierarchy is undocumented and may change at any time. The behavior of modifying the opaque view hierarchy is undefined.

You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.

The contents are undocumented. You can not assume any behavior whatsoever if you modify the contents of the entirely undocumented view hierarchy.

Having been in the position of dealing with customers foolishly relying on internal implementation details, you honestly make me want to beat my head against the wall. It's one thing to make the mistake, it's another to proudly celebrate it.

I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?

You still misunderstand. It's simple: you can not firmly rely upon undocumented, empirically-derived knowledge without a vendor documented invariant.

The contents of an opaque view hierarchy -- and its behavior if modified -- are entirely undocumented.

My capacity for civil dialog is exceeded, and I'll stop here.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com