The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change.
Next Steps
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple’s private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library’s source, you may be able to search the compiled binary using “strings” or “otool” command line tools. The “strings” tool can output a list of the methods that the library calls and “otool -ov” will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you’re doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions.
For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter.
Could well be a plugin that causes this (even if you do not use some features of it).
I had this too with dtPlugins, Jean-Paul had to strip things to get it accepted.
For my current project the only class missing was NSPredicateMBS, but I suspect other projects that rely on the classes within these plugins may trigger errors.
Last news. Yesterday, before I got the new plugins, I simply generated a 32 bits build, and uploaded it to the MAS. It went through just fine and is now on sale. Apparently, grand fathered applications do not need 64 bit just yet.
Yep, I confirm. My grand fathered apps still get accepted as 32 bit. If I recollect right, this should be OK until June, then grandfathers will get the same treatment as babies.