On Jan 29, 2014, at 3:44 PM, Graham Cox wrote: > > On 30 Jan 2014, at 8:03 am, Keary Suska <cocoa-...@esoteritech.com> wrote: > >> Absolutely, and I have found it invaluable to troubleshoot state issues, but >> unfortunately it is not App Store safe (read: basis for rejection), as it >> relies on a private method call for proper NSDocument change tracking... > > It does? > I'm using it in an App Store app without it ever having come up as an issue. > Have you actually had this flagged as an issue by The Keepers Of The Storeā¢? > > If you're referring to: > > - (void) _processEndOfEventNotification:(NSNotification*) note > > > I'm not sure that counts as using private API as such. It's just a stub for a > method that NSDocument calls on its undo manager, and as you can see it's > only a notification handler (containing no code). It's needed because > NSDocument doesn't check whether the undo manager implements it before > calling it, so it will cause an unrecognised selector exception if it's not > there, but it's not actually calling any private API itself anywhere - > NSDocument is. > > If you subclassed NSUndoManager, you would be "using" this private method, > but since GCUndoManager isn't a subclass, the stub is needed so that the > replacement object mimics the original correctly, in accordance with the idea > of duck-typing. If anything, Apple should be either checking for the > existence of the method before invoking it, or making it public.
I haven't had the misfortune of a rejection on that basis but it is good to know that I can keep it in my next app. I should have said, "may be" rather than "is"--I was extrapolating from a different case a colleague experienced where they experienced a rejection from calling a private method, but I think that was iOS, and maybe the rules are more stringent there. I haven't read the latest App Store guidelines so I can't be sure. Hopefully the inconsistencies in approvals are a thing of the past... Best, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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