Avoid static privacy API references in PermissionManager

[fhasse95]

This PR extends the existing dynamic API resolution approach used by LocationManager to other permission-related APIs in PermissionManager. This avoids unnecessary privacy usage description requirements for apps that don't use the corresponding functionality.

For example, when uploading my app to App Store Connect, I encountered ITMS-90683 requiring NSMicrophoneUsageDescription, even though my app doesn't even use the microphone. This was caused by static API references in SkipKit which prevented App Store Connect from successfully processing the uploaded build.

The changes preserve the existing permission functionality while avoiding these static references. Apps that actually use the corresponding APIs still need to provide the required privacy usage descriptions, while apps that don't use them no longer need to add unnecessary usage descriptions to their Info.plist just to satisfy App Store Connect's validation.

---

Thank you for contributing to the Skip project! Please use this space to describe your change and add any labels (bug, enhancement, documentation, etc.) to help categorize your contribution.

Please review the contribution guide at https://skip.dev/docs/contributing/ for advice and guidance on making high-quality PRs.

Skip Pull Request Checklist:

• REQUIRED: I have signed the Contributor Agreement
• REQUIRED: I have tested my change locally with swift test
• OPTIONAL: I have tested my change on an iOS simulator or device
• OPTIONAL: I have tested my change on an Android emulator or device

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.
  I used Codex to help implement and iteratively refine the changes, investigate issues, and run targeted validation checks. I reviewed the changes and manually verified them by building and uploading my own iOS app to TestFlight using the modified Skip package. The upload no longer triggered any ITMS privacy-related warnings, and I confirmed that location fetching, camera access, and photo library access still work as expected.

---

[marcprux]

I wonder if this is a new linkage check that Apple is performing? I recall that in the past the only UsageDescription requirement that linking SkipKit introduced was the location usage descriptions (and thus was why we only introduced the dynamic symbol lookup for the LocationManager APIs). But they may have well have added more checks since then.

[fhasse95]

I wonder if this is a new linkage check that Apple is performing? I recall that in the past the only UsageDescription requirement that linking SkipKit introduced was the location usage descriptions (and thus was why we only introduced the dynamic symbol lookup for the LocationManager APIs). But they may have well have added more checks since then.

That could be the case! Unfortunately, I hadn't uploaded a build using SkipKit to App Store Connect before, so I can't really tell if or when Apple introduced these additional checks.

What I can confirm is that the changes resolved the ITMS-90683 error for my app, and the new build was processed successfully without any privacy-related warnings.

[fhasse95]

@marcprux How would you like to proceed with this PR? Do you think it's ready to merge and include in an upcoming SkipKit release, or is there anything else you'd like me to look into? 🙂

[marcprux]

This is fine to go in. In an ideal world, we might update SkipKit to use SwiftPM package traits and then have the individual capabilities be contingent on the traits that are activated (e.g., only referencing the offending APIs when including the SkipKit dependency with the "microphone" trait enabled). But that's overkill for the near term, so let's go ahead with this route.

[marcprux]

How would you like to proceed with this PR?

Feel free to merge and tag a new patch release.

[marcprux]

when uploading my app to App Store Connect, I encountered ITMS-90683 requiring NSMicrophoneUsageDescription, even though my app doesn't even use the microphone

BTW, I forgot to ask: was this a hard failure for the submission, or just a warning email about the missing usage description?