Apple Claims Mogenerator's Methods(rentzsch.tumblr.com)
rentzsch.tumblr.com
Apple Claims Mogenerator's Methods
http://rentzsch.tumblr.com/post/82453434093/apple-claims-mogenerators-methods
92 comments
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?
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).
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-liqui...
[deleted]
I'm not an expert on licensing, but couldn't Apple continue using the current version of mogenerator? A license change would only prevent them from taking latest.
Right, but that would mean that mogenator could change the names of the class methods (or add additional ones) without having to worry that Apple would adopt them in a later update and thus render the whole exercise moot.
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
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
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.
Or raising a DTS issue, of which you get 2 per year as part of your iOS developer account and can buy more.
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?
Could Apple-enamored newbies please stop trying to tell multi-decade Apple developers how to deal with Apple?
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.
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.
Reminds me of my time (10+ years) as a Microsoft developer.
People who cite "professional support" as a benefit of closed systems like Apple's and Microsoft's have either never experienced it, or work for an organisation with the sort of clout that gets you access to people who can actually help.
People who cite "professional support" as a benefit of closed systems like Apple's and Microsoft's have either never experienced it, or work for an organisation with the sort of clout that gets you access to people who can actually help.
The TS in DTS stands for Technical Support. They don't help with app review problems.
Contacts with the app review team are scarce, and they can be obstinate even if you do manage to find somebody to talk to. That whole area is straight out of Kafka.
There's the (relatively) micro-scale issue of individual apps being rejected, and the macro-scale issue of Apple utilizing open source projects and putting their methods in their list of private, disallowed method names. This seems like the exact sort of macro-scale issue for which Apple maintains mailing lists viewed by actual engineers.
I just don't see how publicly attacking Apple over this is going to lead to any sort of positive situation, especially for the author and his relationship with people at Apple. Mogenerator is super-useful, but if it's going to be the centerpiece of some sort of political statement regarding Apple's policies, developers such as myself are going to have to look elsewhere to get their work done.
--
EDIT: I'm sure you already know about these mailing lists...? https://lists.apple.com/mailman/listinfo ... The fact that you guys want to publicly attack Apple over this, while staking your entire careers on developing for Apple's platforms, is insanity. A course on politics is in order.
I just don't see how publicly attacking Apple over this is going to lead to any sort of positive situation, especially for the author and his relationship with people at Apple. Mogenerator is super-useful, but if it's going to be the centerpiece of some sort of political statement regarding Apple's policies, developers such as myself are going to have to look elsewhere to get their work done.
--
EDIT: I'm sure you already know about these mailing lists...? https://lists.apple.com/mailman/listinfo ... The fact that you guys want to publicly attack Apple over this, while staking your entire careers on developing for Apple's platforms, is insanity. A course on politics is in order.
How is doing a blog post that will be seen by the relevant engineers different to posting to the Apple Developer mailing lists?
This wasn't disclosure of a security flaw, or anything that was going to cause damage to Apple or it's users. Personally, I don't have a problem with things like this being used for professional gain — Jon did the legwork to figure out where the problem was, and wrote it up. Kudos to him.
There's a limit to all politicking, especially when you're dealing with an organisation like Apple. There are no reliable, responsive channels for effecting change at Apple. First person to suggest radar gets a kick in the unmentionables.
This wasn't disclosure of a security flaw, or anything that was going to cause damage to Apple or it's users. Personally, I don't have a problem with things like this being used for professional gain — Jon did the legwork to figure out where the problem was, and wrote it up. Kudos to him.
There's a limit to all politicking, especially when you're dealing with an organisation like Apple. There are no reliable, responsive channels for effecting change at Apple. First person to suggest radar gets a kick in the unmentionables.
Which engineers maintain the private API scanner? What mailing list do they hang out on?
I've been in the community a long time and I have no idea about either one. They are effectively anonymous and uncontactable as far as I know.
Publicly attacking Apple is actually the only way I know to actually start the conversation. If you know a better way then I would sincerely like to hear it, but you need to provide specifics, not just assumptions that it must be possible.
Response to your edit: give me specifics. Yes, I know about those mailing lists. They are useless for this. None of those host anyone who has anything to do with App Store review. Give me an exact email address or a contact form or a phone number or something that you know actually goes to the right people here, or admit that you don't know how. Insisting that it must be possible without saying how when others with more experience are saying that it is not is just embarrassing.
I've been in the community a long time and I have no idea about either one. They are effectively anonymous and uncontactable as far as I know.
Publicly attacking Apple is actually the only way I know to actually start the conversation. If you know a better way then I would sincerely like to hear it, but you need to provide specifics, not just assumptions that it must be possible.
Response to your edit: give me specifics. Yes, I know about those mailing lists. They are useless for this. None of those host anyone who has anything to do with App Store review. Give me an exact email address or a contact form or a phone number or something that you know actually goes to the right people here, or admit that you don't know how. Insisting that it must be possible without saying how when others with more experience are saying that it is not is just embarrassing.
You work at Plausible Labs, right? Have you noticed the class prefix they're using?
https://github.com/JaviSoto/iOS7-Runtime-Headers/tree/master...
I really hope they don't decide that the framework needs its own crash reporter class...
https://github.com/JaviSoto/iOS7-Runtime-Headers/tree/master...
I really hope they don't decide that the framework needs its own crash reporter class...
Oh lord. Thank you for the heads up.
Why would you expect anyone in that position to expose themselves publicly? Although they could give useful feedback, it wouldn't be in their interest to deal with these issues outside of a formal process. Unless of course it's in their job title to handle developer relations. Even then it'd be more setting up coordination and less anything technical.
Granted without knowing what exactly that process could be accessed or what it is, I agree that you need to do something to "start the conversation." However, attacking is unlikely to achieve the results you want. This is especially true considering the imbalance in your relationship with Apple. I've worked a number of years in enterprise software and for large enterprises. You have to learn how to bring attention to issues and escalate them constructively and professionally. You also learn that you don't always get what you want.
Do the blog posts but be aware of the tone. Use the mailing lists. Get others to raise their voice and show that it isn't an isolated incident.
In the meantime, since the issue is out there and details are known, workarounds need to be figured out that can be implemented. Short-term, there should be things that can be done by app developers. Longer-term, a solution probably needs to be put in place in the project that will address the needs of both app developers and Apple. (Apple dropping use of the project may be a possibility but I don't see that as a win for anyone.)
Also realize that an app developer "losing an entire afternoon" is minor in the grand scheme of things. However inconvenient it may be to be that developer, unless it's an absolute show-stopper, any reaction or solution will take time if one is implemented at all.
Granted without knowing what exactly that process could be accessed or what it is, I agree that you need to do something to "start the conversation." However, attacking is unlikely to achieve the results you want. This is especially true considering the imbalance in your relationship with Apple. I've worked a number of years in enterprise software and for large enterprises. You have to learn how to bring attention to issues and escalate them constructively and professionally. You also learn that you don't always get what you want.
Do the blog posts but be aware of the tone. Use the mailing lists. Get others to raise their voice and show that it isn't an isolated incident.
In the meantime, since the issue is out there and details are known, workarounds need to be figured out that can be implemented. Short-term, there should be things that can be done by app developers. Longer-term, a solution probably needs to be put in place in the project that will address the needs of both app developers and Apple. (Apple dropping use of the project may be a possibility but I don't see that as a win for anyone.)
Also realize that an app developer "losing an entire afternoon" is minor in the grand scheme of things. However inconvenient it may be to be that developer, unless it's an absolute show-stopper, any reaction or solution will take time if one is implemented at all.
The developer who lost an afternoon was me, not Jon. I'm pretty sure the community is used to me having an overly dramatic tweet about everything that annoys me by now. It is minor, and you're right: it'll probably result in no action required from anyone come Monday.
Where did I say that I expect anything?
Past experience with Apple shows that this sort of public attack is the only way that's at all effective to get some sort of fix.
You say that we have to learn how to bring attention to issues. We have, and this is the result. I don't understand why that's so hard to believe.
Once again, if you think you have a better way, I'm all ears, but I need specific suggestions, not useless vague advice to talk to them, as if nobody ever thought of that or tried it before.
Past experience with Apple shows that this sort of public attack is the only way that's at all effective to get some sort of fix.
You say that we have to learn how to bring attention to issues. We have, and this is the result. I don't understand why that's so hard to believe.
Once again, if you think you have a better way, I'm all ears, but I need specific suggestions, not useless vague advice to talk to them, as if nobody ever thought of that or tried it before.
How about we open a radar? Is there one yet? The engineers who read those are not entirely unreasonable... just really busy.
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.
Seriously, adding licensing requirements is silly when most likely the engineers responsible just need to know what's going on.
comex's second comment pretty much sums up the whole situation. It's bizarre that anyone even has other ideas at this point.
It feels like the only unreasonable party is the author.
It feels like shoddy work by Apple engineers, actually. Seriously, making use of an open source library and breaking it (indirectly) for everyone else in the process?
"Shoddy work" is maybe a little over-the-top, but I certainly agree that they've screwed up here by not thinking through the implications of the system within which they've made all their design/coding choices (or considering the impenetrability of the system to outside developers, who's work they're happy to use, but who then have very few other workable option except "public shaming" when this sort of unintended consequence occurs).
The other options include:
1. Filing a Radar.
2. Using a DTS incident.
3. Emailing a platform evangelist.
Seems like quite a lot can be tried before "public shaming" becomes the only option.
1. Filing a Radar.
2. Using a DTS incident.
3. Emailing a platform evangelist.
Seems like quite a lot can be tried before "public shaming" becomes the only option.
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.
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.
>the GPL is incompatible with the app store anyway
This project works on OS X, not just iOS.
This project works on OS X, not just iOS.
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.
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.
"This is MIT licensed"
Right, and the MIT license is GPL compatible, so people can incorporate this project into GPL projects. But they're considering adding anti-Apple restrictions to their license, which would make it GPL incompatible.
So? Why should the developers care about GPL projects?
The MIT license is typically used by people who want their code to be broadly used.
How about a license that was "MIT, unless you're Apple in which case it's GPL"? Wouldn't that be compatible with the GPL? You would be effectively barring Apple from using it, as they won't use GPL code inside `PhotoLibraryServices.framework`.
IANAL, but I don't think that would be GPL compatible. You're only explicitly allowing Apple to use it under the GPL, not other parties. And even though "unless you're Apple in which case it's the GPL" involves the GPL, it's still a licensing restriction which is not included in the GPL.
[deleted]
Who cares?
The GPL's compatibility clauses are a pain for everyone, and in return the GPL provides nothing to anyone not already using it.
Maybe we should intentionally poison-pill our open source licenses to be GPLv3-incompatible; after all, the GPL is designed to actively leverage network effects to establish monopoly control over how the rest of us share code.
Responding with the same tactics seems fair.
The GPL's compatibility clauses are a pain for everyone, and in return the GPL provides nothing to anyone not already using it.
Maybe we should intentionally poison-pill our open source licenses to be GPLv3-incompatible; after all, the GPL is designed to actively leverage network effects to establish monopoly control over how the rest of us share code.
Responding with the same tactics seems fair.
> Responding with the same tactics seems fair.
So you are going to combat the network effects that would establish monopoly control over how people share code by...trying to establish monopoly control over how people share code? Doesn't that seem a wee bit hypocritical to you?
So you are going to combat the network effects that would establish monopoly control over how people share code by...trying to establish monopoly control over how people share code? Doesn't that seem a wee bit hypocritical to you?
Seeing as only people who use the GPL would be affected in this hypothetical, no.
And the GPL only affects people who want to write proprietary software. How is the GPL somehow more evil than proprietary software in your worldview?
> And the GPL only affects people who want to write proprietary software.
A GPL-incompatible license isn't proprietary.
> How is the GPL somehow more evil than proprietary software in your worldview?
In the same way that communism is more evil than capitalism.
A GPL-incompatible license isn't proprietary.
> How is the GPL somehow more evil than proprietary software in your worldview?
In the same way that communism is more evil than capitalism.
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?
That sounds crazy. Wouldn't it make sense to keep a list of private classes rather than private selectors?
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.
Cocoa even creates subclasses at runtime and changes classes of existing object instances. It's pretty much as dynamic as JavaScript.
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!
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!
> 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.
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.
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...
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...
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...
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).
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).
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.
Warnings are problematic enough: https://github.com/magicalpanda/MagicalRecord/commit/723827e...
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).
Just above you: "miweiss: I've had an app rejected from the selector search the article mentions."
This issue makes more sense if you just read the Github thread: https://github.com/magicalpanda/MagicalRecord/pull/74
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?
How about putting some distinctive string in the generated method name? Like:
[MyEntity insertMyEntityInManagedObjectContext:moc];
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?
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.
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.
Apple is incorporating his open source project. Whatever names he uses, they will use when they pull the latest version.
The name wouldn't be static. To try to make it more obvious:
[CLASSNAME insertCLASSNAMEInManagedObjectContext:moc]Sorry i didn't make this clearer. I was suggesting that the class name could be used in the method name. As long as nobody names their classes the same as Apple, their method names will also be different.
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.
Please explain how they're not being nice here.
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.
[deleted]
They aren't banning it because they use it internally.
They aren't banning it at all. This is an accident.
They aren't banning it at all. This is an accident.
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.
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.
Are you seriously saying they did this on purpose?
Negligently, not on purpose, but not 'truly' an accident.
This is clearly not negligence. It's an exotic scenario.
I use Mogenerator to just generate the entities. Not actually use the methods.
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.
I'm not an Objective-C developer but it looks like modgenerator is a code generation tool that (among other things) generates helper methods. Apple used this in one of their own frameworks, which is completely within the license, but the helper methods ended up on a blacklist for apps submitted to the app store. Using APIs on the blacklist apparently won't guarantee that an app gets rejected (if I've learned anything from HN it's that iOS App Store rejections are notoriously inconsistent).
The author of this article (and modgenerator) is (perhaps facetiously) considering changing the license so that Apple can't use it in order that they generate other accessors which are not blacklisted.
(Again, this is all my non-Objective-C-developer understanding, so corrections are appreciated)
The author of this article (and modgenerator) is (perhaps facetiously) considering changing the license so that Apple can't use it in order that they generate other accessors which are not blacklisted.
(Again, this is all my non-Objective-C-developer understanding, so corrections are appreciated)
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.
Actually rejected because your app had a MOGenerator selector? Details, please. That adds a lot of information to this story.
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.
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.
[deleted]
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.
It's probably faster and more reliable to do this than file a radar.
But then it would be the author being hostile and destructive, when this is clearly an accident.
it might be worth looking at using a different kind of license: https://www.gnu.org/copyleft/gpl.html comes to mind.
That would stop apple from using it.
Would probably stop most current users as well.
Would probably stop most current users as well.
mouth fart noise if you use GPL for your code on OS X/iOS, nobody will use it due to earlier issues with submitting GPL apps to the App Stores. Friends don't let friends GPL.
[deleted]
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)?
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.
That's not the point - the point is to stop them from updating to a new version and blacklisting the new method names. They already have a license that allows them to use the existing code.