Re: Legal Opinion on GCUndoManager
Re: Legal Opinion on GCUndoManager
- Subject: Re: Legal Opinion on GCUndoManager
- From: Roland King <email@hidden>
- Date: Thu, 30 Jan 2014 18:36:57 +0800
It's not the defining but the calling. If your code calls a method with the same name as an Apple private method you, at least in the iOS store get auto rejected. I see it in the dev forums constantly.
At analysis time there's no way of knowing what object the method is called on so the signature counts and the analyser looks for method calls.
If Graham's own code called that method then I think he'd get a rejection, but merely defining it (and letting the framework call it) doesn't trip up the detector.
Whether Apple would reject apps which define methods like that if they knew about it is unknown.
> On 30 Jan, 2014, at 13:24, Jerry Krinock <email@hidden> wrote:
>
>
>> On 2014 Jan 29, at 13:03, Keary Suska <email@hidden> 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.
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden