Referenced non-public APIs which caused AppStore rejection.

[apersaud]

First of all, great work on MagicalRecord. Coming from a ruby background, it made CoreData a whole lot easier.

I had issues submitting my application this weekend and Apple's ApplicationLoader (the new one which scans private APIs) flagged the methods in this commit as issues (which caused rejection of binary). The error from Apple was:

The app references non-public selectors in PocketSalsa.app/ PocketSalsa: entityInManagedObjectContext:, insertInManagedObjectContext.

After editing my fork and making sure my edits worked, I resubmitted it and the binary it was finally accepted. There is probably a better fix for this, but I'm not an expert on MagicalRecord as you are.

Thanks.

[sibartlett]

I see that these methods are from mogenerator.

I'm guessing that @apersaud didn't use mogenerator; and by not doing so - these methods have not been publicly declared in his project nor in Apple's Core Data framework. Hence Apple deems these calls as non-public, simply as they haven't been declared anywhere at all.

Perhaps all you have to do is create a protocol in MagicalRecord, as below, to 'publicly declare' these methods. Then Apple might accept the rejected method calls.

@protocol MogeneratorStubs <NSManagedObject> 
+ (NSEntityDescription*)entityInManagedObjectContext:(NSManagedObjectContext*)moc_;
+ (id)insertInManagedObjectContext:(NSManagedObjectContext*)moc_;
@end

Anyways, I'd also like to say thanks for writing this library. I've only been using Objective-C and the iOS-SDK for a week and have found MagicalRecord a pleasure to use. Keep up the good work!

[apersaud]

I followed the directions on how to include MagicalRecord files into my project. Should the be updated to show something different like using mogenerator?

I would be nice to know if anyone else got the warning when submitting to AppStore.

On Oct 16, 2011, at 11:45 AM, Simon Bartlettreply@reply.github.com wrote:

I see that these methods are from mogenerator.

I'm guessing that @apersaud didn't use mogenerator; and by not doing so - these methods have not been publicly declared in his project nor in Apple's Core Data framework. Hence Apple deems these calls as non-public, simply as they haven't been declared anywhere at all.

Perhaps all you have to do is create a protocol in MagicalRecord, as below, to 'publicly declare' these methods. Then Apple might accept these methods as you would've 'publicly declared' them.

@@protocol MogeneratorStubs <NSManagedObject> 
+ (NSEntityDescription*)entityInManagedObjectContext:(NSManagedObjectContext*)moc_;
+ (id)insertInManagedObjectContext:(NSManagedObjectContext*)moc_;
@end

Anyways, I'd also like to say thanks for writing this library. I've only been using Objective-C and the iOS-SDK for a week and have found MagicalRecord a pleasure to use. Keep up the good work!

Reply to this email directly or view it on GitHub:
#74 (comment)

[sibartlett]

I think the problem can be solved simply, by the MagicalRecord team including the protocol I wrote above in their codebase, but that's just my hunch though.

The protocol serves no purpose other than making the methods publicly declared.

If my solution is acceptable, the installation instructions would stay the same.

[mellelieuwes]

I've had the same warning totday when submitting to the AppStore.

[casademora]

I talked with a contact at Apple recently, and the word is there have been some false positives in this area now that iOS5 is also being checked. I believe this was one of those false positives, as this is the first and only time I've heard of anyone being rejected from either AppStore for using MagicalRecord. I've shipped several apps with it myself.

I'm not going to accept this change since this is basically a problem with the app review team's toolset at the moment. If this happens again, please send me an email, and we'll try to clear it up with Apple once and for all.

[flypigz]

I have the same issue today, I don't know why..... Is there anyone know how to fix it? This issue has been raised one year ago.....

[msqr]

This happened to me as well. It seems other projects have faced this same problem, and decided to remove the calls to Mogenerator specific additions, e.g.

RestKit/RestKit@a0b9642

It would make it much easier to integrate MR into apps that don't also use Mogenerator if the spirit of this patch were applied, e.g. use use the "fallback" logic already present in these two methods.

[tonyarnold]

I don't see any real downside to remove the mogenerator-specific code. You should not be doing managed object setup or customisation in either of those methods, so the only thing it's doing is saving us a little bit of boilerplate code.

@magicalpanda/team-magicalrecord — any objections to dropping dependencies on mogenerator-derived NSManagedObject methods? In the worst case, we could provide our own prefixed versions of these methods and use those instead (although I think that's largely unnecessary).

[rience]

This warning shows up when submitting app for iOS7, using XCode 5. I modified Core Data files and removed usage of "performSelector" and made sure all of my model classes have "MR_entityName".

I did exactly what @tonyarnold in his pull request and it passed validation, no problems.

[GabrielMassana]

Thanks @tonyarnold. I changed MagicalRecord file as in the pull request and now my app is waiting for review.

[koenvanderdrift]

I just got the same warning when submitting my iOS7 app from Xcode 5: "The app references non-public selectors entityInManagedObjectContext: insertInManagedObjectContext:" I'm using MR release 3.0, without mogenerator.

[tonyarnold]

Wow, @koenvanderdrift you're very, very keen. MagicalRecord 3.0 is very early in it's development — I wouldn't be comfortable shipping it in any of my own apps just yet.

As has been stated a few times before, they're just warnings. All of the apps that have seen this warning have been approved without fanfare, so there's no immediate issue to worry about here (although I'd like to see if we can solve the problems before MR 3 is released).

[koenvanderdrift]

Thanks @tonyarnold, I didn't realize release 3.0 is still very early in development. I guess I got confused since it is called 'release'. Anyway I'll sit and wait and see what happens and post back here.

[tonyarnold]

Yeah, that's our mistake with the naming — sorry about that. I think @casademora is going to move the branch to a more appropriate location shortly. It's early days, and Saul is playing with a bunch of really interesting ideas but he needs to be able to do that without worrying about backwards compatibility or breaking people's builds.

If you're happy to work with an influx API, go for it — we can definitely use the help testing things — but it's not really fit to ship in your apps yet.

[mellelieuwes]

I had the same warning today submitting an iOS7 app to the appstore. I did not use MagicalRecord 3.0

[koenvanderdrift]

Yes same here, I went back to 2.2, and still got the warnings as well.

I'm submitting it anyway, and we'll see.

On Oct 4, 2013, at 11:10 AM, emielvdveen notifications@github.com wrote:

I had the same warning today submitting an iOS7 app to the appstore. I did not use MagicalRecord 3.0

—
Reply to this email directly or view it on GitHub.

[elprl]

Same here, just submitted to Apple with those warnings.

[khawarshzd]

I got the same issue, don't know how to fix properly, for the time being i have commented out both the methods which were causing warnings. If anyone know the best solution please let me know.

• (NSEntityDescription *) MR_entityDescriptionInContext:(NSManagedObjectContext *)context
  {
  // if ([self respondsToSelector:@selector(entityInManagedObjectContext:)])
  // {
  // NSEntityDescription *entity = [self performSelector:@selector(entityInManagedObjectContext:) withObject:context];
  // return entity;
  // }
  // else
  // {
  NSString *entityName = [self MR_entityName];
  return [NSEntityDescription entityForName:entityName inManagedObjectContext:context];
  // }
  }
• (id) MR_createInContext:(NSManagedObjectContext *)context
  {
  // if ([self respondsToSelector:@selector(insertInManagedObjectContext:)])
  // {
  // id entity = [self performSelector:@selector(insertInManagedObjectContext:) withObject:context];
  // return entity;
  // }
  // else
  // {
  return [NSEntityDescription insertNewObjectForEntityForName:[self MR_entityName] inManagedObjectContext:context];
  // }
  }

[koenvanderdrift]

FYI, my app was just approved with these warning.

[Legoless]

I got MR 2.2 installed with CocoaPods and I'm getting 8 warnings for undeclared selectors in iOS 7 app. Is there anything wrong with my configuration or how to get rid of those warnings? They are described below:

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:173:35: warning: undeclared selector 'shouldImport:' [-Wundeclared-selector] if ([self respondsToSelector:@selector(shouldImport:)])

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:175:58: warning: undeclared selector 'shouldImport:' [-Wundeclared-selector] BOOL shouldImport = (BOOL)[self performSelector:@selector(shouldImport:) withObject:objectData];

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:182:35: warning: undeclared selector 'willImport:' [-Wundeclared-selector] if ([self respondsToSelector:@selector(willImport:)])

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:184:32: warning: undeclared selector 'willImport:' [-Wundeclared-selector] [self performSelector:@selector(willImport:) withObject:objectData];

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:186:84: warning: undeclared selector 'MR_valueForUndefinedKey:' [-Wundeclared-selector] MR_swapMethodsFromClass([objectData class], @selector(valueForUndefinedKey:), @selector(MR_valueForUndefinedKey:));

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:192:84: warning: undeclared selector 'MR_valueForUndefinedKey:' [-Wundeclared-selector] MR_swapMethodsFromClass([objectData class], @selector(valueForUndefinedKey:), @selector(MR_valueForUndefinedKey:));

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:193:35: warning: undeclared selector 'didImport:' [-Wundeclared-selector] if ([self respondsToSelector:@selector(didImport:)])

Pods/MagicalRecord/MagicalRecord/Categories/NSManagedObject/NSManagedObject+MagicalDataImport.m:195:32: warning: undeclared selector 'didImport:' [-Wundeclared-selector] [self performSelector:@selector(didImport:) withObject:objectData];

[zardon]

I have the same issue - a boatload of warnings regarding undeclared selectors in iOS7

[alinx]

Hi,

see "New compiler warnings after updating CocoaPods from 0.25 to 0.26"

You can switch this also off if you set the compiler warnings:

[tonyarnold]

For now, you can try the following "fix" if the warnings really bug you. Update the MagicalRecord line in your Podfile like so:

pod 'MagicalRecord', '~> 2.2', :inhibit_warnings => true

I think I got the syntax right for that…

[Legoless]

Please do not write ignore warning techniques as a solution. They are there for a reason. The compiler warnings are not CocoaPod's fault, but MagicalRecord. The pod must be updated to get rid of the warnings.

[tonyarnold]

"For now…"

If you'd like to contribute a fix for this issue, please feel free.

Right now, I don't have time — so what I've suggested is a workaround for the moment. The warnings are harmless in this context.

[Legoless]

I will deploy the fix, if you will verify that my code does not break anything else (I did not yet do a deep down check how MR works). And of course deploy it.

Edit: Created pull request #598 - Added protocols to get rid of Xcode 5 warnings.

[balavec]

Also using 2.2 with the same issues. Will try to submit the app today.

[Legoless]

I can confirm that my application was approved even with these warnings.

[zardon]

Many thanks. I will use the ability to set "undeclared selector" to NO.

[balavec]

So... what do actually those 2 methods do?
It seems they are not declared anywhere ... in one of the previous versions I added following protocol:

@protocol Mogenerator <NSObject>
- (id)entityInManagedObjectContext:(NSManagedObjectContext *)object;
- (id)insertInManagedObjectContext:(NSManagedObjectContext *)object;
@end

and it was forking without any warnings.

Now I use 2.2 version and this protocol is not working any more. So I was thinking that the problem is because the methods are not declared anywhere ... why not declare them?

+ (id)entityInManagedObjectContext:(NSManagedObjectContext *) object { return object; }
+ (id)insertInManagedObjectContext:(NSManagedObjectContext *) object { return object; }

But this might not be a good idea.

So instead I found a new solution and you have to change this:

if ([self respondsToSelector:@selector(insertInManagedObjectContext:)])
{
    id entity = [self performSelector:@selector(insertInManagedObjectContext:) withObject:context];

to this

SEL insertInManagedObjectContextSelector = sel_registerName("insertInManagedObjectContext:");
if ([self respondsToSelector:insertInManagedObjectContextSelector])
{
    id entity = [self performSelector:insertInManagedObjectContextSelector withObject:context];

Do similar also for entityInManagedObjectContext. The warnings in validation are gone. Unfortunately you will see a semantic issue in xCode: "PerformSelector may cause a leak because its selector is unknown".

It is a just workaround. So no solution yet.

[tonyarnold]

The methods are defined by mogenerator, not by MagicalRecord. We make use of them if they exist on your entity subclasses so that you guys don't have to double up on implementing things (although you really shouldn't need to subclass insertInManagedObjectContext or entityInManagedObjectContext:).

There's no easy answer to this — implementing a protocol doesn't force people to adopt it, and your second answer is not a good idea: you're effectively registering the method with the runtime, regardless of it's existence. respondsToSelector: is always going to return true after registering a method in that way.

Can I ask if you guys are defining MR_SHORTHAND and using the shortened (non-MR prefixed) methods?

[balavec]

No, I don't use MR_SHORTHAND.

[Legoless]

I use the MR_SHORTHAND, but it does not change anything apparently.

[tonyarnold]

MR_SHORTHAND was causing conflicts. I may have resolved them recently (it's been a few weeks since I've looked at this code). The easiest answer to all of this is for MagicalRecord to stop relying on mogenerator methods — I can't remember why we don't right now — I'll need to go back and have another look to be sure.

[casademora]

Magicalrecord doesn't rely on those methods..it does check if they exist and use them rather than the default methods. The reason for this is that your entity name and the actual class name can be different. Mogenerator sees this in your model file and maps the two with the methods in question. If you have core data code without mogenerator, do the warnings still appear?

Sent from my iPad

On Feb 4, 2014, at 4:39 AM, Tony Arnold notifications@github.com wrote:

MR_SHORTHAND was causing conflicts. I may have resolved them recently (it's been a few weeks since I've looked at this code). The easiest answer to all of this is for MagicalRecord to stop relying on mogenerator methods — I can't remember why we don't right now — I'll need to go back and have another look to be sure.

—
Reply to this email directly or view it on GitHub.

[ghost]

Yes, I am facing the same issue myself. I can confirm that even if you don't use mogenerator, the warnings still appear. I just submitted my app for review and am crossing my fingers that it would be approved.

[iGranDav]

Same for me today. I've just submitted my app and crossing my fingers too ;-) (with MagicalRecord 2.2)

[ghost]

BTW, mine got approved without any problems. Good luck to you.

Sent from my iPhone

On Feb 26, 2014, at 1:23 AM, David Bonnet notifications@github.com wrote:

Same for me today. I've just submitted my app and crossing my fingers too ;-) (with MagicalRecord 2.2)

—
Reply to this email directly or view it on GitHub.

[rentzsch]

lol.

Grepped /Applications/Xcode.app/Contents/Developer/Platforms for entityInManagedObjectContext. Got a hit on the PhotoLibraryServices.framework iOS private framework.

Popped it open in Hopper. Turns out PhotoLibraryServices uses mogenerator to generate its classes.

http://cl.ly/Uxvt

Doesn't matter if I rename these methods, they're just show up again in the next version of PhotoLibraryServices (assuming Apple upgrades to the latest version of mogenerator) and will be erroneously flagged as non-public all over again.

[tonyarnold]

Oh geez. Thanks mate.

[tonyarnold]

So a little birdy appears to have let @rentzsch know that the mogenerator methods have (finally) been whitelisted! These warnings should disappear automatically. 👍 💣 🍷

[Legoless]

Thats great to hear. Although we've pushed many apps to App Store without rejection.