Tuesday, September 27, 2016

Unfortunate App Store Rejections

One of the less discussed problems with App Review is that apps get rejected for using private API when they are not actually doing so. Peter Steinberger’s PSPDFKit:

These are in fact not calls to private API, just simple selector name clashes, where PSPDFKit has named a method internally the same as one that Apple uses internally. Since these internal names are not documented and this also cannot be verified offline, there is no way for us to anticipate what names are supposedly reserved.


This review seems to be both arbitrary and applied at random. We also got reports that they submitted the exact same app binary, just changed the build number to allow a re-submission, and it went through without any issues.

Sometimes this happens in reverse. Daniel Jalkut:

A major App Store frustration is you can never know when a precision bug fix update will be blocked by reconsidered review criteria.

And then there are the no-win situations. Jalkut again:

Interesting edge case: latest version of @blackinkapp (a bug fix for Sierra) rejected because I link to subscription info pages for puzzles.

Advice from Apple is to use in-app purchase, but I don’t control or profit from them. Have to stop encouraging 3rd party purchases. :-\

Glenn Fleishman:

So you can’t link to a product page for the app which has info?

Daniel Jalkut:

I’m overt about it in the app: I offer a login screen for the affected services. I can see why they’re grumpy, but what can I do?

Glenn Fleishman:

They rejected my The Magazine archives after several months for sale because the book had some Amazon book links in it.

Which was ridiculous. It’s a 1,200-“page” ebook with Amazon links that generate $0. i’m not fixing it.

1 Comment RSS · Twitter

[…] no viable path to Appleā€™s goal state given the existing rules. The details of any particular App Store controversy can often distract from this larger reality. A hardline stance will not sway hearts and […]

Leave a Comment