App Store Audit

The App Store checks a listing once, when it is submitted. After that the developer link, the storefronts it sells in and the year it was last touched are simply displayed, whatever happened to them since.

This Actor rechecks them.

• Developer links that lead nowhere. The URL shown on the listing, followed the way a browser would, reported as reachable, refused, broken or gone.
• Domains behind those links that lapsed or changed hands. A link that 404s is a nuisance. A link whose domain is free to register is an address anyone can move into while Apple keeps showing it under the developer's name.
• Apps absent from every EU storefront while still selling elsewhere. One lookup per storefront turns a distribution question into a fact.
• Listings nobody has updated in years, with the base rate attached so the number means something.

Everything comes from Apple's own public lookup and chart feeds, the links themselves, and the domain registries. No key, no login, no scraping of the store pages.

What comes out

One row per app: the store metadata, what each check found, a list of issues with severities, and an overall riskLevel of critical / high / medium / low / ok.

Four records in the key-value store:

Record	Contents
SUMMARY	Counts by severity, how many apps carried each finding, the base rates, and every caveat that applies to this run
ACTION_LIST	The findings ranked by severity, then by how many people rated the app
LINK_REPORT	Links that do not work, and the registration concerns behind them
AVAILABILITY_MATRIX	One row per app, one column per storefront

Input

Give it apps in whatever form you have them - numeric ids, store URLs, bundle ids - or a developer id to audit a whole catalogue, or a chart name such as top-free to survey what is currently selling.

{
  "apps": [
    "https://apps.apple.com/us/app/example/id384357434",
    "971560709",
    "com.example.app"
  ],
  "checkAvailabilityIn": ["us", "gb", "de", "fr", "es", "it", "jp"],
  "staleAfterDays": 1095
}

Availability needs at least two EU storefronts in the list for the EU finding to mean anything - a single failed request would otherwise look like a withdrawal.

What it will not do

It does not read App Privacy details. Those come from amp-api.apps.apple.com/v1/…, and apps.apple.com/robots.txt disallows /v1/*. Other tools take them anyway. This one does not.

It surveys by chart, not by keyword search. itunes.apple.com/robots.txt names /search*, so where a choice existed this Actor took the path nobody had asked it to stay off: Apple's public chart feeds on rss.applemarketingtools.com, whose robots.txt sets no rules at all. A chart is also the better sample for an audit — it is what people are actually installing this week, not what happens to match a word.

It does not pretend to be a browser. Some developer sites - whatsapp.com among them - answer an automated request with 403. That is a live server declining to talk to a program, and it is reported as exactly that: developer_link_blocked, severity low, "the server is up and refused an automated request; it says nothing about whether a person clicking the listing reaches a page." Retrying behind a browser user agent would produce a cleaner-looking report by working around an answer we were given.

It does not tell you why. Apple returns the same empty answer for an app that was removed and one that never existed. A bloc-wide EU absence is consistent with the DSA trader requirement, with a licensing decision, and with a developer who simply switched EU distribution off. The finding says what the store showed; the reason is yours to establish.

Severities, and why they sit where they do

Measured on 1,312 live App Store apps in July 2026:

• 18.4% had shipped no update in three years — and were still on sale. So no_update_in_years is medium, never an alarm.
• 30% carried no developer link at all. So a missing link is not a finding. Only a link that is there and broken is.
• 16% were registered as http://. Most redirect to HTTPS, which costs the reader nothing, so only a link that stays on http:// is reported, at low.

A warning that fires on healthy input erases the ok rows, which is the only thing that makes the other rows worth reading.

Finding	Severity
app_not_found — not on sale in the main storefront	critical
developer_domain_unregistered — the address on the listing is free to register	critical
developer_link_dead — hostname gone, or 404/410	high
developer_domain_reregistered — registered after the app's last update	high
unavailable_across_eu — absent from every EU storefront checked, still selling outside	high
developer_link_server_error, developer_link_error, developer_link_offsite, developer_domain_expiring, no_update_in_years	medium
developer_link_blocked, developer_link_insecure, unavailable_in_some_countries, link_check_failed, domain_check_failed	low

A domain whose registration could not be read is unknown, never ok. Telling somebody their vendor's domain is safely registered when we merely failed to ask is the mistake that costs them something.

Cost and courtesy

One iTunes request covers 100 apps, one per storefront for availability, one probe per distinct developer URL (a developer with forty apps has one site, not forty), and a registry lookup only where it changes a verdict — behind a link that failed, or an app already past the staleness threshold. RDAP lookups run two at a time because registries operate those servers as a public service.

Verification

39 unit tests and 27 live checks against the real API, the real sites and the real registries. Every true positive in the live file has a negative control beside it, so a rule that fires on everything cannot pass.