You search a term your portfolio should own and two of your own apps come back. The word for this, borrowed from web SEO, is cannibalization, and the borrowed word arrives with a borrowed verdict: fix it.
Sometimes. Often it is the best result available to you, and the reason the analogy misleads is worth unpacking before anyone goes and merges two listings.
Start with the case where it is good
Two slots in a ten-app result is two chances to be the right answer, and on the App Store the two listings can be genuinely different products. A search for "budget" that returns your simple envelope app at #2 and your full accounting app at #6 has put two different propositions in front of someone who has not yet told you which one they want. A single listing cannot do that.
This is the ordinary case for a portfolio developer, and any tool that opens by calling it a problem has assumed away the reason you shipped two apps.
The situation worth attention is narrower: two listings that are substitutes, competing for the same person, splitting the same demand, with the same value proposition described in slightly different words. That is where one listing is genuinely taking something from the other.
Nothing observable from outside distinguishes those two cases. Which is the honest headline of this post.
Why the SEO analogy breaks
Web cannibalization has an infrastructure behind it that simply does not exist here:
| Web SEO | App Store |
|---|---|
| Canonical tags to consolidate duplicates | No equivalent |
| Search Console query reports, per URL | No per-keyword impression data at all |
| Published keyword volume from many vendors | No public search volume from anyone |
| A page can be merged or redirected | Two apps cannot be merged; one can only be removed |
The remedies are what makes the diagnosis actionable on the web. Take them away and "you have cannibalization" becomes an observation with no attached move.
Apple's own App Store search guidance describes what results are based on — "text relevance (matches for your app's title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more)" — and says nothing about limiting how many apps from one developer can appear. So the appearance of two of your apps is not a documented anomaly. It is what the matcher did.
What is actually observable
Quite a lot, as long as you stop at description.
For a given developer, Apple's public API returns the whole portfolio, and a search for a term returns the ranked result. Join them and you get the layout: which of your apps appear, at which positions, how many rival apps sit between them, whether any of them are in the top slots, and whether the two share a primary genre.
Verified against live data while building this:
- A portfolio lookup for Meta returned
resultCount14 — the artist record at index 0 plus 13 apps. - A search for messenger surfaced four Meta apps at positions #1, #2, #10 and #17.
- A full scan across the portfolio's own terms found meta returning ten of its own apps in a single result.
Ten of one result. Whether that is dominance or dilution is not a question the ranking can answer — but knowing it is happening is the prerequisite for asking.
That is what the cannibalization scan reports: positions, apps between, top-slot occupancy, shared genre. No score, no verdict. A scan takes roughly eight seconds at four concurrent requests, and terms that fail are reported separately rather than counted as clean, because a term that did not resolve is not evidence of anything.
Where the candidate terms come from
A detail that matters if you build this yourself. The obvious move is to reuse whatever term extractor you already have for descriptions. It gives the wrong answers here, for three specific reasons:
- Bigrams must not span title boundaries. Concatenate a portfolio's app names and a naive bigram pass produces "clans clash" — two adjacent words from two different products, which is not a term anyone types.
- A term appearing in exactly one title is still a candidate. A description extractor that filters terms occurring once would drop "messenger" from Meta's portfolio, which is the single most interesting term to scan.
- Truncation. An extractor that slices the first 1,200 characters is fine for one description and loses most of a large portfolio.
Same-looking function, different job. Reusing it produces a scan that quietly misses its best findings.
What only you can settle
Here is the part no public dataset reaches.
Whether two listings split one demand is a question about the people who searched: did the person who installed app B want app A, and would they have installed it if B had not been there? That answer lives in your App Store Connect data — impressions, product page views and conversion per app — and nowhere else.
If the scan shows two apps on one term and you want to know whether it costs you anything, the sequence is: look at the impressions each listing gets for that class of query in App Store Connect, look at the conversion rate of each, and look at whether the lower-placed one converts at all. Public data got you to the question. Your own data answers it.
An empty result from a scan is not proof that no overlap exists, either. It is bounded by the terms scanned, and a term nobody thought to scan is not a term nobody searches.
If it is real, the moves are limited
Assume you have established, from your own analytics, that two listings genuinely substitute for one another. The options are unglamorous:
- Differentiate the metadata. Different names, different subtitles, different keyword fields, describing different jobs. Apple's own guidance is to avoid repeating words across your name, subtitle and category; extending that discipline across two of your own apps is the same idea applied one level up.
- Concede a term. Deliberately stop targeting it with the weaker listing and spend those bytes on something it can own. A keyword gap check is the natural next step.
- Accept it. Two slots on a term you would otherwise hold once is often the better outcome, and "no change" is a legitimate conclusion from a scan.
Merging is not on the list, because it is not a thing the App Store does.
What this cannot tell you
- Not search volume. No public source has it, so no ranking here implies traffic.
- Not whether one listing costs the other anything. Only your own App Store Connect data can show that.
- Not that the absence of findings means the absence of overlap. A scan covers the terms it scanned.
- Not a verdict. Positions and layout are observations. Whether two of your apps in one result is an advantage or a leak depends on what those two apps are, which is your judgement to make.
The work
Run the scan over your portfolio and look at the terms where two or more of your apps land in one result. For each, ask whether those two apps are answers to the same question. If they are, take it to your own analytics. If they are not, you have just found two slots you already own.