Apple Claims Mogenerator's Methods
rentzsch.tumblr.com
rentzsch.tumblr.com
http://blogs.findlaw.com/law_and_life/2013/05/what-are-liqui...
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.
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'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.
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.
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.
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...
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.
Could Apple-enamored newbies please stop trying to tell multi-decade Apple developers how to deal with Apple?
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.
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.
Seriously, adding licensing requirements is silly when most likely the engineers responsible just need to know what's going on.
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.
This project works on OS X, not just iOS.
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.
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?
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.
That sounds crazy. Wouldn't it make sense to keep a list of private classes rather than private selectors?
Cocoa even creates subclasses at runtime and changes classes of existing object instances. It's pretty much as dynamic as JavaScript.
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!
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.
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...
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).
[MyEntity insertMyEntityInManagedObjectContext:moc];
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.
[CLASSNAME insertCLASSNAMEInManagedObjectContext:moc]They aren't banning it at all. This is an accident.
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.
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.
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)
It's probably faster and more reliable to do this than file a radar.
Would probably stop most current users as well.