Mac apps that have to use Private APIs
| Originator: | blachman | ||
| Number: | rdar://8585075 | Date Originated: | 10/22/2010 |
| Status: | Open | Resolved: | |
| Product: | App Store | Product Version: | Mac |
| Classification: | Serious Bug | Reproducible: | N/A |
Most first class Mac apps, including my own shipping Mac app (XXXX), run into issues with the Cocoa API where the only solution is to use private APIs. These solutions are almost always suggested by AppKit or WWDR engineers as the only solution to customize, workaround or fix pieces of the public API. Section 2.5 of the Mac App Store guidelines state that because my apps use private APIs, most of which were recommended by Apple engineers, they will be rejected from the app store. I suggest that perhaps there needs to be an interim way to handle situations like mine. I have talked to many other developers and they almost all have the same issue. I don't want to continue using private APIs, I'd much rather have the few APIs fixed that commonly need to be worked around. Perhaps a roll out strategy would be best. For instance, the 10.6 version of the app store submission process could just record and report (in detail with a strong warning) Private API usage with the knowledge that non-public APIs would become reject worthy for the Mac App Store with the advent of 10.7 Lion. This would give Apple time to analyze the most commonly used private APIs and possibly introduce public versions of them or provide public workarounds of some other type. It would also give developers more than 80 days to find an alternative to something that may not have actually have an alternative currently. Note: The three parts of Cocoa which require private API usage that come most prevalently to mind are: NSTableView/NSOutlineView, NSTextView and NSTokenField.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Good idea
Your proposal seems really good to me. I was myself advised to overload some private AppKit methods to fix several problems by Apple Engineers. The rules of the App Store are not acceptable at this time regarding private API usage. Lion needs to open much larger part of the frameworks if we want to continue our business and comply to the App Store rules. In the mean time, I hope Apple won't be stupid and won't reject an app that uses "well known" private APIs, typically in NSTableView !
Omni's practice is to require a Radar number next to any use of private API. I'd be happier if Apple required the same thing in the Mac App Store -- they should be able to white-list your use of private API and tie it to a Radar. Once that Radar is fixed, then some timer begins and/or your next version needs to stop using it. This still wouldn't be perfect, but it would help address the issue and put more pressure on Apple to fix the Radars that have been submitted (both by bumping the count of Radars that get logged on issues instead of silently working around them and by listing the apps that need a bug to be fixed).