9 ms·

Apple Claims Mogenerator's Methods

176 points by chmars 13y ago

archagon 13y ago
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 13y ago
  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 13y ago
    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-liquidated-damages.html http://blogs.findlaw.com/law_and_life/2013/05/what-are-liqui...
    - deleted 13y ago
      [deleted]
- jjmanton 13y ago
  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.
  - archagon 13y ago
    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.
lordmatty 13y ago
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)?
- lukegb 13y ago
  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.
- pdpi 13y ago
  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.
twic 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      Apple is incorporating his open source project. Whatever names he uses, they will use when they pull the latest version.
      - paxswill 13y ago
        The name wouldn't be static. To try to make it more obvious: [CLASSNAME insertCLASSNAMEInManagedObjectContext:moc]
      - twic 13y ago
        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.
andymoe 13y ago
How about we open a radar? Is there one yet? The engineers who read those are not entirely unreasonable... just really busy.
- comex 13y ago
  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 13y ago
    comex's second comment pretty much sums up the whole situation. It's bizarre that anyone even has other ideas at this point.
- Alphasite_ 13y ago
  It feels like the only unreasonable party is the author.
  - Gigablah 13y ago
    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?
    - bigiain 13y ago
      "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).
      - 13y ago
seivan 13y ago
I use Mogenerator to just generate the entities. Not actually use the methods.
badman_ting 13y ago
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 13y ago
  Please explain how they're not being nice here.
  - kennywinker 13y ago
    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 13y ago
      [deleted]
    - gress 13y ago
      They aren't banning it because they use it internally. They aren't banning it at all. This is an accident.
      - bigiain 13y ago
        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.
        13y ago
andyzweb 13y ago
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 13y ago
  That would stop apple from using it. Would probably stop most current users as well.
- deleted 13y ago
  [deleted]
- tonyarnold 13y ago
  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.
eurleif 13y ago
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 13y ago
  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 13y ago
    >the GPL is incompatible with the app store anyway This project works on OS X, not just iOS.
    - coldtea 13y ago
      "This is MIT licensed"
      - eurleif 13y ago
        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.
        coldtea 13y ago
        So? Why should the developers care about GPL projects?
        streptomycin 13y ago
        The MIT license is typically used by people who want their code to be broadly used.
mattyohe 13y ago
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 13y ago
  Warnings are problematic enough: https://github.com/magicalpanda/MagicalRecord/commit/723827ec37498fa9c0a0a742a3ca48f41b756feb https://github.com/magicalpanda/MagicalRecord/commit/723827e...
  - tonyarnold 13y ago
    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).
- coldtea 13y ago
  Just above you: "miweiss: I've had an app rejected from the selector search the article mentions."
mtford 13y ago
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 13y ago
  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).
stefan_kendall3 13y ago
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 13y ago
  But then it would be the author being hostile and destructive, when this is clearly an accident.
mwfunk 13y ago
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 13y ago
  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 13y ago
    Actually rejected because your app had a MOGenerator selector? Details, please. That adds a lot of information to this story.
    - kennywinker 13y ago
      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.
- deleted 13y ago
  [deleted]
- paulgb 13y ago
  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)
nwp90 13y ago
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?
numair 13y ago
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
- mikeash 13y ago
  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.
  - numair 13y ago
    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 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.
alayne 13y ago
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
chrisdevereux 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      > 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 13y ago

176 points by chmars 13y ago

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 13y ago
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 13y ago
  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-liquidated-damages.html http://blogs.findlaw.com/law_and_life/2013/05/what-are-liqui...
  - deleted 13y ago
    [deleted]
jjmanton 13y ago
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.
- archagon 13y ago
  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.

lordmatty 13y ago

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)?

lukegb 13y ago
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.
pdpi 13y ago
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.

twic 13y ago

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 13y ago
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 13y ago
  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 13y ago
    Apple is incorporating his open source project. Whatever names he uses, they will use when they pull the latest version.
    - paxswill 13y ago
      The name wouldn't be static. To try to make it more obvious: [CLASSNAME insertCLASSNAMEInManagedObjectContext:moc]
    - twic 13y ago
      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.

andymoe 13y ago

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

comex 13y ago
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 13y ago
  comex's second comment pretty much sums up the whole situation. It's bizarre that anyone even has other ideas at this point.
Alphasite_ 13y ago
It feels like the only unreasonable party is the author.
- Gigablah 13y ago
  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?
  - bigiain 13y ago
    "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).
    - 13y ago

seivan 13y ago

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

badman_ting 13y ago

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 13y ago
Please explain how they're not being nice here.
- kennywinker 13y ago
  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 13y ago
    [deleted]
  - gress 13y ago
    They aren't banning it because they use it internally. They aren't banning it at all. This is an accident.
    - bigiain 13y ago
      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.
      - 13y ago

andyzweb 13y ago

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 13y ago
That would stop apple from using it. Would probably stop most current users as well.
deleted 13y ago
[deleted]
tonyarnold 13y ago
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.

eurleif 13y ago

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 13y ago
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 13y ago
  >the GPL is incompatible with the app store anyway This project works on OS X, not just iOS.
  - coldtea 13y ago
    "This is MIT licensed"
    - eurleif 13y ago
      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.
      - coldtea 13y ago
        So? Why should the developers care about GPL projects?
        streptomycin 13y ago
        The MIT license is typically used by people who want their code to be broadly used.

mattyohe 13y ago

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 13y ago
Warnings are problematic enough: https://github.com/magicalpanda/MagicalRecord/commit/723827ec37498fa9c0a0a742a3ca48f41b756feb https://github.com/magicalpanda/MagicalRecord/commit/723827e...
- tonyarnold 13y ago
  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).
coldtea 13y ago
Just above you: "miweiss: I've had an app rejected from the selector search the article mentions."

mtford 13y ago

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 13y ago
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).

stefan_kendall3 13y ago

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 13y ago
But then it would be the author being hostile and destructive, when this is clearly an accident.

mwfunk 13y ago

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 13y ago
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 13y ago
  Actually rejected because your app had a MOGenerator selector? Details, please. That adds a lot of information to this story.
  - kennywinker 13y ago
    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.
deleted 13y ago
[deleted]
paulgb 13y ago
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)

nwp90 13y ago

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?

numair 13y ago

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

mikeash 13y ago
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.
- numair 13y ago
  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 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.

alayne 13y ago

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

chrisdevereux 13y ago

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 13y ago
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 13y ago
  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 13y ago
    > 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 13y ago