Incorrect App Store rejections for name clashes on methods that happen to be named like private API (especially bad for us, as we ship an SDK.)

Originator:steipete
Number:rdar://28252227 Date Originated:12-Sep-2016 01:44 AM
Status:Open Resolved:
Product:App Store Product Version:
Classification: Reproducible:Sometimes
 
Summary:
We sell PSPDFKit, an SDK that's in thousands of apps on the App Store. Lately we've seen rejections again for methods that seemingly just randomly clash with internal API that Apple uses.

This is a problem. Our customers are mad and blame us for using private API, when we do not - it's just bad luck that names clash in completely unrelated parts. We cannot do anything other than trying to educate, and then rushing out a new release of our SDK with these symbols renamed (because our customers often are in a hurry and even if arguing might help - it could take a long time and it's not certain that they are not forced to rename anyway.)

This caused bugs as we rushed and forgot to update all calls. We've beefed up our test coverage over the last two years, but especially with dynamic code there's always a risk of introducing bugs for doing needless changes. It also makes our API worse and might break existing implementations.

Some customers argue with the review team. Some simply re-submit and pass - without any binary changes. The system seems very arbitrary. The method flagged here was in our SDK for years. It never got flagged. I assume that this method has recently been added somewhere inside iOS 10 and thus now is on a list.

Steps to Reproduce:
I might be able to list customers, but would have to ping them first - we'd rather not. The test the last one received was the following:

Performance - 2.5.1


Your app uses or references the following non-public APIs:

finished:, pageRange, postBody, titleForSection:

The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.

Next Steps

Please revise your app to remove any non-public APIs. 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, if you are using third party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "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 tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third-party libraries are calling these APIs.

Resources

For information on the "nm" tool, please see the "nm tool" Xcode manual page.

If there are no alternatives for providing the functionality your app requires, you may wish to file an enhancement request.

If you have difficulty reproducing a reported issue, please try testing the workflow described in Technical Q&A QA1764: How to reproduce bugs reported against App Store submissions.

If you have code-level questions after utilizing the above resources, you may wish to consult with Apple Developer Technical Support. When the DTS engineer follows up with you, please be ready to provide:
- complete details of your rejection issue(s)
- screenshots
- steps to reproduce the issue(s)
- symbolicated crash logs - if your issue results in a crash log


Expected Results:
All private methods (and functions, for that matter) implemented by Apple should start with an underscore. This, combined with a clearly-defined precedence for original versus category-defined methods, would make adding methods to framework classes by category or by subclass much safer.

This would also fix the problem with the name clashers here.

Actual Results:
Apps are rejected for unsound reasons.

Version:
iOS

Notes:
This is not the first time this happened. I vented via Twitter but should have started describing the problem earlier. Sorry about that.

Here are some incidents I can remember. There surely are more:

https://twitter.com/steipete/status/773499862579023872
https://twitter.com/steipete/status/451417995945193472
https://twitter.com/steipete/status/272391185530753024
https://twitter.com/steipete/status/654291385949024256
https://twitter.com/0xced/statuses/314458799643693056
https://mobile.twitter.com/chockenberry/status/270684871612051457
http://stackoverflow.com/questions/3455604/apple-rejected-app-because-of-animationdidstopfinishedcontext-is-a-non-public

I've seen that Apple is investing a lot in making the App Store better. A cleanup, faster review times - you're on a good track. Thanks!

Comments

We've been hit by this again with finished: and are now renaming it to finished_pspdf: in PSPDFKit 5.5.5. cries

22-Sep-2016 09:33 AM

PlanGrid (another of our customers and big company for construction plans) got rejected for "finished:, titleForSection:" iOS 10 update. https://twitter.com/benjaminencz/status/778812843906916353

21-Sep-2016 11:26 AM

The VLC (Video Lan Client) iOS App got rejected for having a method with the name "showErrorWithTitle:message:" https://twitter.com/feepk/status/778525061745639424

20-Sep-2016 11:05 AM

Dupe with more information from the GeniusScan people: rdar://28383144 https://openradar.appspot.com/28383144

20-Sep-2016 10:25 AM

Further evidence:

Genius Scan: "got rejected for import: and followersCount: !! Had to migrate a CoreData schema…" https://twitter.com/bvirlet/status/778135546405216256

Voony Games: "We rolled out an update, which was approved yesterday using mainScreen. Something is broken at Apple." https://twitter.com/arvidgerstmann/status/778130274341257217

"re-uploading the same build with a different build number sometimes fixes that problem." https://twitter.com/lukas_kollmer/status/778099408864968704

Number23 (Banking) "us too. Seems massives of false positives showing up since last week" https://twitter.com/philipmcdermott/status/777981817924284416 Peter Steinberger19-Sep-2016 11:16 PM

Some more:

Rejected for "addAction:`: https://twitter.com/parrots/status/777969036428795904 Rejected for "ping": https://twitter.com/tomiq/status/777964923745890305

19-Sep-2016 09:52 PM

We renamed the internal methods, released a new version, and now one of our largest customers, Atlassian, was flagged again in their HipChat iOS app.

"App store rejected us for “titleForSection:”, updated to PSPDFKit 5.5.3 and now rejected for “titleForSectionIndex" https://twitter.com/andymikefred/status/777917248216309760

We will rename the method again (idk... titleForSectionAtIndex maybe?) but there's something broken in the review process, and it takes up a lot of time and energy and these renames are also a potential source of new bugs. Please sort this out.

This is also bad for customers, since they are suck on an older version of HipChat (and many other apps), potentially not yet optimized for iOS 10 - so they're probably having a bad experience with the OS update.

Some more people joined the conversation: https://twitter.com/ketzusaka/status/777940811912654848 https://github.com/MailCore/mailcore2/issues/1510 https://twitter.com/senior/status/777946304274051073

We've already renamed our API calls to work around this issue, coming in PSPDFKit 5.5.3 for iOS (release today/tomorrow).

https://pspdfkit.com/changelog/ios/ https://twitter.com/PSPDFKit


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!