Guideline 4.7.2 - Design: Exposing Native APIs to Hosted Content Without Apple Permission

Apple is rejecting your app because it exposes native device APIs (camera, microphone, location, contacts, Bluetooth, etc.) to hosted web content or mini apps without explicit Apple permission. Guideline 4.7.2 requires that if your app hosts third-party code (HTML5 games, web-based mini apps, chatbot plugins) and gives that code access to native device capabilities through JavaScript bridges or custom URL schemes, you must have Apple's written approval. This is a security-critical rejection. When web content or embedded third-party code can access native APIs through your app's bridge layer, it creates a potential attack vector — malicious hosted content could access the camera, read contacts, or track location through your app's permissions, bypassing the normal App Store review process. The most common trigger is apps that implement a JavaScript-to-native bridge (via WKWebView's WKScriptMessageHandler or similar) that exposes device APIs to loaded web content. Even if you trust the current web content, Apple considers the bridge itself a risk because the content can change without a new app review. The fastest compliant path for most developers is to remove the native API bridge from hosted content entirely. If native API access is essential for your platform, you need to apply for an entitlement or contact Apple directly to discuss your use case.