Guideline 2.3.1 Misleading Marketing: Fix the Claims, Prices and AI Promises Your App Doesn't Keep

Guideline 2.3.1 misleading marketing: what the second half of the rule covers

Guideline 2.3.1 misleading marketing means promoting your app with content, services or a price it doesn't actually deliver – in the listing, inside the app or anywhere else you advertise it. The first half of 2.3.1(a) is about documenting features for App Review; this half is about the promises you make to customers, and it carries Apple's harshest consequences.

The sentence follows the Notes for Review requirement in the App Store Review Guidelines (last updated June 8, 2026):

Similarly, marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price, whether within or outside of the App Store, is grounds for removal of your app from the App Store or a block from installing via alternative distribution and termination of your developer account.

• Content or services the app doesn't offer. Apple's example shows the logic: an iOS app can't scan the device for malware, because Guideline 2.5.2 says apps "may not read or write data outside the designated container area". An app promoting features it doesn't offer for simpler reasons – say, a website-only feature – is caught by the same sentence.
• A false price: "free" that isn't, discounts that don't exist, a web price presented as the app price.
• Within or outside of the App Store: listing, app, website, ads, social posts, newsletters, influencer briefs.

Guideline 5.6.2 points the same way: your representation of "your offerings" must be accurate. For the documentation half of 2.3.1, see Notes for Review that pass 2.3.1.

Removal, not just rejection: why this half of 2.3.1 is riskier

An undocumented feature usually costs you a rejection and a resubmission. Misleading marketing is framed as a reason to remove the app and end the developer account, and 2.3.1(b) adds: "Egregious or repeated behavior is grounds for removal from the Apple Developer Program."

Timing differs too. Ads, landing pages and social posts change after approval, so the problem doesn't have to surface during review – the wording covers the live app and everything promoting it. In 2025, Apple rejected over 371,000 submissions for copying other apps, spam or otherwise misleading users, removed nearly 59,000 apps for bait-and-switch maneuvers and terminated 193,000 developer accounts over fraud concerns (Apple Newsroom, May 20, 2026).

Customers feed into this. Guideline 5.6.4 lists "excessive customer reports", negative reviews and "excessive refund requests" as signs that an app falls short, which may count when Apple judges a developer's conduct – and people who paid for a promise the app doesn't keep produce all three.

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 →

Why are WebView and AI-built apps especially exposed?

In a native app, marketing mostly lives in the listing. In a WebView app it often lives inside the app, because the app loads the website that sells it. Whatever your landing page claims, the reviewer may read on the first screen:

• Social proof: "trusted by 20,000 teams", star ratings, testimonial carousels, "as seen in" logos.
• Feature lists and comparison tables with a desktop editor, browser extension, integrations or an API the iOS app lacks.
• Price banners: "free forever", "50% off today only", "lifetime deal".
• Store badges for other platforms – a separate issue under Guideline 2.3.10.

AI-built apps add a second layer. AI builders and copy generators fill landing pages with plausible numbers and quotes because the templates expect them: testimonials from people who don't exist, a "4.9 rating", "10,000+ users" for an app launched last week. Nobody meant to deceive – the placeholders simply went live – but to customers and reviewers they are claims. Our pillar on 2.3.1 rejections of AI-built apps covers the hidden-feature side of the same habit.

Outside the App Store, the same copy spreads into ads, social posts and emails, often with the boldest promises. App Review doesn't see your ad account, but the guideline covers it.

False price: "free" claims, web prices and trials that don't match

A false price is any price statement that doesn't match what someone pays through the App Store. Three mismatches dominate in WebView apps.

"Free" in front of a hard paywall

Free to download with paid plans is a normal model; an unqualified "free" followed by a paywall on the first useful screen isn't. Guideline 2.3.2 asks your description, screenshots and previews to "clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases", and 2.3.7 keeps prices out of names, subtitles, screenshots and previews. Say what is free and what costs money – the same way everywhere.

Web prices inside the app

App Store prices are set in App Store Connect and shown in each storefront's currency, so a price typed into your CMS is wrong for many App Store customers even when it's right in the browser. For digital goods, the web checkout shouldn't appear in the app at all – see Guideline 3.1.1 for WebView apps. In app mode, leave the price to the native purchase sheet or pass StoreKit's localized price to the page.

Trials and discounts

Guideline 3.1.2(a) lets subscription apps offer a free trial "by providing the relevant information set forth in App Store Connect", so the trial in your ads must be the introductory offer you configured. "14 days free" on the website and a 7-day offer in the app is a false price in miniature – as are countdowns and strike-through prices App Store customers can't get. Apps that trick users into subscribing "under false pretenses" will be removed, the guideline adds. Paywall details are in the 3.1.2 Subscriptions guide.

AI claims: "AI-powered", model names, accuracy and third-party AI

AI features attract bold copy, and 2.3.1 treats them like any other feature. Four claims cause most of the trouble:

• "AI-powered" without a feature to find. If the reviewer can't locate and test it, it's a promoted service the app doesn't offer. Name the feature and its screen in your review notes.
• Model and provider names. "Powered by [model]" ages fast – switch providers on your server and the claim turns false without a new build. Popular AI app names in your app name or keywords also collide with the 2.3.7 rule against "trademarked terms, popular app names".
• Accuracy and outcome claims. "99% accurate", "diagnoses skin conditions", "replaces your accountant". For health measurements, Guideline 1.4.1 is explicit: "Apps must clearly disclose data and methodology to support accuracy claims relating to health measurements, and if the level of accuracy or methodology cannot be validated, we will reject your app." For diagnostic claims, Apple's complete-review page asks for regulatory clearance, a test report or a peer-reviewed study.
• "Unlimited" and "private". Unlimited chats with a hidden daily quota, or "your data never leaves your phone" while prompts go to a cloud model, are false claims.

The privacy claim meets Guideline 5.1.2(i): you must "clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so". Since privacy information is metadata under 2.3, a "private" website, empty App Privacy details and a missing consent screen contradict each other. Name the provider in a consent prompt before the first request, in the privacy policy and in App Privacy details – see Guideline 5.1.2 for WebView apps.

Audit table: every claim, where it shows up and how to fix it

Collect every surface first – app pages, landing pages, the listing in every locale, onboarding, ads, social profiles, emails – then go claim by claim:

Metadata has extra rules: under 2.3.7, subtitles must not "make unverifiable product claims", and under 2.3.3 screenshots "should show the app in use" – a caption promising a feature the build lacks fails both. Field-by-field details are in our 2.3 Accurate Metadata guide and the 2.3.3 Screenshots guide. Promotional text is the quickest fix: App Store Connect lets you change it without a new submission.

App-mode detection: clean presentation, not a hiding place

A WebView app may – and usually should – look different from your website. WebViewGold, the website-to-app template built by our team, offers two tools for it: a custom user agent per device type (useragent_iphone and useragent_ipad in Config.swift), so your server can tell app requests from browser visits, and Custom CSS & JS applied to every page the app loads. Use them to remove the marketing header, newsletter pop-ups, "get the app" prompts and other stores' badges, or to swap web purchase flows where 3.1.1 requires In-App Purchase.

What app mode can't do is make a false claim true. Hide an invented testimonial carousel in the app and it stays on your website and in your ads – both "outside of the App Store", both still covered. Content that disappears only during review is a conduct issue; see Guideline 5.6 for WebView apps. Fix the claim where it's written – CMS, landing page builder, ad set – and use app mode for layout only.

Sometimes the honest fix is delivering the promise. If your marketing mentions push notifications, Face ID or a barcode scanner, WebViewGold adds them as native modules. "Works offline" needs care: the native offline screen tells users they're offline but doesn't make content available – only screens bundled as local HTML work without a connection. WebViewGold is a one-time purchase and the project is yours, yet no tool can promise an approval.

How to fix the claims and reply to App Review

1. Find the claim Apple means. Start with what the message names; if it's vague, ask in your reply and run the full audit anyway.
2. Correct it at the source – website, CMS, ad sets, social bios, email templates – and keep dated before-and-after screenshots.
3. Align prices and offers with App Store Connect for every storefront you sell in.
4. Update the listing in every locale, screenshots and promotional text included.
5. Upload a new build only if the claim lives in the binary – local HTML, injected CSS or native strings.
6. Reply in App Store Connect with a claim-by-claim list (up to 4,000 characters, files attached) and resubmit. If you think Apple misread your marketing, appeal to the App Review Board.

appsubmitter.io takes this off your desk as part of a submission: our AI-powered pre-submission check compares listing and in-app claims with what the build does, and an App Specialist reviews borderline wording, prepares the store listing and App Privacy details and answers App Review in your own developer account. Rewriting your website or code isn't included – if it's needed, we quote it upfront. Book the iOS service or start with a free consultation call.

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 pointing out the marketing issue under Guideline 2.3.1.

We have checked every place where we promote the app – the app itself, our website [domain], the App Store listing in all localizations and our current ads – and corrected the following:

1. "[Claim, e.g. Free forever]" now reads "[new wording, e.g. Free to download; Premium is an optional subscription]" on [website / description / ads].
2. "[Claim, e.g. Used by 10,000+ teams]" has been removed because we could not document it.
3. "[Claim, e.g. AI accountant]" now reads "[accurate description of the AI feature]". Users give permission before any data is sent to [AI provider].
4. The [trial / price] we advertise now matches the introductory offer in App Store Connect ([trial length]).

[If a new build was needed:] Build [build number] removes [claim] from [local screen / onboarding].

Before-and-after screenshots are attached. Every feature we promote is available in this version and can be tested with [username] / [password].

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Every page the app loads has been read as marketing: hero text, testimonials, counters, badges, feature tables, price banners.
• User counts, ratings, testimonials and customer logos are real, current and documented – or removed.
• Feature lists only promise what the iOS build offers; platform-specific features are labeled.
• "Free" claims say what needs a purchase, consistently on the website, in ads and in the listing.
• Prices, discounts and trial lengths match App Store Connect; no web-only offers appear in the app.
• AI claims describe a feature the reviewer can find, accuracy figures are backed by data, and data sent to third-party AI is disclosed with consent.
• Name, subtitle, keywords, screenshots and promotional text carry no prices, rankings or unverifiable claims.
• App mode only adapts presentation; no claim is hidden in the app while it stays live elsewhere.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 2.3.1
• Apple – App Store Review Guidelines, 2.3 Accurate Metadata
• Apple – App Store Review Guidelines, 5.1.2 Data Use and Sharing
• Apple – Provide information for a complete review
• App Store Connect Help – Platform version information (promotional text, App Review Information)
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
• Apple – App Review: appeals and App Review Board

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.