
Apple Claims Mogenerator's Methods - chmars
http://rentzsch.tumblr.com/post/82453434093/apple-claims-mogenerators-methods
======
archagon
That sucks (but it's also a little funny, I have to admit). Here's an idea:
instead of excluding Apple from the license altogether, why not insert a
clause to specifically prohibit putting any of the class methods on Apple's
non-public selector list?

~~~
leoc
Add specified damages for doing so (be bold! be creative!), and mandate your
choice of legal venue (obviously somewhere that the loser usually pays both
parties' legal costs, and where it's relatively easy to get lawyers to work on
contingency).

~~~
bonyt
In the US, anyway, liquidated damages clauses like this in a contract
(licenses are contracts) are only enforced if they are a reasonable estimate
of the damages expected for a breach when the actual damages would be hard to
calculate. Penalty damages are not enforced.

[http://blogs.findlaw.com/law_and_life/2013/05/what-are-
liqui...](http://blogs.findlaw.com/law_and_life/2013/05/what-are-liquidated-
damages.html)

------
numair
This is a real nuisance, but the author seems to be going about it in the
wrong way (which is confusing, because the author is a super-long-time
NeXT/Obj-C developer who probably has contacts at Apple to help resolve the
issue). I'm subscribed to all of the relevant Apple mailing lists for
Cocoa/Obj-C and yet the first I've heard about this issue is through a blog
linked on Hacker News; why? Why not have a friendly conversation about Apple
regarding their use of open source Obj-C code, and the problems it creates
with their method blacklist? The fact that Apple is using mogenerator is a
good thing, isn't it?

It seems that an interim solution would be to patch mogenerator to generate a
different name/prefix for these methods, with the name set via an option flag
or something. If the author would rather wage a religious war with Apple over
this, well, time to fork... (And if someone creates such a solution, it'd be
great if you could post a link here!)

(Retzsch probably has good reasons, based on past interactions, on why he's
going about things this way, but we've got to be pragmatic here.)

\--

EDIT: Since it seems that people aren't familiar with them, here is a link to
Apple's mailing lists. Browse the archives and you'll see that Apple engineers
do, in fact, read and reply to things on there.

[https://lists.apple.com/mailman/listinfo](https://lists.apple.com/mailman/listinfo)

~~~
lnanek2
You claim otherwise, but it is generally not possible to have a meaningful
discussion about why your app is rejected. Even when you do the person you are
communicating with is not an engineer, just someone going through a checklist.
As someone with some iOS apps out there, my only chance to communicate with an
engineer is to go to wwdc.

~~~
coob
Or raising a DTS issue, of which you get 2 per year as part of your iOS
developer account and can buy more.

~~~
teacup50
Which also will not, in most circumstances, illicit a useful response.

Could Apple-enamored newbies please stop trying to tell multi-decade Apple
developers how to deal with Apple?

~~~
coob
1) I was referring to the last sentence's notion of the only way of
communicating with an Apple engineer is at WWDC. You can talk to engineers via
DTS if it gets bumped up enough.

2) I wasn't aware of the need to post a photo of me with my SE/30 and
HyperCard manuals before commenting on Apple development issues.

------
andymoe
How about we open a radar? Is there one yet? The engineers who read those are
not entirely unreasonable... just really busy.

~~~
comex
Or have the build system check if the SDK name ends in ".internal" and change
the name and/or complain if so.

Seriously, adding licensing requirements is silly when most likely the
engineers responsible just need to know what's going on.

~~~
mwfunk
comex's second comment pretty much sums up the whole situation. It's bizarre
that anyone even has other ideas at this point.

------
eurleif
Unfortunately, licensing restrictions like that would make it incompatible
with the GPL. One way around that would be dual licensing: allow people to use
either the special MIT-but-no-Apple license, or the GPL. Presumably Apple
wouldn't touch the GPL option.

~~~
lnanek2
Why do you think the GPL matters? This is MIT licensed and the GPL is
incompatible with the app store anyway, so no one can use it. See the removal
of VLC.

~~~
eurleif
>the GPL is incompatible with the app store anyway

This project works on OS X, not just iOS.

~~~
kennywinker
The issue is with the App Store. Apple can't ban you from using a "private"
selector on the Mac, but they can ban you from using a "private" selector on
the Mac App Store.

~~~
eurleif
Right, but presumably they want to have one library that can be used both in
projects built for the app store and in projects not built for the app store.

------
chrisdevereux
So if Apple have a private class with a method called 'invalidate' and I also
have a method called 'invalidate', I go on the naugty list?

That sounds crazy. Wouldn't it make sense to keep a list of private classes
rather than private selectors?

~~~
pornel
In Objective-C selectors are not really tied to classes. The runtime doesn't
care about classes — it can send any selector to any object.

Cocoa even creates subclasses at runtime and changes classes of existing
object instances. It's pretty much as dynamic as JavaScript.

~~~
chrisdevereux
Sure, but to access a private class, I'd typically need to message the class
to obtain an instance. I could obsfucate my access of the class, but equally I
could obsfucate obtaining the selector.

The fact that selectors aren't tied to classes is exactly the reason this is
so insane, as the example above (and the OP's) show!

~~~
pornel
> Sure, but to access a private class, I'd typically need to message the class
> to obtain an instance

Apple is also (and probably most) worried about you messing with objects
borrowed from/exposed by Cocoa, so looking for calls to [Class alloc] is not
enough.

> I could obsfucate my access of the class, but equally I could obsfucate
> obtaining the selector.

The problem is that after compilation _every_ call is obfuscated. Compilation
throws away types, so all you're left with is tons of identical function calls
with generic pointers pointing to `isa` structures that aren't definitive at
compile time. I imagine this is really hard to statically analyze, especially
that you can easily "launder" origin of objects by passing them through
containers like NSArray, notifications, etc.

~~~
chrisdevereux
Well, the objects they _really_ don't want you using (that grant access to
resources with no public API) are often exposed as shared instances via class
methods. This is actually the case with PhotoLibraryServices, the framework
with these private methods[1].

In general, I agree with what you're saying. My point here is really just this
approach to detecting private API usage is obviously going to throw up loads
of false positives. I get that they'd rather have false positives than false
negatives, but it doesn't make it any less annoying.

[1] [https://github.com/JaviSoto/iOS7-Runtime-
Headers/blob/master...](https://github.com/JaviSoto/iOS7-Runtime-
Headers/blob/master/PrivateFrameworks/PhotoLibraryServices.framework/PLManagedObjectContext.h)

------
mtford
Has anyone actually been rejected for this yet? How do we know there isn't a
whitelist already? We're submitting in a weeks time - with mogen - so I guess
there is only one way to find out...

~~~
tonyarnold
Nobody is being rejected for this issue — Apple seems to be ignoring it as
overzealousness from the validator. It's just a validation warning, but you'd
be amazed how upset some developers get about it.

We've had numerous issues filed about it on the MagicalRecord issue tracker
(which is what prompted me to hassle Wolf about it in the first place).

------
mattyohe
Eh, while Apple is using it, we have yet to have a rejection due to this. I'll
hold my complaints until Apple actually rejects apps.

~~~
icambron
Warnings are problematic enough:
[https://github.com/magicalpanda/MagicalRecord/commit/723827e...](https://github.com/magicalpanda/MagicalRecord/commit/723827ec37498fa9c0a0a742a3ca48f41b756feb)

~~~
tonyarnold
I decided to roll that commit back — I'm hopeful Apple's going to whitelist
the APIs early next week (and honestly, it's an otherwise unnecessary API
change).

------
alayne
This issue makes more sense if you just read the Github thread:
[https://github.com/magicalpanda/MagicalRecord/pull/74](https://github.com/magicalpanda/MagicalRecord/pull/74)

------
nwp90
Why not just add a means of invoking it such that it generates "special"
method names when used by Apple, and (if necessary) use the license to require
that they use them?

------
twic
How about putting some distinctive string in the generated method name? Like:

    
    
      [MyEntity insertMyEntityInManagedObjectContext:moc];
    

Yes, it's redundant and crappy. But it's not a disaster and it should avoid
the great stamping boot of Apple.

~~~
LeoNatan25
When Apple upgrades their code, they'll have the same "distinctive string" and
the cycle continues. Or do you suggest people go in potentially tens or
hundreds of classes and change manually the methods and their use?

~~~
kennywinker
If the entity name is part of the method name, it'll be different so long as
you don't overlap entity names with Apple.

It'd be a lot of work for devs to change code that calls those methods, but
not so much it's not a possible solution. I'm optimistic someone inside Apple
will address this issue on their end, but if that fails this sounds like a
possible workable solution.

~~~
gress
Apple is incorporating his open source project. Whatever names he uses, they
will use when they pull the latest version.

~~~
paxswill
The name wouldn't be static. To try to make it more obvious:

    
    
        [CLASSNAME insertCLASSNAMEInManagedObjectContext:moc]

------
badman_ting
I don't see what's so bad about excluding Apple in the license. I mean,
they're not really playing nice here. Perhaps unintentionally so, but if
that's how they want to carry it then they can write their own thing for the
Photo framework.

~~~
mwfunk
Please explain how they're not being nice here.

~~~
kennywinker
Effectively banning a commonly used tool from the app store because they use
it internally. It's a bit of an "I'm taking your ball and going home" kind of
a situation.

~~~
gress
They aren't banning it because they use it internally.

They aren't banning it at all. This is an accident.

~~~
bigiain
So they "accidentally" took this guy's ball and went home. Which has resulted
in an effective "automated banning" of the guy's tool.

I'm half inclined to suggest that publicly outing that kind of behaviour on
your own blog is _exactly_ the right response to that sort of "accident". When
their "accident" has some quite serious consequences for everybody except the
people who carelessly allowed the accident to happen, and when the people who
need to fix the "accident" are hidden behind Apple's legendarily un-
approachable app store review process - "public shaming" seems like an
entirely appropriate reaction.

~~~
gress
Are you seriously saying they did this on purpose?

~~~
Dylan16807
Negligently, not on purpose, but not 'truly' an accident.

~~~
gress
This is clearly not negligence. It's an exotic scenario.

------
seivan
I use Mogenerator to just generate the entities. Not actually use the methods.

------
mwfunk
I don't understand, what's the problem exactly? Is this against Mogenerator's
license (it doesn't appear so)? The article described a hypothetical scenario
in which an app using Mogenerator might get incorrectly rejected for using
private methods, but there wasn't any evidence that this has or will happen,
or if it did happen that it would be anything other than an easily corrected
mistake. I must be missing something.

~~~
miweiss
I've had an app rejected from the selector search the article mentions. As the
article says though, I'm sure it's within apple's power to ignore them,
especially if lots of existing apps use it.

~~~
robterrell
Actually rejected because your app had a MOGenerator selector? Details,
please. That adds a lot of information to this story.

~~~
kennywinker
I believe he's saying he's had an app rejected because of a selector conflict,
not specifically a selector conflict involving mogenerator.

E.g. he calls `-(void)someMethodWithTheSameNameAsAnApplePrivateMethod` in his
code, and App Review rejects it because their tools are telling them he's
calling a private method.

------
stefan_kendall3
Change the license, exclude apple, and send them a CnD if they use the library
going forward.

It's probably faster and more reliable to do this than file a radar.

~~~
gress
But then it would be the author being hostile and destructive, when this is
clearly an accident.

------
andyzweb
it might be worth looking at using a different kind of license:
[https://www.gnu.org/copyleft/gpl.html](https://www.gnu.org/copyleft/gpl.html)
comes to mind.

~~~
tfinniga
That would stop apple from using it.

Would probably stop most current users as well.

------
lordmatty
Good thought, but Apple is the gatekeeper here - not sure changing your
license will help. What if they continue to use the methods without using
Mogenerator (they could easily write their own categories to implement the
methods for example)?

~~~
pdpi
Idea is that the next version of mogenerator uses new method names, and that
version says "Apple can't use this". Apple has no motivation to change the
method names they use to match the new mogenerator if they're not using it, so
nobody else is affected.

