4 ms·

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

13 points by terpua 17y ago

ankhmoop 17y 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.
- cstone 17y 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/uikit/reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html 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/uikit/reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instp/UIViewController/view http://developer.apple.com/iphone/library/documentation/uiki...), which is a reference to type UIView (http://developer.apple.com/iphone/library/documentation/uikit/reference/UIView_Class/UIView/UIView.html#//apple_ref/doc/c_ref/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?
  - ankhmoop 17y 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.
    - cstone 17y ago
      "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 17y ago
        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.
greyfade 17y 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 17y 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 17y 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 17y 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 17y 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.
  - deleted 17y ago
    [deleted]
pierattt 17y ago
I'd take him a lot more seriously if he'd stop using the phrase "are now ticking time bombs."

13 points by terpua 17y 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.

cstone 17y 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/uikit/reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html 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/uikit/reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instp/UIViewController/view http://developer.apple.com/iphone/library/documentation/uiki...), which is a reference to type UIView (http://developer.apple.com/iphone/library/documentation/uikit/reference/UIView_Class/UIView/UIView.html#//apple_ref/doc/c_ref/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?
- ankhmoop 17y 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.
  - cstone 17y ago
    "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 17y ago
      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.

greyfade 17y 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 17y 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 17y 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 17y 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 17y 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.
- deleted 17y ago
  [deleted]

pierattt 17y ago

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