Mac App Store Publishing Still Broken!
Fal01
Member Posts: 460
@BlackCloakGS,
This is getting a little annoying now, my binary has been rejected again. My Pro has now run out.
Reasons
2.5: Apps that use non-public APIs will be rejected
2.5
The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The app includes _cpu_capabilities from the framework '/usr/lib/libSystem.B.dylib'.
If you have defined a method in your source code with the same name as this API, we suggest altering your method name so that it no longer collides with Apple's private API to avoid your application being flagged in future submissions.
Alternatively, this API 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.
This is getting a little annoying now, my binary has been rejected again. My Pro has now run out.
Reasons
2.5: Apps that use non-public APIs will be rejected
2.5
The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The app includes _cpu_capabilities from the framework '/usr/lib/libSystem.B.dylib'.
If you have defined a method in your source code with the same name as this API, we suggest altering your method name so that it no longer collides with Apple's private API to avoid your application being flagged in future submissions.
Alternatively, this API 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.
It’s not a bug – it’s an undocumented feature
Comments
✮My Web Site✮ ✮My Full Games On Sale✮ ✮Follow Me✮ ✮My Video Channel✮ ✮Contact Me To Buy My GS Games✮
2.5
The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The app includes : _cpu_capabilities from the framework '/usr/lib/libSystem.B.dylib'.
If you have defined a method in your source code with the same name as this API, we suggest altering your method name so that it no longer collides with Apple's private API to avoid your application being flagged in future submissions.
Alternatively, this API 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.
6.1
The user interface is not consistent with the OS X Human Interface Guidelines.
We have found that when the user closes the main application window there is no menu item to re-open it. The app should implement a Window menu that lists the main window so it can be reopened, or provide similar functionality in another menu item. OS X Human Interface Guidelines, state that "The menu bar [a]lways contains [a] Window menu".
Alternatively, if the application is a single-window app, it might be appropriate to save data and quit the app when the main window is closed.
For information on managing windows in Mac OS X, please review the following sections in Apple Human Interface Guidelines:
* The Menu Bar and Its Menus
* The Window Menu
* The File Menu
* Clicking in the Dock
* Window Behavior
Please evaluate how you can implement the appropriate changes, and resubmit your app for review.
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 discrete code-level questions, you may wish to consult with Apple Developer Technical Support. Please be sure to:
- include the complete details of your rejection issues
- prepare any symbolicated crash logs, screenshots, or steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter.
✮My Web Site✮ ✮My Full Games On Sale✮ ✮Follow Me✮ ✮My Video Channel✮ ✮Contact Me To Buy My GS Games✮
6.1
The user interface is not consistent with the OS X Human Interface Guidelines.
We have found that when the user closes the main application window there is no menu item to re-open it. The app should implement a Window menu that lists the main window so it can be reopened, or provide similar functionality in another menu item. OS X Human Interface Guidelines, state that "The menu bar [a]lways contains [a] Window menu".
Has anyone found a fix or is one coming soon?