WebView App Rejected Under Guideline 5.2.1: Prove Your Rights

Key takeaways

In a WebView app the website is the content – if you don't own the site, you don't own the app's content, and Guideline 5.2.1 expects permission.
The cleanest fix for client and partner sites is publishing from the rights holder's own developer account, with you as a team member.
Embedded videos, maps and feeds need the provider's terms on your side (5.2.2); download buttons for third-party media need explicit authorization (5.2.3).
Put permission letters, trademark registrations and licenses into one PDF under App Review Information – and only wrap sites you are authorized to publish.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 5.2.1 - Legal - Intellectual Property

Your app includes content from [third party] without the necessary authorization.

Next Steps: Provide documentary evidence of your rights in the App Review Information section in App Store Connect, or remove the protected content from your app and its metadata.

(Common variant for wrapped client websites: the seller name associated with the app does not reflect the brand shown in the app or its metadata.)

Paraphrased example – the exact wording in your message may differ.

WebView app rejected under Guideline 5.2.1: whose content is in your app?

When a WebView app is rejected under Guideline 5.2.1, App Review couldn't verify that you have the right to show what the app shows – or that you are the right party to submit it. For a wrapper app, that question covers the whole website: its name, logo, texts, photos and embedded media. The fix is either proof of permission or a different submitter. The guideline reads:

Don't use protected third-party material such as trademarks, copyrighted works, or patented ideas in your app without permission, and don't include misleading, false, or copycat representations, names, or metadata in your app bundle or developer name. Apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights.

A native app's content is mostly what you put into the bundle. A WebView app shows whatever the loaded site shows today, so the rights question is broader: whose domain is it, whose brand sits in the header, who licensed the photos and videos? If the answer isn't "ours" every time, you need documents or a different publisher.

Our Guideline 5.2.1 guide covers trademarks, fan apps and Apple's own marks in general. This article covers the situations specific to wrapped websites. It is practical release advice, not legal advice.

Whose website is it? Four wrapping scenarios compared

Scenario	Typical problem	What App Review needs
Your own company's website	The seller name differs from the brand on the site, for example a personal account publishing a company brand	A matching seller name – or verifiable proof that you own the brand
A client's website, built by your agency	The agency's account publishes a brand it doesn't own	Publication from the client's own developer account
A third-party site you like – news portal, forum, school or city portal, transit operator	No relationship with the owner at all, often with impersonation concerns on top	Written permission from the owner – realistically, the owner as publisher
Your storefront on a marketplace or platform	Pages, layout and branding belong to the platform, not to you	The platform's permission – or an app built on your own domain

The third row is the riskiest. Wrapping someone else's website also raises Guideline 5.2.2, which says: "If your app uses, accesses, monetizes access to, or displays content from a third-party service, ensure that you are specifically permitted to do so under the service's terms of use. Authorization must be provided upon request." Presenting such an app as the official one adds Guideline 4.1 Copycats to the list.

Google Play draws the same line. Its Webviews and Affiliate Spam policy doesn't allow apps whose primary purpose is to provide a webview of a website without permission from the website owner or administrator – see our Google Play WebView policy guide if you publish on both stores.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Embedded videos, maps and feeds: third-party content inside your pages

Even when you own the website, its pages often carry other people's content – and App Review sees it inside your app:

Embedded content	Usually fine when…	A problem when…
Videos from YouTube, Vimeo and similar	You use the platform's official embed player as its terms allow	You add download or "save offline" buttons – Guideline 5.2.3 requires explicit authorization from the source
Maps	You use an official maps API or embed with its attribution intact	App-only CSS hides the attribution or copyright line
News, social or RSS feeds	You hold a license, or the provider's terms permit display	The app mainly republishes other publishers' articles
Photos and illustrations	You created them or hold a license you can show	They were copied from a search engine or another website
Music and audio	You hold the rights or use a licensed service	Tracks play without any license
Partner logos and badges	The partner's brand guidelines allow the use	They suggest an endorsement the partner never gave

Watch the CSS you inject for the app: hiding your website's footer is fine, hiding a map's attribution or a photo credit is not. Apple's App Review page also asks apps that let users stream or download third-party content to provide authorization, so keep the relevant terms or contracts at hand.

Other brands in your app name, icon and screenshots

Screenshots of a wrapped website pick up third-party marks easily: payment logos in the footer, a marketplace badge, celebrity photos in a news teaser, a franchisor's logo in the header. Two guideline sentences decide what may stay:

You are responsible for securing the rights to use all materials in your app icons, screenshots, and previews, and you should display fictional account information instead of data from a real person.

You cannot use another developer's icon, brand, or product name in your app's icon or name, without approval from the developer.

The first is Guideline 2.3.9, the second 4.1(c). Applied to a wrapper app:

Name: "[City] Bus Times" describes a service; "[Transit operator] App" claims to be it. Only the operator, or someone it authorized, can use its name.
Icon: a franchisee can't simply use the franchisor's logo. Check the franchise agreement or brand guidelines and get written approval.
Screenshots: capture them with a demo account showing fictional data, crop out badges and logos you have no right to, and replace stock photos you can't license. Store badges for other platforms are a separate trap – see Guideline 2.3.10 for WebView apps.
Subtitle and keywords: no partner or competitor brands to catch search traffic.

Building a rights file App Review can verify

If you do hold the rights, make them easy to check. Apple's App Review page asks apps that feature third-party trademarks or copyrighted content to provide authorization, and says such files go into the Attachment section in App Store Connect, with descriptions or links in the Review Notes. A strong file for a wrapped website contains:

Written permission from the site owner on letterhead, signed by an authorized person, naming the app, your legal entity as seller, the domains the app may load, the allowed uses (name, icon, content) and a contact for verification.
Trademark registrations in the name of the account holder's legal entity, if you own the brand.
License agreements or receipts for photos, fonts, feeds and media used on the site.
Proof of the link between site and seller – for example the website's legal notice or about page naming the same company as your seller name, and a support URL on the same domain.
A one-page cover note mapping each document to the content it covers.

Merge everything into one PDF, attach it under App Review Information and summarize it in the Notes. Then check the Content Rights declaration under App Information: apps that contain, show or access third-party content must hold the necessary rights in every country or region where they are available. Never submit altered or unverifiable documents – that turns an IP question into a conduct problem under Guideline 5.6.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

Publishing from the rights holder's account instead

For client sites and partner portals, a stack of documents is a workaround; the cleaner fix is the publisher. Guideline 5.2.1 asks for submission by the person or legal entity that owns or licensed the rights, and seller-name rejections point the same way. In practice:

The client or partner enrolls in the Apple Developer Program, as an organization under its legal entity name.
You join their team in App Store Connect and build, sign and submit from there – the model appsubmitter.io uses for every app it publishes.
Seller name, support URL, privacy policy and the website's legal notice all show the same company.

The same move resolves Guideline 4.2.6 if the app comes from a template or website-to-app service – Guideline 4.2.6 for WebView apps walks through the account migration. For a third-party site you have no relationship with, the honest options are to approach the owner and offer to build the app for them, or to build a service of your own.

WebViewGold and appsubmitter.io when rights are on the line

WebViewGold, the website-to-app solution built by our team, converts any site that runs in Safari – which is exactly why the rights question has to be settled before you start. Use it for websites you own or are authorized to publish, and let its features keep third-party content in its place:

URL handling sends external domains – marketplaces, partner sites, social networks – to Safari or an in-app browser tab, so they aren't presented as your app's own content.
Custom CSS and JS removes third-party widgets you can't license from the app for every user – not just during review, which would raise a Guideline 5.6 problem.
Local HTML bundling keeps your own licensed content available offline.
The native video player with Picture-in-Picture plays streams you hold the rights to.

Publishing from the right account is where appsubmitter.io comes in: we always submit in the customer's own developer account, help you structure the rights documentation and your reply, and handle the communication with App Review. Legal questions belong with an IP attorney. Book the iOS service or describe your case in a free consultation call.

How to answer a 5.2.1 rejection for a wrapped website

You hold the rights: reply with the document list, explain which document covers which content and name a contact at the rights holder who can confirm.
You moved the app: state that the rights holder now publishes it from its own account and that you work as its developer.
You removed content: list every change by surface – name, subtitle, icon, screenshots, in-app pages – and by localization.
You believe the reviewer is wrong: for example because the brand is your own or the use is purely descriptive. Explain why and attach evidence.

If a reply doesn't resolve it, appeal to the App Review Board – one appeal per rejected submission, with specific reasons – or discuss the case in a 30-minute App Review appointment. Note that Apple's bug-fix exception, which lets some updates through while guideline issues are fixed later, excludes legal issues, so a 5.2.1 finding usually has to be resolved in the current submission. If a rights holder contacts you directly, involve a lawyer.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback under Guideline 5.2.1.

[Option A – we hold the rights]
[Our legal entity] is authorized to publish an app based on [domain] and its content. We have attached one PDF to the App Review Information section containing:
- Written permission from [Rights holder], signed by [name, title] on [date], covering the app name, icon and all content loaded from [domains]
- [Trademark registration no. [x] in the name of [our legal entity]]
- [License agreements for photos / video streams / feeds]
[Rights holder] can confirm this at [contact name, email].

[Option B – published by the rights holder]
The app is now submitted from [Rights holder]'s own developer account. [Rights holder] owns [domain], the brand and the content; our agency acts as a team member.

[Option C – content removed]
We removed [brand / content] from the app name, subtitle, keywords, icon, screenshots and the pages loaded in the app, in all [n] localizations. External links to [third-party sites] now open in Safari.

Please let us know if you need anything else to continue the review.

Best regards,
[Your name]
[Role], [Legal entity]

Checklist before you resubmit

The app only wraps websites you own or are authorized in writing to publish.
The seller name matches the company named in the website's legal notice.
Client and partner apps are published from the rights holder's own developer account.
Embedded videos, maps and feeds use official players or APIs with attribution intact.
No download or save buttons for third-party media without the source's authorization.
App-only CSS hides site chrome, never attributions, credits or copyright notices.
App name, icon, subtitle and keywords contain no third-party brand you lack written approval for.
Screenshots show fictional demo data and no logos or photos you can't license.
Permission letters, trademark registrations and licenses are merged into one PDF under App Review Information.
The Content Rights declaration under App Information is answered correctly.
External marketplaces, partner sites and social networks open in Safari or an in-app browser tab (in WebViewGold via its URL handling settings).

Frequently asked questions

Why was my WebView app rejected under Guideline 5.2.1?

Because App Review couldn't see that you have the right to show the app's content or to submit it. For wrapper apps this usually means the website, brand or embedded media belong to someone else – a client, a partner, a publisher – or the seller name doesn't match the brand. Publish from the rights holder's account, attach proof of permission or remove the content.

Can I make an app from a website I don't own?

Only with the owner's permission, and realistically with the owner as publisher. Guideline 5.2.1 expects apps to be submitted by whoever owns or licensed the rights, and 5.2.2 requires permission under a third-party service's terms. Google Play's Webviews and Affiliate Spam policy likewise bans apps that mainly show a website without permission from its owner.

Can I embed YouTube videos in my WebView app?

Embedding through the platform's official player, as its terms allow, is the common approach. What Guideline 5.2.3 rules out is saving, converting or downloading media from sources like YouTube or Vimeo without their explicit authorization. Don't add download buttons, keep the player and its attribution intact and be ready to show the terms you rely on.

What permission letter does Apple accept for a wrapped website?

Apple publishes no template. A letter that works is signed by an authorized person at the site owner, names the app and your legal entity, lists the domains the app may load and the allowed uses – name, icon, content – and gives a contact for verification. Attach it as a PDF under App Review Information and explain it in the Notes.

My agency built the client's website. Can we publish the app ourselves?

Not from your own account if the brand and content belong to the client. Guideline 5.2.1 asks for submission by the rights holder, and template-built apps also fall under 4.2.6. Have the client enroll, join their team and publish from there – your agency still does the work, but the seller is the client.

Can WebViewGold wrap any website?

Technically, WebViewGold converts any site that runs in Safari. For App Review – and legally – you should only wrap sites you own or are authorized to publish, from the right developer account. WebViewGold is made by our team; its URL handling keeps third-party domains in Safari or an in-app browser tab. No tool can promise an approval.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

WebView App Rejected Under Guideline 5.2.1: Wrapping Websites, Brands and Content You Don't Own