
Interview: Jared Brown, iPhone developer about having his app rejected - terpua
http://www.crunchgear.com/2009/06/22/interview-jared-brown-iphone-developer-about-having-his-app-rejected/
======
ankhmoop
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.

~~~
cstone
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...](http://developer.apple.com/iphone/library/documentation/uikit/reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html)

As you can see, UIImageController is a subclass of UIViewController.
UIViewControllers contain a property named "view"
([http://developer.apple.com/iphone/library/documentation/uiki...](http://developer.apple.com/iphone/library/documentation/uikit/reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instp/UIViewController/view)),
which is a reference to type UIView
([http://developer.apple.com/iphone/library/documentation/uiki...](http://developer.apple.com/iphone/library/documentation/uikit/reference/UIView_Class/UIView/UIView.html#//apple_ref/doc/c_ref/UIView)).
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?

~~~
ankhmoop
_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.

~~~
cstone
"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.

~~~
ankhmoop
_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.

~~~
cstone
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?

~~~
ankhmoop
_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.

------
jerf
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.

~~~
rewind
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.

------
greyfade
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
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.

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

