We recently ran into an issue where our submission was rejected due to references to an API that we are not using but that was present in the code.
Guideline 2.5.1 - Performance - Software Requirements
Issue Description
The app uses the Clinical Health Records API but the app does not appear to include any primary features that require the Clinical Health Records API.
Next Steps
To resolve this issue, please remove the Clinical Health Records API from the app, as well as any references to this app’s interactivity with Clinical Health Records from the app or its metadata.
And as it turns out, we actually did have references to that API that we had missed and did have to remove them.
Usually, I would recommend to just resubmit the new build and see if it gets accepted, then hold it until the powers that be approve it for publication.
For this client, though, their QA team forces us into more of a waterfall-ish approach, where we are not allowed to submit production builds ahead of time (i.e. until after all manual testing has concluded, test evidence has been filed and the required documents have been updated and approved).
And if after resubmission we find something else that needs to be fixed, we get to restart the process all over again.
That's ... slower.
We do have a workaround in place where we submit a development build for review and check whether that would get accepted, then retract that version and submit the production build once we are allowed to.
But that means more work for Apple (the App has to be reviewed twice) and more risk for us (if the submission team accidentally publishes a development build, the consequences would be severe).
Is there a tool that allows us to check for guideline violations without having to submit a build to the App Store Connect?
I'm not looking for a "yes, this will get approved" kind of guarantee, just a "well, the review team may find something else to question / reject, but as far as automated checks go, this looks ready for submission".