[quote='883989022, DTS Engineer, /thread/822361?answerId=883989022#883989022'] If the issue originates from your own codebase rather than a compiled third-party SDK, you can identify and resolve it at the source code level. [/quote] Out of curiosity, what if it doesn't? Part of our issue was that we were using a third-party library to access HealthKit and that library being a general purpose one, contained some references to the API the Apple Store Connect wanted us to remove. Our solution was to fork the library and remove the references from it ourselves, but I am curious if there's a better approach. [quote='883989022, DTS Engineer, /thread/822361?answerId=883989022#883989022'] Apple’s review process examines the binary for linked frameworks and symbol references. You can perform the same checks locally or within your pipeline before the build is submitted to QA. [/quote] Once we are made aware of it, sure. But you are talking about checks that we would implement ourselves, right? I was rather hoping Apple would provide a tool for doing that because parsing and encoding the guidelines into a software check sounds like something Apple has already done anyway time-consuming and error-prone to implement ourselves For example, the indicated point 2.5.1 in the rejection message just says Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. That this also means we need to eradicate all binary references to the APIs we don't use from our app is non-obvious to me.