Policy Checker

The Policy Checker scans your store listing metadata for compliance risks before they reach store reviewers. It detects prohibited terms, misleading claims, and competitor trademark usage across all metadata fields, with platform-specific and field-specific severity grading.

The ASO Problem: Policy Violations Are the Fastest Way to Lose Rankings You Earned

Most ASO conversations focus on keywords, screenshots, and conversion copy. Policy compliance barely gets a mention until something goes wrong. And when it goes wrong, the consequences are disproportionate: a listing gets rejected, an update gets stuck in review, or worse, a live app gets flagged and pulled from search results while the team scrambles to figure out why installs dropped overnight.

The root cause is usually something mundane. A title that says “Free” when the store prohibits price references in metadata. A description that still claims “#1 fitness app” from a ranking the app held two years ago. A subtitle that mentions a competitor’s trademarked name, either on purpose (to draft off their search traffic) or by accident (a common word that also happens to be a brand name).

These violations are easy to introduce and hard to catch at scale. Apple and Google each maintain separate sets of metadata rules, and those rules differ by field. What is tolerated in a description may get your title rejected. The prohibited term lists vary between platforms. Misleading claims that pass on Google Play may trigger a block on App Store. A term that is perfectly generic in English might be a registered trademark in another locale.

A rejected metadata update typically delays an App Store release by 3-7 days. For time-sensitive seasonal promotions or feature launches, that delay costs real installs and revenue.

Policy compliance should be automatic, field-aware, platform-specific, and running on every piece of store text before it gets anywhere near a submission. Catching a prohibited term in a title before a human even reviews the draft is orders of magnitude cheaper than debugging a rejection after the fact.

Under the Hood

The Policy Checker operates as a two-phase compliance scan. Phase one checks your text against known prohibited words and common misleading phrases that the stores flag. Phase two uses an AI model to catch competitor trademark references in context. Every flagged term gets a severity rating based on the combination of platform, field type, and violation category.

The platform’s prohibited term lists and claim patterns are maintained by the Apptonomy team and updated when Apple or Google revise their metadata guidelines, so the compliance layer stays current as store policies change.

Prohibited Term Detection

The problem: Both Apple and Google maintain lists of terms they prohibit in metadata fields. “Free” is prohibited on both platforms. “iPhone” and “iPad” are prohibited on App Store. “Android” and “Google Play” are prohibited on Google Play. These seem obvious, but they appear constantly in real listings, especially in localized versions where a translator adds platform references that were absent in the source language.

How the engine handles it: The Policy Checker maintains curated prohibited term lists for each platform. App Store currently has 18 prohibited terms covering price-related language (“free,” “cheap,” “discount,” “sale,” “promo,” “offer”), status claims (“new,” “latest,” “updated”), platform references (“iphone,” “ipad,” “ios,” “apple,” “app store,” “itunes”), and generic filler (“app,” “application”). Google Play has 11 prohibited terms covering similar categories with platform-specific adjustments.

Each term is matched using case-insensitive word-boundary detection, preventing false positives on partial matches. If the app’s own brand name contains a prohibited term (for example, an app called “FreeStyle”), the engine skips that term rather than flagging the app’s own identity.

What you get: A list of flagged prohibited terms, each tagged with the platform it violates, the field where it was found, and a severity rating. Titles and subtitles get “block” severity (these terms will cause a rejection). Descriptions and promo text get “block” for prohibited terms but “warn” for other categories, reflecting the stores’ own enforcement gradient. A typical flag looks like this:

Term	Platform	Field	Severity
free	App Store	title	block
#1	App Store	description	warn
WhatsApp	App Store	subtitle	block

Misleading Claim Detection

The problem: Superlative and unsubstantiated claims are among the most common reasons for App Store review delays. “#1 photo editor.” “Best app of 2024.” “Guaranteed results.” “World’s fastest.” These claims appear in store descriptions everywhere. Some were true once. Some were never verifiable. Either way, the stores increasingly flag them during review.

How the engine handles it: The engine runs 11 regex-based pattern detectors against the listing text, each calibrated for a specific claim type: “#1” rankings, “best” claims, “guaranteed” promises, “number one” variations, “top rated” assertions, “most popular” claims, “award-winning” references, “world’s best/first/leading/fastest” superlatives, “100% safe/secure/guaranteed/free” absolutes, “unbeatable” claims, and “No. 1” rankings in various formats.

Pattern matching is case-insensitive and handles common formatting variations (hyphenated “top-rated,” spaced “No. 1,” hashtag “#1”). Each detected pattern gets a label so the output clearly identifies what was flagged and why.

What you get: A list of flagged misleading claims with the specific pattern that matched, the field location, and a severity rating. On App Store, misleading claims in titles and subtitles receive “block” severity. In descriptions and promo text, they receive “warn” severity. On Google Play, misleading claims get “warn” across all fields.

AI-Powered Competitor Brand Detection

The problem: Competitor trademark usage in store metadata is a policy violation on both platforms, and the most difficult category to catch with static rules. The challenge is context. “Swift” could be an adjective meaning fast, or a reference to Apple’s programming language. “Spark” could describe energy, or reference Spark Mail. A static word list produces too many false positives to be useful, and missing an actual trademark reference creates real legal and compliance risk.

How the engine handles it: The engine sends each text field to a language model with a structured prompt that asks for competitor brand identification. The prompt provides the app’s own brand name (so the model knows what to exclude), the content locale (so the model applies locale-appropriate brand knowledge), and explicit instructions to distinguish between generic word usage and actual brand references. The model returns each detected brand along with the company that owns it.

This approach handles multilingual content natively. The language model knows that “WhatsApp” is always a brand, “spark” is usually generic, and “Photoshop” is an Adobe trademark regardless of the language the listing is written in. It also handles compound references and indirect brand mentions that static rules would miss entirely. When a term is ambiguous (“spark” could be generic energy or a reference to Spark Mail), the engine defaults to warn severity rather than block, flagging it for human review rather than assuming a violation.

What you get: A list of flagged competitor brands with the exact term as it appears in the listing and the brand owner. On App Store, competitor brands in titles, subtitles, and the keywords field receive “block” severity. In descriptions and promo text, they receive “warn” severity. On Google Play, competitor brands receive “warn” across all fields, reflecting Google’s relatively lighter enforcement.

Severity Grading and Field-Aware Enforcement

The problem: Not all violations carry the same risk. A prohibited term in your description might sail through review. The same term in your title will get rejected. Treating every flag with equal urgency leads to alert fatigue; treating them all as low priority leads to missed rejections.

How the engine handles it: The Policy Checker uses a severity matrix that maps every combination of platform, field type, and violation category to either “block” or “warn.” Think of it like a linter for your app listing: block-severity flags are errors that will likely prevent your update from going live, and warn-severity flags are warnings you should review but that probably will not cause a rejection. App Store enforcement is strictest on titles, subtitles, and the keywords field, where all three violation types (prohibited terms, misleading claims, competitor brands) receive “block” severity. Descriptions, promo text, and “what’s new” fields get a more lenient mapping: prohibited terms still block, but misleading claims and competitor brands receive “warn.” Google Play uses a single default mapping across all fields: prohibited terms block, everything else warns.

When the Policy Checker is integrated into content generation workflows, block-severity terms are flagged for removal, and the platform documents each change with an explanation so your team can review what was modified and why before publishing. Warn-severity terms are kept in the text but flagged with a note recommending review before publishing.

What you get: Every flagged term includes a severity level (“block” or “warn”) that reflects the actual risk for that specific platform and field combination. Block flags indicate terms that are very likely to cause a review rejection. Warn flags indicate terms that may be sensitive and should be reviewed but are less likely to trigger an automated rejection. A summary note reports the total count of block and warn flags per field.

Store Text Engine — policy findings inform store text recommendations
Keyword Engine — keyword targeting should avoid policy-violating terms