On 29 Jan 2014, at 11:24 PM, Jerry Krinock <je...@ieee.org> wrote:
>
> On 2014 Jan 29, at 13:03, Keary Suska <cocoa-...@esoteritech.com> wrote:
>
>> unfortunately it [GCUndoManager] is not App Store safe … as it relies on a
>> private method call for proper NSDocument change tracking…
>
> I just spent the last half hour studying this and wrote my own concise legal
> opinion arguing why GCUndoManager is OK. Now having read Graham’s post, it’s
> probably redundant. But I’m posting it here anyhow in case I or anyone else
> ever needs it :)
>
> Although -[NSUndoManager _processEndOfEventNotification:] is a non-public
> API, -[GCUndoManager _processEndOfEventNotification:] is NOT a non-public
> API. As a matter of fact, it is not even an Apple API! It’s the same as if
> I defined a class CorePerformer and innocently named a method -[CorePerformer
> _corePerformAction]. There also happens to be an Apple non-public method
> -[NSMenuItem _corePerformAction]. Certainly my definition should not result
> in an app store rejection.
I can’t offer legal opinions or advice (retirees from the bar are particularly
forbidden to do so), but this isn’t a matter of law. Apple says explicitly that
the guidelines are only that: a description of the principles that characterize
a completely discretionary process. They are not rules, because there are none.
Rules (binding promises) could be gamed to defeat Apple’s purpose in conducting
reviews.
Legalism does no good (as is so often the case in life). Apple says it will do
no good.
If I were implementing the review process, my automated checker would run
strings(1) on the binary, and flag the collision with private API. Under my
notional process, the reviewer would have to reject, because he has no way of
knowing how the selector is used; or, even if your use is innocent, whether it
propagates down into the framework so the collision with private API happens
anyway.
You could appeal, and may win — solely on the technical question — but if I’m
right, the app would not simply sail through to acceptance.
— F
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
