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

**Guideline:** 4.7.2 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** hard · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/apple/4/guideline-472-design-exposing-native-apis-to-hosted-content-without-apple-permission

## Description

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.

## Common variations

- App exposes native platform APIs to hosted third-party content
- JavaScript bridge allows hosted content to access device capabilities
- Native API access provided to web content without Apple authorization
- Hosted code can access camera, location, or contacts through app bridge
- App provides unauthorized native API bridge to embedded content

## Example rejection email

```
Guideline 4.7.2 - Design - HTML5 Games, Bots, etc.

Your app exposes native platform APIs to hosted third-party content without Apple's authorization. Specifically, your app provides a JavaScript bridge that allows hosted web content to access device capabilities including [camera/location/contacts/etc.].

Exposing native APIs to hosted content creates security and privacy risks, as the hosted content can change without undergoing App Store review. Apps that provide native API access to hosted content must receive explicit authorization from Apple.

Next Steps:
Please either remove the native API bridge from hosted content, or contact Apple to request authorization for this functionality. In either case, reply in the Resolution Center with your planned approach.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High — security violation with potential account implications
- **Resolution path:** Remove native API bridge OR obtain Apple authorization
- **Typical turnaround:** 1-3 days (removal) or weeks-months (authorization)

## The Fix

### Path A: Remove the bridge (fastest)
01. **Audit your JavaScript bridge** — List every native API your WKWebView bridge exposes to web content: camera, location, contacts, Bluetooth, file system, etc.

02. **Remove native API exposure** — Remove message handlers that pass native API data to web content. Hosted content should only be able to communicate non-sensitive data with the native layer.

03. **Move native features to native UI** — If hosted content needs a photo, present a native UIImagePickerController from the native layer and pass the result. Don't give the web content direct camera access.

04. **Implement a safe communication protocol** — You can still have a bridge for non-sensitive operations (theming, navigation, analytics). Just don't expose device APIs.

05. **Sandbox hosted content** — Configure WKWebView with strict content security policies. Disable `allowsInlineMediaPlayback` and other permissive settings unless needed.

### Path B: Request Apple authorization (long-term)
01. **Contact Apple Developer Relations** — Submit a request explaining your platform, why native API access is needed, and your security measures.

02. **Document your security architecture** — Prepare detailed documentation of how you vet hosted content, how API access is scoped, and what safeguards prevent abuse.

03. **Implement review process for hosted content** — Show Apple that you have a review process for mini apps that mirrors App Store review for privacy and security.

## Prevention
- Never expose native APIs to web content without Apple's permission
- Use native UI components for device API interactions, not web bridges
- If building a platform, consult Apple early about native API access requirements
- Implement strict WKWebView security configurations

## Appeal guidance

This is not an appeal situation — you need either Apple's explicit permission or to remove the bridge. If your platform genuinely requires native API access for hosted content, contact Apple Developer Relations to discuss your use case and request authorization. This is a formal process, not something resolved through Resolution Center alone.

## Before / after examples

**Before:** App hosts HTML5 mini apps and provides a JavaScript bridge with window.nativeAPI.getLocation(), window.nativeAPI.openCamera(), and window.nativeAPI.getContacts() — any hosted content can call these
**After:** JavaScript bridge restricted to window.nativeAPI.setTheme() and window.nativeAPI.navigate(). When a mini app needs a photo, it calls window.nativeAPI.requestPhoto() which presents the native image picker overlay — the mini app receives only the selected image, not camera access
**Why it works:** Hosted content must not have direct access to native APIs. Device features should be mediated through native UI with the minimum data necessary passed back.

## Common questions

**Can you appeal a 4.7.2 rejection?**

This is not an appeal situation — you need either Apple's explicit permission or to remove the bridge. If your platform genuinely requires native API access for hosted content, contact Apple Developer Relations to discuss your use case and request authorization. This is a formal process, not something resolved through Resolution Center alone.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-472-design-exposing-native-apis-to-hosted-content-without-apple-permission*