WebView App Rejected Under Guideline 4.2.6: Who Must Submit

Key takeaways

Guideline 4.2.6 is about who submits: template-based apps must come directly from the provider of the app's content, usually from that business's own developer account.
Website-to-app services, agencies and freelancers trigger it when they publish client apps under their own seller name.
Three models comply: the client's own account with you as a team member, a genuinely customized app, or one picker app that hosts all clients.
WebViewGold, built by our team, is a template you customize and publish in your own account – and appsubmitter.io submits in the customer's account, never its own.

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 4.2.6 - Design - Minimum Functionality

Your app appears to have been created from a commercialized template or app generation service. Apps created this way must be submitted directly by the provider of the app's content.

Next Steps: Have the provider of the app's content submit the app from its own Apple Developer Program account.

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

WebView app rejected under Guideline 4.2.6: the rule word for word

A WebView app rejected under Guideline 4.2.6 was, in Apple's eyes, built with a template or app generation service and submitted by someone other than the business whose content it shows. You usually fix it by publishing from the content owner's Apple Developer account – the code can often stay as it is. Here is the complete rule:

Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or "picker" model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.

Taken sentence by sentence, it sets three expectations:

Wording	What it means for a website wrapper
"submitted directly by the provider of the app's content"	The submitting developer account belongs to the business behind the website – not to the tool, agency or freelancer that built the app
"should not submit apps on behalf of their clients"	A publishing service that uploads every customer app from one central account is the textbook case
"customized, innovative apps that provide unique customer experiences"	Swapping URL, icon and colors isn't customization; each client needs features and content of its own
"a single binary to host all client content"	The alternative for platforms: one app, many clients inside it

Note what the rule doesn't say: templates aren't banned. A business that builds its own app from a template and submits it from its own account is precisely the case Apple accepts. For the rest of Guideline 4.2 – minimum functionality, marketing apps, dependencies – see our Guideline 4.2 guide.

Website-to-app services, agencies and freelancers: who gets flagged

Website-to-app platforms publishing from their own account

A platform turns customer websites into apps and, to keep onboarding painless, publishes them under its own developer account. Every app shows the platform as seller and differs only in URL, name and icon – the setup the second sentence of 4.2.6 rules out. Before you sign up for such a service, ask whose account your app will live in.

Agencies with one account for all clients

An agency builds WebView apps for a bakery, a law firm and a sports club and uploads all three from its own account, because the clients have none and the agency's certificates are already set up. Convenient – but the App Store then lists the agency as seller of content it doesn't own. Besides 4.2.6, that mismatch also produces seller-name rejections under 5.2.1, covered in 5.2.1 for WebView apps.

Freelancers reselling a reskinned template

A freelancer licenses a template, changes start URL and logo for each customer and submits everything from a personal account. That fails 4.2.6 on the submitter and often 4.3 on similarity, because the binaries are nearly identical. If this sounds familiar, read our article on Guideline 4.3 spam for WebView apps too.

Regulated services

Apple's App Review page adds a related expectation: apps that require sensitive user information or offer services in regulated fields – banking and financial services, cryptocurrency, healthcare, gambling, air travel – must be submitted by the legal entity that provides the service rather than an individual developer. A WebView app for a clinic or a lender belongs in the clinic's or the lender's account.

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 →

Are you the provider of the app's content? A five-question test

Apple doesn't define the term further, but in practice these five questions settle it:

Question	Points to you	Points to someone else
Whose name will appear as seller on the App Store?	Your company's legal name	An agency, a tool or a freelancer
Who owns the domain the app loads?	You do	A client whose site you built
Who answers when an app user contacts support?	Your team	You forward requests to the client
Whose privacy policy covers the data the web app collects?	Yours	The client's
Who decides what the app shows next week?	You	The client edits the site

If most answers point to someone else, that party is the provider of the content and should submit the app. Keep in mind that enrollment fixes the seller name: an organization appears under its legal entity name (Apple accepts no trade names or DBAs), an individual under their personal legal name.

Three ways to comply: own account, real customization or a picker app

Model	Who submits	Fits	Watch out for
Client's own account	The client, with you as team member	Agencies, freelancers, done-for-you publishing	The client must enroll; organizations need a D-U-N-S Number
Customized app from a template	The content owner, from its own account	Businesses building their own app with a template or builder	A logo-and-URL swap can still read as a clone under 4.3
Picker app	The platform, from its account	Platforms serving many small clients – restaurants, venues, events	It must be a real directory with search and entries, not a launcher for client websites

The client's own account

The default for client work: the agency keeps building, signing and uploading – only the seller changes. The one-time migration is described below.

A customized app, not a reskin

The second half of 4.2.6 expects template services to enable "customized, innovative apps". For a WebView app, that means features that belong to this one business: push for its own events, a scanner for its tickets or products, Face ID for its customer portal, a widget with its users' data. Two apps from the same template should look and behave like two different products.

One picker app for many clients

Apple's own examples are a restaurant finder with a customized page per restaurant and an event app with an entry per event. For a website-to-app platform, that can be a directory app: users search, browse a map or scan a QR code, pick the business and see its customized pages inside one binary. Because 4.2.6 names this model as acceptable for template providers, the platform submits it from its own account.

Moving a WebView app into the client's developer account

The client enrolls. An organization needs to be a legal entity with a D-U-N-S Number (government entities excepted), a functional website on its own domain and an Account Holder with authority to sign agreements. Sole proprietors can enroll as individuals.
The client invites you. Under Users and Access, the Account Holder adds you as Admin – on organization teams, Admins get access to Certificates, Identifiers & Profiles by default – or as App Manager with that access enabled. Only the Account Holder can sign legal agreements such as the Paid Apps Agreement.
Create or transfer the app. For a new app, register the bundle ID in the client's team. For an app already live in your account, use App Transfer: it keeps ratings, reviews and the bundle ID, requires at least one version released on the App Store and is initiated and accepted by the two Account Holders.
Switch signing and CI/CD. Certificates and provisioning profiles now come from the client's team, and your pipeline uses the client's Team ID and an App Store Connect API key from the client's account.
Reconnect push. APNs keys belong to a team. Create one in the client's team (or reuse an APNs-enabled key there) and update OneSignal, Firebase or Pushwoosh accordingly.
Fix universal links. The apple-app-site-association file lists apps as <Application Identifier Prefix>.<Bundle Identifier>. A new App ID in the client's team carries the client's prefix, so update the appIDs entry or links stop opening the app.
Prepare Sign in with Apple. Before an App Transfer, Apple requires a transfer identifier for each existing user; plan that step with your backend.
Update the listing. Support URL, privacy policy and copyright should point to the client, matching the new seller name.

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

Why WebViewGold and appsubmitter.io fit the 4.2.6 model

Honest framing first: WebViewGold, the website-to-app solution made by our team, is a commercialized template in the sense of 4.2.6. That is exactly why its model matters. You buy the Xcode project once, configure your own URL and native modules in Config.swift and publish the result in your own Apple Developer account – the provider of the content submits, as the guideline asks. WebViewGold's license terms also require one license per customized end product, so an agency serving five clients licenses five apps instead of reskinning one.

The native modules are what turn the template into a customized app: push via OneSignal, Firebase or Pushwoosh for the business's own events, QR, barcode or document scanning, Face ID, NFC, widgets, in-app purchases. Use the ones that fit each client's journey, and each app ends up with its own feature set. No tool can promise an approval, but this is the setup 4.2.6 describes.

appsubmitter.io applies the same principle to publishing. We set up certificates, signing and CI/CD in the customer's own developer account, prepare the listing and App Privacy details and communicate with App Review – the app is always published in the customer's account, never in ours. For agencies, that is the "client account, agency as team member" model done for you. Book the iOS service or describe your setup in a free consultation call.

4.2.6 or 4.3? Telling the two rejections apart

	4.2.6 Templates	4.3(a) Duplicates	4.3(b) Saturation
Core question	Who submitted a template-built app?	Are several apps essentially the same?	Is the concept already everywhere?
Typical WebView trigger	An agency or platform account publishes client apps	One wrapper shipped per branch, city or client	Yet another wrapped wallpaper or horoscope site
Fix	Content owner submits, real customization or a picker app	Consolidate, or make each app genuinely different	A meaningfully different or improved experience

The two often arrive together, and fixing one doesn't fix the other. Moving fifty near-identical client apps into fifty client accounts settles who submits, but if the binaries still differ only by URL and icon, they can still be rejected under 4.3(a). A single picker app addresses both at once.

How to answer App Review after a 4.2.6 rejection

Your reply should make the content provider unmistakable:

You moved the app: state that it is now submitted from the client's own developer account, that the client owns the website and its content, and that your agency works as a team member.
You are the content owner and used a builder or template: explain that your company runs the service in the app, link the website whose legal notice names the same entity as the seller, and list the features you customized.
You run a picker app: describe how users choose a business inside the app and how each entry is customized.

Apple's App Review page says partnership documentation or authorization belongs in the Attachment section in App Store Connect, with descriptions or links in the Review Notes. If you believe the reviewer misread your setup – for example because your brand differs from your company name – reply first, then appeal to the App Review Board with specific reasons, or book a 30-minute App Review appointment to explain it.

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 4.2.6.

[Option A – app moved to the content provider]
The app is now submitted directly by [Client legal name], the provider of the app's content. [Client] owns and operates [domain], all content shown in the app and the customer relationship. Our agency, [Agency name], builds and maintains the app as a team member in [Client]'s developer account.

[Option B – we are the content provider]
[Company legal name] operates the service shown in the app and owns [domain]; the website's legal notice names the same company as our seller name. We built the app with [template / builder] and customized it for our customers:
- [Feature 1, e.g. push notifications for order status]
- [Feature 2, e.g. barcode scanning for product lookup]
- [Feature 3, e.g. Face ID sign-in to customer accounts]

[Option C – picker model]
[App name] hosts [number] businesses in one app. Users select a business via search, map or QR code and see its customized pages.

Supporting documents are attached in App Review Information. Demo account: [username] / [password].

Best regards,
[Your name]
[Company]

Checklist before you resubmit

The app is submitted from the developer account of the business that owns the website and its content.
The seller name matches that business's legal name.
Agencies or freelancers work as team members in the client's account, not as the publisher.
Each client app has features and content of its own, not only a different URL, name and icon.
Platforms with many small clients considered a single picker app instead of one app per client.
Certificates, provisioning profiles, APNs key and App Store Connect API key come from the client's team.
The apple-app-site-association file lists the App ID with the client's prefix.
Support URL, privacy policy and copyright name the same business as the seller.
Supporting documents are in the Attachment section, explained in the Review Notes.
Each customized WebViewGold app has its own license.

Frequently asked questions

Why was my WebView app rejected under Guideline 4.2.6?

Apple concluded that the app was built with a commercialized template or app generation service and submitted by someone other than the business whose content it shows. Usually the seller is a website-to-app platform, an agency or a freelancer instead of the website owner. Publishing from the content owner's developer account – or consolidating clients into one picker app – addresses it.

Can an agency publish client apps under its own Apple Developer account?

Not for template-based apps whose content belongs to the client: 4.2.6 says such services should not submit apps on behalf of their clients. The accepted pattern is the client's own account with the agency invited as a team member, for example as Admin or App Manager. The agency still does all the work – only the seller changes.

Am I allowed to build my app with a template like WebViewGold?

Yes. 4.2.6 doesn't ban templates; it requires the content provider to submit and expects customized, unique apps. WebViewGold, made by our team, is used exactly that way: you configure your own website and native modules and publish in your own account. No tool can promise an approval, so customize the app for your users.

Does my client need a D-U-N-S Number to enroll?

If the client enrolls as an organization, yes – Apple uses the D-U-N-S Number to verify the legal entity, with an exception for government entities. The organization's legal name becomes the seller name, and trade names or DBAs aren't accepted. A sole proprietor can enroll as an individual instead, and their personal legal name then appears as the seller.

Can I transfer an existing app to my client without losing its reviews?

Yes, with App Transfer in App Store Connect. The app keeps its ratings, reviews and bundle ID, and users keep receiving updates. It needs at least one version released on the App Store and can't be in review while you transfer it. Prepare the push key, universal links and Sign in with Apple transfer identifiers before you start.

Does appsubmitter.io publish apps under its own account?

No. appsubmitter.io always publishes in the customer's own Apple Developer or Google Play account. We set up signing, CI/CD and the listing there, submit the app and handle the communication with App Review, so the content provider is also the submitter – the setup Guideline 4.2.6 asks for. Code changes aren't included but are quoted upfront if needed.

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 4.2.6: Templates, App Generators and the Right Developer Account