Conflicts, where sources disagree and what won

Read this one on its own. It is the most useful output of the project, because it is a list of things you may still believe.

Twenty-seven findings, each checked against Apple’s or Google’s current documentation on 2026-09-18 to 2026-10-06. Each states what was believed, where the belief came from, what the documentation says now, which won, and, the part that matters, why it changes what you do.

Three kinds of finding

Superseded. The source was right when written and the platform moved. No fault, but it will still put a wrong number in a deck. (001, 008, 009, 010, 013, 014, 023)

Wrong. The claim was not supported when it was made. More dangerous, because these spread by repetition rather than by age and nothing about them looks stale. (002, 003, 011, 012, 015, 020)

Definitional. Nothing is stated incorrectly, the words mean something other than you assume. The hardest class to catch, because every chart still renders and every number still looks reasonable. (005, 016, 017, 018, 021)

Resolved. An open question that has since been settled, kept because the misleading source is still live. (004, 019, 024)

The five that would change your work today

If you read nothing else:

CONFLICT-016. App Store conversion rate is total downloads and pre-orders divided by unique device impressions, including redownloads. Not page views to installs. Every conversion benchmark in your folder assumes the other definition, and a lower iOS rate than Android is the expected consequence of the definitions rather than a finding about the app.

CONFLICT-017, applying age or gender targeting in Apple Ads excludes the devices responsible for roughly 78% of App Store search volume. Documented by Apple, and absent from every source you have, including the Apple Ads certification material.

CONFLICT-013, since July 2026 Google Play measures store listing performance in clicks, not acquisitions. A definition change, not a data change, so every Play comparison spanning mid-2026 is silently wrong.

CONFLICT-002, the iOS description is not named by Apple as a search input at all. The “first 245 characters” rule is a Play heuristic applied to a field that is not indexed, and acting on it is effortful work that does nothing.

CONFLICT-009: custom product pages are now 70, not 35, and each can carry its own keywords. Most people still treat them as a creative tool for paid traffic rather than an indexed surface.

The full list

	Finding	Kind
001	In-app purchase limits are 35 and 55 characters, not 30 and 45	superseded
002	“First 245 characters of the description are crucial”	wrong
003	“Google Play has a subtitle”	wrong
004	Keyword field: Apple’s own pages disagree. It is 100 characters	resolved
005	“Editable” in Apple’s table does not mean “live”	definitional
006	“Additional locales give +200 characters”	technique real, arithmetic unsupported
007	Title truncation is a range, not a number	false precision
008	Age rating tiers changed at OS 26. And 16+ was added	superseded
009	Custom product pages: 70, not 35, and they carry keywords	superseded
010	Google Play title dropped from 50 to 30 characters in 2021	superseded
011	Keyword density in the Play description	contradicted by Google’s own example
012	Keywords in the Play package name	wrong, and irreversible
013	Play store listing performance now counts clicks	superseded, July 2026
014	iOS screenshot requirements: 6.5-inch and 13-inch	superseded
015	“User reviews are indexed”	unsupported
016	App Store conversion rate is not what almost anyone computes	definitional
017	Demographic targeting in Apple Ads excludes ~78% of search volume	not in any source
018	Custom product page keywords route traffic; they do not expand your keyword space	this base got it wrong
019	App tags do have a control surface: deselect-only, US-only	resolved
020	Most iOS creative and store settings are release-bound; this base said they were not	resolved
021	Apple’s search popularity is documented as 1–5, not 5–100	resolved
022	Apple says drop the plural; practitioners say test it	open
023	Apple’s own certification course is behind Apple’s own help pages	superseded
024	This base’s own release-process page contradicted its own metadata page	resolved

Status: all thirteen sections complete. Every finding below carries the URL it was checked against and the date.

Two entries (018 and 019) are corrections to this knowledge base, not to the source folder. They are here because a reference work that hides its own errors is worth less than one that logs them.

CONFLICT-001: In-app purchase character limits · superseded

Believed: IAP display name up to 30 characters, IAP description up to 45.
Source: The Advanced App Store Optimization e-Book, Phiture, 2022, the most authoritative single document in the source material.
Current documentation: Display name 35 characters, description 55 characters. (Creating your product page, verified 2026-09-18)
Winner: Apple. Claims IOS-IAP-001, IOS-IAP-002.

Why it matters: the e-book was right in 2022. This is the clearest illustration in the source material of why a four-year-old reference cannot be trusted on numbers even when it is excellent on reasoning. Twenty extra characters on a subscription name is a materially different piece of copy.

CONFLICT-002: “The first 245 characters of the description are crucial” · wrong

Believed: the opening 245 characters of the iOS app description are critical for keyword optimisation.
Source: ASO Competitor Analysis E-Book, Elena Vedmedenko / Keyapp.top, where it is asserted four separate times. It circulates well beyond that document.
Current documentation: Apple names its text-relevance inputs as title, subtitle, keywords and primary category. The description is not among them. (App Store search, verified 2026-09-18)
Winner: Apple. Recorded as tier C in claim IOS-DESC-001, kept in the base specifically so the belief is documented and refuted.

Why it matters: this is the most expensive wrong belief in the source material, because acting on it feels like work. Writing keyword-dense opening paragraphs takes real effort, produces something that looks optimised, and on iOS does nothing for search.

The number appears to be an import from Google Play, where the description genuinely is indexed and where the visible-before-truncation portion does matter. A correct Play heuristic applied to an iOS field that is not indexed. See kb/20-google-play-metadata/20-08-writing-for-play-vs-ios.md.

What to do instead: write the iOS description for the reader, not the algorithm. It is a conversion asset.

CONFLICT-003: “Google Play has a subtitle” · wrong

Believed: Google Play has a subtitle field, variously described as 80 characters. One source additionally lists a keyword field under Google Play.
Sources: ASO Beginner’s Handbook, AppTweak. “Subtitles have varying lengths in the App Store and Google Play (30 characters and 80 characters respectively)”. The Keyword Promotion Playbook, Keyapp.top appears to list both a subtitle and a keyword field under a Google Play heading.
Current documentation: Google Play store listing fields are app name (30), short description (80), full description (4000). There is no subtitle. There is no keyword field. (Create and set up your app, verified 2026-09-18)
Winner: Google. Claim PLAY-MD-001.

Why it matters: it conflates the iOS subtitle with the Play short description. The two fields have genuinely different jobs, the iOS subtitle is indexed and sits under the name on the product page; the Play short description is indexed and is the text shown before a user expands the listing. Teaching them as the same field produces copy that is wrong for both.

The B16 instance may partly be a PDF extraction artefact from a two-column layout, and is marked provisional pending a visual check of the original. The B4 instance is unambiguous.

CONFLICT-004, Keyword field: Apple’s own two pages disagree · resolved, 100 characters

Page	Wording
Creating your product page	“Keywords, up to 100 characters total”
Platform version information	“You can provide up to 100 bytes of content”

Both verified 2026-09-19. The reference-page wording was confirmed against raw page source, so it is not a transcription error on this side.

Resolved: the working limit is 100 characters, including in non-Latin locales, confirmed from App Store Connect use, 2026-09-19. Claims IOS-MD-003, IOS-KW-001.

Why it was worth resolving rather than guessing. For English the two readings are identical. For anything else they are not: in UTF-8 a CJK character costs 3 bytes, so a strict byte ceiling would have meant roughly 33 Chinese characters rather than 100, a threefold difference in the keyword budget for some of the largest storefronts in the world.

The byte reading was not obviously wrong on its face. Apple uses “bytes” elsewhere on the same reference page, for the App Review notes field, so it did not read as loose wording. It simply is not what the field does.

Why it stays in this log now that it is settled. Apple’s reference page still says bytes. Anyone reading that page in a year will re-derive the same wrong conclusion, and it is the more authoritative-looking of the two pages. The entry exists so the next person finds the answer instead of the discrepancy.

What it means in practice: CJK keyword fields genuinely do carry more meaning per character, and that advantage is not cancelled by encoding cost, one of the few places a locale gives you more rather than less. See kb/30-keywords/30-06-cjk-and-rtl-specifics.md.

CONFLICT-005: “Editable” does not mean “live” · Apple’s own table misleads

Believed, reasonably: Apple’s Required, localizable, and editable properties table marks the app name and subtitle “Editable”, so they can be changed on a live app.
What Apple says elsewhere: you can edit the name until you submit to App Review; afterwards you can change it when you create a new version, or when the status of the app version permits editing this property. (App information, verified 2026-09-18)
Winner: the precise wording. Claims IOS-MD-008, IOS-VER-001.

Why it matters: the table’s “Editable” column means editable when the version status permits, not reaches users without a submission. App Store Connect will let you type in the field on a live app, which reinforces the misreading. The change still ships with a version and still goes through review.

This is not a source-folder error. It is a genuine ambiguity in Apple’s own documentation, and it is the most common cause of a missed ASO commitment. The operational question is always: does this reach users without a submission? For name, subtitle, keywords, description and What’s New the answer is no. See kb/10-app-store-metadata/10-09-what-requires-a-new-version.md.

CONFLICT-006: “Additional locales give you +200 characters” · technique real, arithmetic unsupported

Believed: most countries have two additional locales beyond their native one, so metadata can be extended by a flat +200 characters.
Source: Basics of ASO for Google Play and the App Store, ASOMobile.
Current documentation: Apple’s localizations reference lists 50 languages and locales, and states that each storefront has a default language plus a set of additional supported languages, which differ by storefront: the US supports eight additional languages, Germany one, India ten. (App Store localizations, verified 2026-09-18)
Winner: Apple, partially. Claims IOS-LOC-001, IOS-LOC-002.

Why it matters: the underlying technique is real, adding a localization does add another indexed name, subtitle and keyword set within storefronts that support it. But there is no uniform “+200 characters”, the number of additional languages varies from one to ten by storefront, and the mapping changes over time.

Treat locale stacking as B established practice, verify the current storefront-to-language mapping before planning around it, and never quote the character arithmetic as a fact.

CONFLICT-007: Title truncation is a range, not a number · false precision

Believed: iOS titles truncate at a specific character count. The source material variously states 23, 25, 26 and “22–27”.
Current documentation: Apple documents the 30-character field. Apple does not document where the rendered string is cut.
Winner: nobody. Recorded as claim IOS-TRUNC-001 at tier [B], as a range of roughly 23–27 characters.

Why it matters: this is an observation of a layout that varies by device, surface and locale, being reported as a constant. Four sources give four numbers, which is exactly what you would expect. The base states the range and the reason for it, and tells you to check on a real device in your priority storefronts.

Less useful than a single number, and more honest. A deck that says “26 characters” is repeating false precision.

CONFLICT-008: Age rating tiers changed at OS 26 · superseded

Believed: App Store age ratings are 4+, 9+, 12+ and 17+.
Current documentation: the tiers are 4+, 9+, 12+, 13+, 17+ and 18+, updated with OS version 26, and the rating shown may differ depending on the user’s OS version. (Set an app age rating, verified 2026-09-18)
Winner: Apple. Claims IOS-AGE-001, IOS-AGE-002.

Why it matters: every source reviewed here predates this. Any material listing four tiers is now wrong, and the OS-dependent behaviour means two users can see different ratings for the same app.

CONFLICT-009: Custom product pages: 35 or 70? · superseded

Believed: an app can have up to 35 custom product pages, varying screenshots, previews and promotional text only.
Source: A Comprehensive Guide to CPPs, AppTweak, 2023, and general practitioner consensus.
Current documentation: “You can publish up to 70 additional versions of your product page on the App Store for iPhone and iPad.” Each can vary screenshots, app previews, promotional text, keywords, and (on iOS 18 and later) a deep link. (Custom Product Pages, verified 2026-09-18, corroborated by App Store Connect Help)
Winner: Apple. Claim IOS-CPP-001.

Why it matters: two changes, and the second is the bigger one. The count doubled. But custom product pages are now a keyword surface, which is not how most practitioners think about them. They are widely treated as a creative-variation tool for paid traffic. Detail belongs in section 60; logged here because the belief is so widely held.

CONFLICT-010: Google Play title length: 50 or 30? · superseded

Believed: Google Play app titles allow 50 characters.
Sources: the Advanced ASO e-Book correctly traces the history, but older items in the source material still write to the longer field.
Current documentation: 30 characters. (Create and set up your app, verified 2026-09-18)
Winner: Google. Claim PLAY-MD-001.

Why it matters: the limit dropped from 50 to 30 in September 2021. Any guidance written before that assumes a field nearly twice the size, so its advice on how many terms fit is wrong by construction, not just out of date. Play and the App Store now share a 30-character title. But the App Store adds a 30-character subtitle and a 100-byte keyword field, so total indexed text is still not comparable.

CONFLICT-011: Keyword density in the Play description · contradicted by Google’s own example

Believed: repeat your main keyword a set number of times in the Play full description, commonly “five times”, or to a stated density percentage.
Sources: widespread. The Keyword Promotion Playbook and ASO Competitor Analysis E-Book both give repetition guidance; the Advanced ASO e-Book (A1) states Google considers keyword density.
Current documentation: Google advises avoiding “excessive length, detail, improper formatting, and repetition of words”, and publishes an example of what not to write: a keyword list beginning “Car racing, car driving, race cars, car races…”. The Metadata policy makes it enforceable, prohibiting “repetitive or unrelated keywords or references”. (Best practices; Metadata policy, both verified 2026-09-18)
Winner: Google, on the policy question. Claims PLAY-MD-004, PLAY-POL-003.

Why it matters: this is subtler than a wrong number, so it is worth being precise about what is and is not established.

That Google weighs term frequency in the description to some degree is [B], consistently reported by independent practitioners, and consistent with Google naming the description as a metadata input. That is not disputed here.

What is wrong is the leap from “frequency matters” to “repeat it five times”. No source for a specific target is credible, the numbers vary wildly between vendors, and following them produces text that matches Google’s own published counter-example and is prohibited by the Metadata policy. The advice optimises for an undemonstrated mechanism against documented guidance.

What to do instead: use your terms naturally, in prose a person would read. If a term appears often, it should be because the app is genuinely about that thing.

CONFLICT-012: Keywords in the Play package name · wrong, and irreversible

Believed: putting keywords in the Android package name helps Play ranking.
Source: #Tips - Package Name (Play Store).pdf (folder item, tier C social carousel), which advises picking a “unique package name” for ranking purposes.
Current documentation: Google names title, description and category as the metadata it uses to identify an app. The package name is not mentioned as a discovery input anywhere. It is documented as unique and permanent. It “can’t be deleted or re-used”. (Create and set up your app, verified 2026-09-18)
Winner: Google. Claim PLAY-MD-002.

Why it matters: this is the worst risk-to-evidence ratio in the source material. The claimed benefit is undocumented and unmeasured. The cost of acting on it is permanent: a package name, once used, is gone forever, and “changing” it means publishing a new listing with zero installs, zero ratings and no review history.

An unevidenced ranking theory is never worth an irreversible decision.

CONFLICT-013: Play store listing performance now counts clicks, not acquisitions · superseded, July 2026

Believed: Google Play store listing performance is measured in acquisitions, store listing visitors converting to installs, and conversion rate means acquisitions ÷ visitors.
Sources: every Play benchmark and reporting template in the source material, and the ASO & ASA Audit series, which is built on acquisition-based conversion rates.
Current documentation: “From July 2026, Google Play updated store listing performance reports to focus on user intent (clicks) rather than successful outcomes (acquisitions).” The primary metric is now Unique user Install Clicks, unique users who clicked the Install button. Legacy acquisition data remains available in Statistics and exports. (Understand and grow your app’s user base, verified 2026-09-18)
Winner: Google. Claim PLAY-ACQ-002.

Why it matters: this is a definition change, not a data change, which is the most dangerous kind. The reports still exist, the charts still render, the numbers still look like conversion rates. And they are measuring something different.

A click on Install is not an install. It precedes the download and can fail, be cancelled, or be a returning user. So a click-based conversion rate is structurally higher than the acquisition-based one it replaced, and any trend line that crosses mid-2026 shows a step change that is an artefact of the definition.

What to do:

Any Play conversion benchmark from before mid-2026 is not comparable to one after it. Do not put them on the same chart.
Historical acquisition data is still available in Statistics and exports, use it explicitly when you need a like-for-like comparison.
Say which metric you mean in every report. “Conversion rate” is now ambiguous on Play.

This is exactly the failure mode the verification dates exist for: Google renamed and redefined a report, nothing broke visibly, and every comparison silently became wrong.

CONFLICT-014, iOS screenshot requirements · superseded

Believed: the required iPhone screenshot sizes are the 5.5-inch and 6.5-inch sets, with iPad at 12.9 inches.
Source: The Ultimate Guide to App Store Screenshots, SplitMetrics (~2021), and every creative guide in the source material of similar vintage.
Current documentation: the required sets are 6.5-inch for iPhone and 13-inch for iPad. Omitted smaller sizes are scaled automatically down a defined chain. (Screenshot specifications, verified 2026-09-18)
Winner: Apple. Claims IOS-CRE-001, IOS-CRE-002.

Why it matters: the required-size list changes roughly annually as Apple ships hardware, which makes this the fastest-rotting fact in the base, treated as a high re-verification priority.

The second-order point is more useful than the sizes themselves. Because Apple now scales from larger sets, a team can ship one set and be technically compliant everywhere, while caption text sized for a 6.5-inch frame becomes proportionally smaller on every device below it. The old guidance assumed you supplied each size deliberately. The current behaviour lets you not think about it, which is worse.

CONFLICT-015: “User reviews are indexed” · unsupported

Believed: review text is indexed by App Store search, so keywords appearing in user reviews help an app rank.
Source: Basics of ASO for Google Play and the App Store, ASOMobile, which also states review length is capped at 500 characters.
Current documentation: Apple names its text-relevance inputs as title, subtitle, keywords and primary category, and separately names downloads, ratings and reviews under user behaviour. (App Store search, verified 2026-09-18)
Winner: Apple, on the distinction. Recorded as tier C in claim IOS-REV-001.

Why it matters: the two claims are easy to conflate and they are not the same.

That ratings and reviews influence ranking as a behavioural signal is [A]. Apple says so directly. That the words inside review text are indexed as searchable content is a different assertion, and nothing in Apple’s documentation supports it.

The practical difference is large. If review text were indexed, seeding reviews containing target keywords would be an ASO tactic. And it is one that gets recommended. It rests on a conflation, it is unevidenced, and soliciting reviews with specified content is separately a review-manipulation problem on both platforms.

What to do instead: work on the rating, which is documented as influencing ranking on both platforms, through prompt timing and review responses (40-08).

The 500-character review length claim remains unverified. It is a user-facing limit not documented in developer materials, and is not load-bearing for anything.

CONFLICT-016: App Store conversion rate is not what almost anyone computes · definitional

Believed: App Store conversion rate means product page views → downloads. Every conversion benchmark, audit template and reporting deck in the source material assumes it, including the ASO & ASA Audit series and The Product Page Analysis Cheat Sheet.
Current documentation: Apple defines it as “Total downloads and pre-orders divided by unique device impressions.” Impressions are “the number of unique devices that have viewed your app on the Today, Games, Apps, and Search tabs” and explicitly “includes unique product page views”. Total downloads is “the sum of First Time Downloads and Redownloads”. (Metric definitions, verified 2026-09-18)
Winner: Apple. Claims IOS-AN-001, IOS-AN-003, IOS-AN-004.

Why it matters, four independent problems in one ratio:

The denominator is impressions, not page views. It counts everyone who saw your icon in a list without opening anything. Apple’s rate is mechanically far lower than the page-view ratio people quote.
The numerator includes redownloads. A win-back campaign raises “conversion rate” while acquiring nobody new.
It includes pre-orders, counted at pre-order and not again at download.
Impressions include product page views, so the funnel does not decompose. You cannot subtract to get “impressions that did not reach the page”.

The practical damage. A team reads Apple’s conversion rate from App Store Connect, compares it to a vendor benchmark computed as page-views-to-installs, concludes the app converts badly, and spends a quarter redesigning screenshots to close a gap that is entirely definitional.

Cross-platform it is worse still. Google’s rate is first-time installers over store listing visitors, and Google’s definition of visitors excludes users who already installed the app. Different numerator, different denominator, users versus devices. A lower iOS conversion rate than Android is the expected consequence of the definitions. See kb/80-analytics-and-measurement/80-03-where-the-two-are-not-comparable.md.

What to do: state the definition beside every conversion figure, never compare the two platforms’ raw rates, never benchmark either against a vendor number computed differently, and split first-time downloads from redownloads before concluding anything about acquisition.

CONFLICT-017: Demographic targeting in Apple Ads excludes ~78% of search volume · not in any source

Believed: age and gender refinement in Apple Ads is an ordinary targeting option, comparable to device or location, used to focus spend on a relevant audience.
Sources: every Apple Ads guide and deck in the source material that covers audience settings treats demographics as a routine refinement. None mentions a reach cost.
Current documentation: “78 percent of App Store iOS 17 and later search volume came from devices with Personalized Ads turned off.” And: applying age or gender refinements “automatically exclude[s] customers with Personalized Ads turned Off.” (Modify audience settings, verified 2026-09-18)
Winner: Apple. Claim ADS-AUD-002.

Why it matters: put the two sentences together and applying a demographic refinement removes the devices responsible for roughly four fifths of App Store search volume.

This is not a conflict where an old number was superseded. It is a fact that is documented, current, enormously consequential, and absent from every source reviewed here, including the Apple Ads certification material and the dedicated Apple Ads book.

The interface presents demographics beside device and location as though the three were comparable. They are not. Device and location narrow who sees the ad; demographics narrow and silently remove the majority of the addressable audience.

What to do: treat “no demographic refinement” as the default. Use age or gender only where a legal or policy requirement demands it, or where a test has shown the efficiency gain genuinely exceeds a ~78% volume loss, which it rarely will.

The diagnostic worth remembering: a campaign that will not spend its budget, with thin impressions but acceptable conversion, is usually an audience-settings problem rather than a bidding problem. Check audience settings before touching bids.

CONFLICT-018: Custom product page keywords route traffic; they do not expand your keyword space · this base got it wrong

Believed, including by this knowledge base until 2026-09-19: custom product pages carry their own keywords, making each page an additional indexed surface and expanding the iOS keyword space beyond the 30 + 30 + 100 characters of the default listing.
Current documentation: “You can assign keywords from your latest approved app version to a custom product page. This directs customers to your custom product page when they search those keywords, rather than your default product page.” Keywords can be assigned at any time, but the page is searchable only once approved and set to visible; Apple advises a unique set of keywords per page; and assigned keywords can be disabled individually. (Configure multiple product page versions, verified 2026-09-19)
Winner: Apple. Claim IOS-CPP-004.

Why it matters: the operative phrase is from your latest approved app version. You are selecting from keywords that already exist in your approved keyword field, not writing new ones. So a custom product page is a routing mechanism, not a keyword surface:

Your indexed keyword space is unchanged, still 30 + 30 + 100 characters per localization
What changes is which page a given query lands on

That is genuinely valuable, a query about one feature arriving on a page about that feature converts better than the same query arriving on a generic page, but it is a different claim from “CPPs give you more keywords”, and planning built on the second is planning for reach you will not get.

Apple’s advice to use a unique set per page follows mechanically: two pages claiming the same keyword gives Apple no basis to choose between them.

And the documentation and the interface use different words. Apple’s help pages say keywords; App Store Connect labels the selection “tags”, offering the keyword field entries for that localization, a CPP with a Spanish localization offers the terms from your Spanish keyword field (confirmed from console use, 2026-09-19).

That matters twice over. It is why the feature is easy to misread as a free-text keyword field. And it collides with App Store Tags (CONFLICT-019), a completely different app-level feature that is Apple-generated, deselect-only and US-only. Two features, one word, opposite behaviour, one is your own keywords, the other is Apple’s output.

A practical consequence worth drawing out: because CPP routing draws from that localization’s keyword field, a market with a thin or neglected keyword field has thin routing options. The quarterly keyword refresh and the custom product page plan are therefore the same exercise, not two.

Recorded here as a correction to this base, not to the source material. The earlier version of kb/60-custom-pages-and-targeting/60-01-ios-custom-product-pages.md described CPPs as an additional indexed surface and flagged it for console confirmation. The confirmation came back the other way. This is what the open-items list is for.

CONFLICT-019: App tags do have a control surface, and it is narrower than it sounds · resolved

Believed, including by this knowledge base until 2026-09-19: app tags are generated by Apple from your metadata with no developer control surface at all.
Current documentation: app tags are “glanceable terms that help people understand more about your app or game’s essential qualities”, based on “the App Store metadata you provide in App Store Connect, artificial intelligence, and human curation”, appearing in search results and on the product page. “You can deselect the tags you don’t want associated with your app.” Apple cautions that “deselecting all tags may affect your discoverability.” And: “Currently, tags are only supported and displayed to users across the App Store in the United States.” (Manage app tags, verified 2026-09-19)
Winner: Apple. Claims IOS-RANK-003, IOS-TAG-001.

Do not confuse these with the “tags” shown when configuring a custom product page. Those are your own keyword field entries for that localization. See CONFLICT-018.

Why it matters: there is a control, and knowing its exact shape prevents two opposite errors.

Deselect-only. You can remove a tag you do not want. You cannot add one you would prefer. So this is a hygiene lever, removing a tag that misrepresents the app, not a targeting lever.

US-only, currently. A tag audit is a US-market task today. Teaching it as a global lever would waste people’s time in every other storefront.

Human curation is in the mix, not only metadata and AI. That makes the generated set less mechanically predictable from your metadata than an LLM-only process would be.

Resolves the open question flagged in Phase 2, where this base stated that no control surface was documented. One was. It had simply not been found.

CONFLICT-020: Most iOS creative and store settings are release-bound; this base said they were not · resolved

Believed: by this knowledge base until 2026-09-19, and widely in practice: on iOS the app icon, screenshots, app previews, primary and secondary category, age rating and the support and marketing URLs can all be changed on a live app without submitting a new version.

Current documentation: they cannot.

Ready for Distribution, the status of a live app, carries a blank Editable mark. (App and submission statuses, verified 2026-09-19) Every editable status is a state of a version that has not shipped.
Icon: “If you want to change your app icon after publishing, you must create and upload a new version of your app. Then, submit it for review.” (Add an app icon, verified 2026-09-19) It ships in the build’s asset catalog, so it needs a binary, not merely a version record.
Screenshots and previews: uploadable only while the status is Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected or Developer Rejected; removable only “when the app status is editable”; not editable at all while Waiting for Review. (Upload app previews and screenshots, Remove app previews or screenshots, verified 2026-09-19)
Categories, age rating, support URL, marketing URL, privacy policy URL: all carry an empty Editable cell. (Required, localizable, and editable properties, verified 2026-09-19)

What genuinely moves without a version is short: promotional text (Apple: informs visitors “without requiring an updated submission”), price and availability, the privacy data types, and the surfaces that carry their own submission: custom product pages, in-app events, IAP metadata.

Winner: Apple, confirmed against console behaviour on 2026-09-19. Claims IOS-VER-001, IOS-VER-002, and new IOS-VER-005, IOS-VER-006, IOS-VER-007.

Follow-up, same day: a residual instance was found in 10-08, which stated that the privacy policy URL and the privacy data types are both editable at any time. Only the data types are. Corrected. When a misread source has seeded a page, the first sweep does not always find every sentence it touched, grep for the consequence, not only for the wording.

Why it matters: this was not a wrong number, it was a wrong plan. It told the reader which levers are available when something urgent happens and which creative decisions can be left late, and it was wrong in the expensive direction, claiming flexibility that does not exist. Corrected in nine pages: 00-05, 10-01, 10-08, 10-09, 40-01, 40-02, 40-10, 70-07, 98-04.

The practical consequence for scheduling: on iOS the keyword refresh, the screenshot refresh, the icon and a category change are one release-bound batch. They should be decided together, against the build cut-off. On Play they remain four independent edits. That widens the gap described in 00-05 from a text-field difference to a whole-listing one.

How it got in, which is the part worth keeping

The source was read as text rather than as markup. In Apple’s property tables a set mark is <figure class="icon icon-checkcircle" alt="Required">, an element with no text content. Strip the tags, or paste the page into an editor, and every cell in every column reads blank. A reader then falls back on what the surrounding prose implies, and the prose says only that the tables “indicate the properties that can be localized and edited at any time”.

Compounding it, that page is incomplete: it has no row at all for the keyword field, description, promotional text, screenshots, previews or icon, and the string “Keyword” never appears on it. Those properties are described on Platform version information, which has no Editable column. Absence from the table was read as permission.

This is the fourth error in this base traceable to not reading a source in its own form, after the localization count, the age-rating tiers and the offer-code limit. The first three were summaries; this one was a text extraction that silently dropped the data. The working rule now has to cover both: read the source as rendered, and check that the thing you are reading actually contains a row for the property you are about to write about.

CONFLICT-021: Apple’s search popularity is documented as 1–5, not 5–100 · resolved

Believed: across practitioner material, including the Phiture Advanced ASO e-Book (2022): Apple’s search popularity score runs from 5 to 100, is exponential rather than linear, returns no real value below 6, and groups terms differing only by special characters.

Current documentation: Apple’s Apple Ads glossary defines search popularity as “a relative indicator of an Apple Ads keyword’s popularity”, based on App Store searches, and states it is “displayed as numbers from 1 to 5, with 5 being the most popular.” (Apple Ads glossary, verified 2026-09-19, read from raw page text)

Winner: Apple, for what Apple’s interface shows. Claim ADS-KW-005.

Confirmed a second time, from a second Apple source, 2026-09-20. Apple’s own Apple Ads certification course states the same thing twice: the keyword suggestion tool shows “the search term popularity index: which shows ratings from one to five, with five being the highest rating”, and its metrics glossary repeats “displayed as numbers from 1 to 5, with 5 being the most popular.” And vendors were found on the other side: ASOMobile’s course material states the range as “5 (unpopular) to 100 (very popular)” in two separate chapters, and RadASO’s blog uses the same scale in a June 2026 article on seasonal demand, “the scale ranges from 5 to 100”. So the split is two Apple sources against at least three vendors, which is as settled as this gets. The vendor scale is not going away, so the working rule is to state the scale every time you quote a popularity number.

This is a definitional conflict, not a factual one, and that is what makes it dangerous. Both numbers exist. The 5–100 figure is what third-party ASO tools display and what the practitioner literature quotes; Apple’s own documented indicator is 1–5. Neither party is lying and the two are not interchangeable.

Why it matters:

A popularity number is meaningless without its scale. “Popularity 4” is near the top on Apple’s scale and near the floor on a tool’s. Two people comparing notes from different sources will reach opposite conclusions about the same keyword and never find the disagreement, because both are quoting “search popularity”.

The familiar caveats attach to the tool scale, not to Apple’s. Exponentiality, a floor around 6, the grouping of disney with disney+, all of these are practitioner observations of the 5–100 values, and none is documented by Apple. They are [C]: worth knowing, not usable as facts, and not transferable to the 1–5 indicator.

Apple publishes no absolute volume at all. The indicator is explicitly relative. Neither scale converts to impressions, so neither belongs in a forecast. Recorded in 30-01; the third-party scores are handled separately in 30-02, which already treats a 5–100 range as a presentation choice rather than a measurement.

CONFLICT-022: Apple says drop the plural; practitioners say test it · open

What Apple documents: to maximise the words that fit in the 100-character keyword field, avoid “plurals of words that you’ve already included in singular form”, along with category names, the word “app”, duplicate words, and special characters, which Apple says carry no extra weight. (Creating your product page, verified 2026-09-20)

Apple is not describing a style preference. Telling you a plural is redundant is Apple stating that the store matches it. Claim IOS-KW-006.

What practitioners report: that singular and plural forms can rank differently and should be treated as separate keywords, particularly outside English. MobileAction publishes guidance under precisely that heading; the Phiture e-Book reports that Apple “does not always rank apps for the plural or compound versions of singular keywords”, calling the behaviour “far from fully baked… especially regarding non-English searches”, and recommends carrying both forms for a term that matters.

Neither side wins, and that is the finding. Apple’s statement is about the algorithm’s intent; the practitioner reports are about observed behaviour in specific locales. Both can be true at once, and the resolution is language-dependent rather than universal.

Why it matters: the field is 100 characters. Carrying run and running where Apple already matches them is waste; dropping the plural where it is not matched is lost ranking. Getting this wrong costs a measurable fraction of the scarcest asset on the page.

The working position, recorded in 10-03 and 30-04: follow Apple for simple English plurals, and verify per locale before extending that to any other language. Morphologically rich languages (Turkish, Finnish, the Slavic languages, Japanese) are where the assumption breaks, and English is no guide to any of them.

Not resolved, and not resolvable from documentation. It needs a test on a live app in the locale in question: put the singular in the field alone, and track the plural.

A specific heuristic from the e-Book was checked and not corroborated: that a results-count discrepancy under about 15% between two variants indicates Apple is matching them. No independent source states it. Recorded here so the next person does not spend time on it, and deliberately not written into the base.

CONFLICT-023: Apple’s own certification course is behind Apple’s own help pages · superseded

The source: the Apple Ads Certification curriculum, Apple’s free training course and the material most practitioners are pointed at first. It is first-party, it carries no visible date, and it is not the same thing as Apple’s help documentation.

Three places where it is stale, found on a full read 2026-09-20:

The course teaches	Apple’s help documentation says
A search results page carries one ad: “you can reach users… with a single ad promoting your app at the top of relevant App Store search results”	The glossary defines impression share (first ad position) separately from impression share (all ad positions) for the same search term, a distinction with no meaning if there is one slot. `ADS-PLACE-002`, 90-01
“You can create up to 35 custom product pages in App Store Connect”	70. CONFLICT-009, `IOS-CPP-001`, 60-01
Impression share “is displayed as a percentage range, such as 0‑10%, 11‑20%”	An exact percentage from 0 to 90%, and a 91–100% band above that. `ADS-PLACE-002`

The course also carries a statistic footnoted to the first quarter of 2022 (78% of App Store search volume from devices with Personalized Ads off. See CONFLICT-017), which dates the material’s last substantial revision as well as anything.

Winner: the help pages, in all three rows. They carry the current interface behaviour; the course carries the interface as it was when the lesson was written.

Why it matters, and it is not really about these three facts.

A first-party source is not automatically a current source. This base’s tier rule says A means Apple or Google documents it. That rule needs a second half: which Apple. Training material, marketing pages, WWDC sessions and help documentation are all Apple, they revise on completely different cycles, and the help pages revise fastest. When two Apple sources disagree, prefer the help documentation and record the date.

The certification is also the source of a lot of second-hand practice. Every guide that teaches the four-campaign structure teaches it from this course, which is fine. That part has not changed. The trouble is that the same guides repeat “35 custom product pages” and “one ad slot” with equal confidence and equal provenance, and neither is true now. A claim being traceable to Apple does not make it current.

It does not make the course useless. Read as a description of intent and mechanics it is still the clearest single explanation of the auction, match types, Search Match and the discovery loop that Apple publishes, and four documented facts here were taken from it and confirmed against the help pages. Read as a reference for numbers, it will put stale figures into a deck.

CONFLICT-024: This base’s own release-process page contradicted its own metadata page · resolved

Found 2026-09-21, while writing the plain-language version of 98-04. Not a disagreement with Apple’s documentation: a disagreement between two pages of this base with each other, which is a different and arguably worse failure, because nothing about it looks like a conflict from outside.

What 98-04 said, in its own “Not bound to a release” line: promotional text, screenshots, app previews, icon, categories, age rating, privacy details, support and marketing URLs, price and availability.

What the very paragraph above that line, on the same page, already said: “The same applies to the icon, screenshots, previews, categories and age rating”, meaning they are bound to a release, referring the reader to 10-09.

What 10-09 itself says, and has said since CONFLICT-020 was fixed on 2026-09-19: screenshots, app previews, the icon, both categories, age rating, the privacy policy URL, and the support and marketing URLs all require a new app version. Only promotional text, the privacy data types (not the URL), price and availability, in-app events, custom product pages, and in-app purchase names and descriptions move without one.

Why this happened: CONFLICT-020 corrected the fact on 10-09 and on the pages that cite it directly, but 98-04 carried an independent copy of the same list written before the fix, and that copy was never revisited. A correction made in one place does not propagate to a duplicate written from the same wrong source.

Why it matters more than a normal correction: this is exactly the failure mode the project’s own working rules exist to catch: a fact repeated on a second page, and a second page is a second copy that drifts the first time the truth changes, per the standing rule “do not pad; cross-reference, never restate.” 98-04 restated a table 10-09 already owns, and the restatement is what went stale.

Fixed: 98-04’s line now matches 10-09, names the correct short list of what is genuinely free of a release, and both the English page and its Croatian translation carry a note pointing at this entry. last_verified on 98-04 updated to 2026-09-21.

The general lesson, worth keeping: when a page needs to state a fact that another page already owns in detail, link to it rather than re-deriving or re-typing the list. A cross-reference cannot go stale independently; a duplicate always can.

CONFLICT-025: This base said most users only ever see the preview poster frame · resolved

Believed: by this knowledge base until 2026-10-06, in 40-04, its Croatian translation, both plain-language versions and the vocabulary entry for “poster frame”: the poster frame is “what the majority of users actually see, because they never press play”, the “most-seen frame”.

Current documentation: “App previews display and autoplay on your product page and within search results”, they play “with the sound muted” by default, and “if someone has turned off video autoplay in their App Store settings, a poster frame will display.” (App previews, verified 2026-10-06)

Winner: Apple. The poster frame matters to the people who turned autoplay off and before playback starts; it is not the frame most visitors see. New claim IOS-CRE-005.

How it got in: an assumption about user behaviour (nobody presses play) was written as a fact without a source, on a page whose sources covered only the preview specifications, which say nothing about playback. Found while checking a third-party ASO guide against this base: the guide stated autoplay correctly, and this base did not.

Why it matters: the advice changed direction. The cheap fix used to be “set the poster frame”; the bigger lever is the first silent seconds of the video itself, because that is what plays in search results next to competitors.

CONFLICT-026: This base said a 6.5-inch iPhone screenshot set is required · resolved

Believed: by this knowledge base until 2026-10-06, in 40-02, its Croatian translation, both plain-language versions and claim IOS-CRE-002: a 6.5-inch iPhone set is the required one, with 6.9″ falling back to 6.5″ and smaller sizes scaling from it.

Current documentation: the screenshot specifications page, read as raw HTML on 2026-10-06, requires “at least one screenshot for iPhone with Dynamic Island (medium display)”, 1179 x 2556 or 1206 x 2622 px. The fallback chain names a source for every size, and iPhone Duo sizes were added. (Screenshot specifications)

Winner: Apple. IOS-CRE-002 rewritten; IOS-WWDC-004 and IOS-WWDC-005 added.

How it got in: the required-size list changes with hardware, and the claim row itself warned about that (“changes roughly annually”). It was correct on 2026-09-18 and was overtaken by Apple’s update, not misread. The same page now both names the medium size as required and says supplying only the highest resolution is enough; the base reports both.

Why it matters: an iPhone 18 era upload workflow built around 6.5″ would target a size Apple no longer lists as the required one. And from April 2027 a missing Duo set blocks submission, per Apple’s release notes.

CONFLICT-027: This base said screenshots always need a new app version · resolved

Believed: by this knowledge base from 2026-09-19 to 2026-10-06, in 40-02, 10-09, 98-04, 70-07, 40-10, 00-05 and claim IOS-VER-006: screenshots and app previews require a new app version.

Current documentation: that was correct for the version page and is still true there. But since 2026-10-05 the Asset Library lets you submit assets on their own once the app has an approved version: “you can submit standalone assets directly from the Asset Library without creating a new app version”. A screenshot set for one language can be sent to review that way. (Submit assets from Asset Library) Confirmed first-hand by an in-house practitioner on 2026-10-06.

Winner: Apple, with one gap kept open: its pages do not describe how an approved standalone set then replaces the one shown on the live page.

How it got in: two things at once. The rule was right when it was written (CONFLICT-020 corrected the opposite error), and Apple then changed the product. A second slip followed on the same day this was found: an earlier version of this page said standalone screenshots cannot go live without a release, taken from a single first test, and had to be reversed within hours when the practitioner corrected it.

Why it matters: the planning rule “a screenshot refresh costs a release cycle” is no longer true by default. Seasonal sets, a single-language fix and a competitor response can move on review time alone.

CONFLICT-028: Do creative assets already run in Apple Ads? · open

Claimed: Apple’s WWDC26 session and the App Store What’s New page say the new creative assets can be used in Apple Ads on the Today tab and in search results, and some vendor write-ups of October 2026 read that as “available now”. One vendor timeline also puts header and search assets live on 2026-09-09.

Current documentation: Apple Ads Help, read 2026-10-11: creative assets are coming soon to Apple Ads; you can upload them in App Store Connect now, and they “will be available to use in Today tab and search results ads at a later date”, with no date. Apple’s own ads news of 2026-06-08 says “later this year”. For the organic placements, Apple’s App Store Connect release notes and developer news date the launch 2026-10-05.

Winner: Apple Ads Help for the ads question, the release notes for the organic date. The 2026-09-09 date is a single third-party timeline and is not used.

Why it matters: a campaign plan that assumes custom ad creative is open in Apple Ads would be built on a feature that cannot be selected yet. Re-check the Apple Ads help page and the account interface before each use.