Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-Public API Usage #2899

Closed
MikePT28 opened this issue Oct 20, 2017 · 13 comments
Closed

Non-Public API Usage #2899

MikePT28 opened this issue Oct 20, 2017 · 13 comments

Comments

@MikePT28
Copy link

Hi all,

Yesterday we got hit by Apple's submission review system with the following:

Non-public API usage:

The app references non-public selectors in XXX: _panGestureRecognizer, addDataSet:, dataSetIndex, dataSets, entryCount, initWithDataSet:, initWithLimit:, initWithValues:, initWithX:y:, legend, rotationAngle, setBarData:, setCircleRadius:, setGranularity:, setHighlightColor:, setLabelFont:, setLabelPosition:, setLabelTextColor:, setLabelWidth:, setLineColor:, setRotationAngle:, setScaleEnabled:, setValueFont:, setValueFormatter:
If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed.

We have used this library before, we even have our app released, but now we get this blocker when submitting. We are on talks with Apple because we believe it is a false positive. I'm opening the issue to let the community know that this could happen. I will also keep posting updates as we get them from Apple to see if they agree that it is a false positive or if a change has to be done to this framework's naming.

Regards,
Mike

@pmairoldi
Copy link
Collaborator

We don't use private apis. This is just a case of same method names. I'll leave this open for now waiting for your updates.

@liuxuan30
Copy link
Member

Will you ask apple to justify what's the names that matches their private API names? I don't see any. Can this be false alert by apple?

@pmairoldi
Copy link
Collaborator

It is a flase alert. I’ve had this happen to some of apps before the method names are the same but on different objects. They don’t check on what objects the methods are just that the names match.

@MikePT28
Copy link
Author

No update so far. Still waiting for Apple to give us an answer. Really slow process.....

@MikePT28
Copy link
Author

Hello!

Got an update from Apple:

This is an automated test we run on all app submissions. As per submission guidance, if method names in your source code [or in a 3rd party library] match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. You could also try resubmitting without the 3rd party library to narrow down the issue.

It seems they are not willing to change their script. Is this something that can be fixed on the library or is the correct path for me to fork this and make the changes on my own??

I really appreciate the assistance anyone can provide

@liuxuan30
Copy link
Member

liuxuan30 commented Nov 13, 2017

It's weird only you report this issue so far. If it's really our issue, at least more users should report this.

The app references non-public selectors in XXX: _panGestureRecognizer, addDataSet:, dataSetIndex, dataSets, entryCount, initWithDataSet:, initWithLimit:, initWithValues:, initWithX:y:, legend, rotationAngle, setBarData:, setCircleRadius:, setGranularity:, setHighlightColor:, setLabelFont:, setLabelPosition:, setLabelTextColor:, setLabelWidth:, setLineColor:, setRotationAngle:, setScaleEnabled:, setValueFont:, setValueFormatter:

these names are very common... I don't think it's our fault. You should ask for more details why these names are on their radar, and these are just common names to use.

You can try upload again to see if same alerts came out. Ofc you can change what listed to other names, but it just makes no sense..

@pmairoldi
Copy link
Collaborator

I’ve had this for apps before it’s a warning not an error. It’s fine. We don’t need to change anything.

@droidpl
Copy link

droidpl commented Nov 15, 2017

I don't thing this is a warning anymore. We couldn't submit the app to testflight with this error. At the end we have forked the library to change the names and now its all good.

@liuxuan30
Copy link
Member

liuxuan30 commented Nov 18, 2017

what.. you have to change the name? As I said you are the ony one to report this. That makes no sense. Are you able to file a bug report for apple? As you see, our name is harmless, and very common name to have. If those names are conflict, there would be more apps to reject then :(

@droidpl
Copy link

droidpl commented Nov 18, 2017

We tried hardly. I contacted them personally, also our client. They said they were going to have a look forwarding to the correct team, two times. After almost a month we didn't get any reply, so we contacted a sales director from Apple directly and after a couple of mails he also recommended us to fork the library and change the names to submit it.

Maybe it is that this issue is only blocker if you upload to testflight, I don't know. But in the mail they clearly said "you must change the names", it was not optional since they rejected our uploaded builds.

@liuxuan30
Copy link
Member

liuxuan30 commented Nov 20, 2017

if you upload to testflight

not quite understand this. I remember submitting apps to app store will trigger a testflight build automatically. and after it succeeded, we can release them then.

Yes it's quite weird. My current & previous company use this library as well (on app store as well), but never get a rejection like this.

@MikePT28
Copy link
Author

MikePT28 commented Nov 23, 2017

Yes, Testflight builds are triggered automatically. I think he might have misspoken there a bit :)

The issue is on the automatic review they do, not the manual one (obviously). But as he said, we did try to contact Apple about the issue but it was pointless. The solution was as he said, to fork the library and invert the names that were giving issues. (i.e: dataSets => setsOfData) The system bought it and we went life with those changes. Not ideal but we were on a time constraint.

I do agree that if we are the only ones reporting this, not much can be done. But, my guess is that if this keeps happening, more people can report this as an issue to Apple and that will validate the problem and maybe get it fixed on their side :)

@liuxuan30
Copy link
Member

liuxuan30 commented Nov 24, 2017

Yes, I feel bad you have to change names on your side; it's not sustainable and not your fault. We got many swift related PRs recently and slowly merging it; once you have to upgrade your library, it will be disaster again. I suggest you file a DTS request(the one every account have 2 yearly) to let a dedicated person help you about it. If they thought it was bug they should refund your DTS back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants