Safari extension rejected? The usual reasons, and the fixes.

Safari extensions ship inside apps, so they live and die by App Review — and App Review rejections cite guidelines, not fixes. Here’s the translation table I’ve built shipping extensions through review at Honey and Pie, roughly in order of how often each one bites.

“Your app provides minimal functionality”

The containing app can’t be an empty shell. It doesn’t need features — it needs a purpose: explain what the extension does, show whether it’s enabled, and walk the user through turning it on in Safari settings. A well-designed onboarding screen with live extension state satisfies this. A blank window with your logo doesn’t.

Broad permissions without justification

An extension that requests access to all websites is asking for a lot, and review treats it that way. Two fixes, used together: request the narrowest permissions your product genuinely needs, and explain the remainder — in the review notes andin the user-facing UI. “This extension needs access to shopping sites to find coupons at checkout” passes; unexplained all-sites access invites rejection or a request for justification that stalls you a cycle.

Privacy labels that don’t match the binary

Your App Store privacy questionnaire is checked against what the app and extension actually do. The classic failure: an analytics SDK someone added two years ago collects identifiers your label says you don’t collect. Audit what actually leaves the extension — network request by network request — before filling in the labels, not after the rejection.

Metadata problems

Store listings that lean on other brands (“works like the Chrome version!”), screenshots showing other browsers, or names that collide with trademarks all draw metadata rejections. Keep the listing about what the Safari product does for the user.

The iOS-specific tier

iOS review is stricter than macOS. Expect extra attention on anything that touches payments (guideline 3.1 territory), content filtering, and background behavior claims. If your extension interacts with purchases or money — coupons, cashback, price tracking — write the review notes as if the reviewer knows nothing about your category and needs to see, step by step, that everything happens on the merchant’s site, not through payment mechanisms Apple polices.

Review notes are a product surface

The highest-leverage hour in the whole submission: write review notes that include what the extension does in one paragraph, a demo path with any test credentials, an explanation of each permission, and a preemptive answer to whatever looks unusual about your product. Reviewers are fast and pattern-driven; your notes are the pattern you hand them. At PayPal scale we treated review notes like release engineering, because a rejection cycle costs a week and notes cost an hour.

If you’re already in the loop

1. Read the citation, then diagnose the reviewer’s concern behind it — the guideline number is often the nearest label, not the actual issue.
2. Respond in Resolution Center with specifics before resubmitting blind; sometimes the answer alone clears it.
3. Fix the class, not the instance — if one permission drew fire, audit all of them before the next round.
4. If you believe review is simply wrong, appeal — it works more often than people think, when the case is factual.