🍎 Apple App Store Developer Leads Scraper — emails, phones & portfolios

One row per App Store DEVELOPER, never per app. Point it at a keyword, a category chart, a list of developer IDs or a list of app IDs, and get back the publisher behind the apps: their legal entity, registered address, phone number, email, D-U-N-S number, website, support URL — plus how big their catalogue is, how much traction it has and how long they have been shipping.

The contact block is not scraped off somebody's homepage. It is Apple's own EU Digital Services Act Article 30 trader register, which every trader distributing on an EU storefront is legally required to declare and keep accurate.

Revolut Ltd        support@revolut.com   +44 2033228352   30 South Colonnade, London E14 5HX   DUNS 219783625
myCraftnote GmbH   info@mycraftnote.de   +49 1742058062   Heinrich-Heine-Platz 10, 10179 Berlin  DUNS 315098030
OnePageCRM         support@onepagecrm.com +1 6467621303   (Novus Via Ltd)                        DUNS 896941593

⚠️ Read this before your first run

The trader contact block exists only on EU storefronts. Measured on one app id across four storefronts on 2026-09-07: populated on ie and de, null on us and gb — the UK is not in the EU. On a 25-developer us batch, trader_* filled 0 of 25. That is why the storefront defaults to ie (the English-language EU storefront). If you need US developers, set country: "us" and put ["ie"] in Fallback storefronts — measured below, that takes the trader block from 0% to 68%.

---

📊 What you get on every row

Group	Fields
🏢 Identity	developer_id · developer_name · developer_url · seller_name · copyright
📇 EU trader register	is_trader · trader_name (legal entity) · trader_email · trader_phone · trader_address · trader_address_lines · trader_address_country · trader_duns
✉️ Best contact	email · email_source · email_domain · email_is_role_address · email_is_freemail · description_emails · contact_channels · contact_source · contact_storefront
🌐 Web	developer_website · support_url · privacy_policy_url
📈 Portfolio economics	portfolio_app_count · portfolio_paid_app_count · portfolio_free_app_count · portfolio_total_ratings · portfolio_avg_rating (ratings-weighted) · portfolio_categories · first_release_date · newest_release_date · last_update_date · tenure_years · optional portfolio_apps[]
📱 The lead app	lead_app_id · lead_app_name · lead_app_subtitle · lead_app_url · lead_app_bundle_id · lead_app_category · lead_app_price · lead_app_is_free · lead_app_rating · lead_app_rating_count · lead_app_version · lead_app_release_date · lead_app_last_updated · lead_app_has_in_app_purchases · lead_app_min_os · lead_app_languages · lead_app_icon_url · optional lead_app_description
🏆 Chart position	lead_app_chart · lead_app_chart_genre · lead_app_chart_position · lead_app_chart_source
✅ Integrity	portfolio_complete + portfolio_incomplete_reason · contact_complete + contact_incomplete_reason · contact_enriched · contact_used_alternate_app · contact_used_fallback_storefront
🧾 Provenance	discovered_via · storefront · storefront_is_eu · scraped_at

---

📏 MEASURED field fill — real runs, not estimates

Every number below comes from a real run through the Apify datacenter proxy. Nothing here is rounded up, and nothing is projected.

These are one sample, not a guarantee. Which 100 of the ~561 developers a keyword search finds get delivered depends on the order Apple answers in, so an identical input run again moves the softer fields by a few points. Table A was measured three times on the same input (crm+invoice+dental+plumbing, ie, 100 developers) on 2026-09-07 and 2026-09-08; where the three runs disagreed, the range is printed and the lowest number is the one to plan with.

A. 100 developers, ie storefront, keyword search (crm, invoice, dental, plumbing)

Field	Filled	%
developer_id / developer_name / developer_url	100/100	100%
support_url	100/100	100%
copyright · trader_name	100/100	100%
privacy_policy_url	99/100	99%
portfolio_app_count · first_release_date · lead_app_*	100/100	100%
developer_website	66–68/100	66–68%
email (any source)	57–59/100	57–59%
is_trader = true	53–54/100	53–54%
trader_email · trader_phone · trader_address	53–54/100	53–54%
trader_duns	33–39/100	33–39% (the widest-swinging field of the set)
portfolio_avg_rating	36–50/100	36–50% (null when the whole portfolio has zero ratings)
description_emails (≥1)	5–7/100	5–7%
portfolio_complete = true	98/100	98% (2 developers filled Apple's 200-app ceiling)
contact_complete = true	100/100	100%

contact_source across those 100 rows: 53–54 apple-dsa-trader, 42–43 app-metadata, 3–5 app-description. Portfolio size: min 1, median 2–3, mean 10–25, max 106–201.

B. 50 developers, ie storefront, top-grossing charts (Business + Finance + Productivity)

The money charts are a much richer lead source, because a publisher earning revenue in the EU almost always has to declare as a trader:

Field	Filled	%
support_url · privacy_policy_url	50/50	100%
email (any source)	44/50	88%
trader_email · trader_phone · trader_address	43/50	86%
trader_duns	37/50	74%
developer_website	40/50	80%

If contact fill is what you care about, run the charts, not a keyword search.

C. Non-EU storefront, with and without the EU fallback (25 developers, us, crm + invoice)

	trader_*	any email	developer_website
country: "us" alone	0%	24%	76%
country: "us" + contactFallbackCountries: ["ie"]	68%	80%	80%

17 of the 25 trader blocks were recovered from the Irish storefront. Cost: one extra request per developer that needed it, and no extra charge. This is the most-repeated measurement in this README: three separate runs on three separate days each landed on 0/25 without the fallback and 17/25 with it.

EU → EU fallback adds nothing. ie primary with de fallback measured 60% → 60% over 25 developers. A developer's DSA declaration is consistent across EU storefronts, so only use the fallback when your primary storefront is outside the EU.

D. Trying a second app for the trader block: measured zero

Over 100 developers on ie, contactRetryApps: 2 spent 29 extra requests and recovered 0 extra trader blocks. That is why the default is 1. The knob is still there — the measurement is one storefront on one day, not a law.

---

⚡ MEASURED speed and reliability

All through the Apify datacenter proxy (BUYPROXIES94952), concurrency 4, one pinned proxy session per worker, on 2026-09-07:

Run	Developers	HTTP requests	Retries	HTTP 429	Unrecoverable	Wall clock
Keyword search, ie (the demo input)	10	25	2	1	0	15 s
Keyword search crm, ie	25	70	12	12	0	44 s
Top-grossing charts × 3, ie	50	117	8	6	0	83 s
Keyword search × 4, ie	100	266	33	32	0	131 s

The only wall Apple puts up is HTTP 429, and it is per exit IP. There is no Cloudflare, no CAPTCHA, no challenge page, no login and no token anywhere in this actor. Every 429 above was recovered by retrying on a fresh proxy session. Running with no proxy from a single IP measured 15 of 20 successes.

Cost per developer: 2 HTTP requests (portfolio + contact), plus one shared discovery request per keyword or chart.

---

🔎 Four ways to find developers — one row shape

Mode	What it does	MEASURED supply
Keyword search	Runs App Store searches and collapses every result to its publisher	crm/ie → 179 apps → 162 developers; invoice/ie → 186 → 169; dental/ie → 171 → 154; plumbing/ie → 113 → 88. Apple caps one search near 200 apps; the number of keywords is not capped
Category charts	Walks the top-free / top-paid / top-grossing chart of any of Apple's 26 categories	100 entries per chart (Apple returns 100 even when more is asked for) → 89–100 distinct developers per chart. 26 categories × 3 charts ≈ 6,600 developers per storefront
Developer IDs	You already know the publisher	Their whole storefront catalogue, up to Apple's 200-app ceiling
App IDs	You know the app, you want the company behind it	Looked up 50 ids per request

Start URLs work in every mode. Paste apps.apple.com/de/app/…/id123 or apps.apple.com/ie/developer/…/id456 and the storefront in the URL is honoured, so a German app page is never looked up on the Irish storefront and reported as missing.

---

💰 Pricing — pay per event, nothing else

Event	Price	When it fires
Per developer lead returned (developer-scraped)	$0.003	Once per DEVELOPER row actually written to your dataset
Per developer contact enriched (contact-enriched)	$0.002	Once per delivered developer whose contact call returned at least one contact channel

A fully enriched lead ceilings at $0.005 — $5.00 per 1,000 verified developer leads. There is no actor-start charge and no per-dataset-item charge; both Apify auto-events are removed.

What you are never charged for:

• a developer removed by one of your filters (the filters run on the finished row — you keep the enrichment cost off your bill, not just the row)
• a developer skipped because dedupeAcrossRuns already delivered them
• a developer on your excludeDeveloperIds suppression list (they never cost a request either)
• a contact call that failed or came back empty
• anything at all when fetchContacts is off
• rows a charging cap truncated away — they are not delivered and not billed; the run says so in plain words and names the cap as the cause, both in the log and in the run's own status message (e.g. "6 developer row(s) delivered | charged 6 developer-scraped + 6 contact-enriched | STOPPED BY YOUR CHARGING LIMIT"), so you never have to open the log to find out why a run is short

One developer is one row and one charge however many of their apps surfaced them. In the 100-developer run above, 645 app rows collapsed to 561 developers before a single charge.

---

🧾 Honest limits

1. The trader block is EU-only. Not a bug, not a fixable gap — Apple only publishes it where the DSA applies. gb is not in the EU. Non-EU storefronts still give you the developer, the portfolio economics, support_url, privacy_policy_url and developer_website.
2. Fill is 54% (search) to 86% (top-grossing charts), not 100%. The developers who come back without a contact block declared isTrader: false — governments, public bodies, some non-EU corporates and hobbyists. They still get a row, with is_trader: false and the reason visible. Turn on Only developers with a trader contact if you want the others gone (and unbilled).
3. Apple caps the portfolio lookup at 200 apps per developer. A developer who fills that ceiling gets portfolio_complete: false and a portfolio_incomplete_reason saying the totals cover 200 apps, not necessarily the whole catalogue. Measured: 2 of 100.
4. Apple caps a chart at 100 entries even when more is requested. This actor never claims 200.
5. portfolio_avg_rating is null when the whole portfolio has zero ratings (50 of 100 rows in run A). A null is a null — it is never reported as 0.0.
6. Rate limiting is real. At concurrency 4, 32 of 266 requests came back 429 on the largest run. All were recovered. Push concurrency past ~4 and the run gets slower, not faster.
7. A row is a company, not a person. developer_name is Apple's display name; trader_name is the legal entity, and they often differ (OnePageCRM → Novus Via Ltd).
8. A short run timeout can cut discovery short, and the run says so out loud. If the run's own clock runs out before every keyword / chart / storefront has been read, the log prints INCOMPLETE DISCOVERY, names the searches that were never read, sets discoveryComplete: false in RUN_STATS, and the run's status message carries it too. It is never reported as if Apple had nothing — and a request our own clock cut short is never blamed on Apple or on the proxy.
9. email_is_role_address is a heuristic, not a verified fact. It matches known role words in the local part (support@, info@, hallo@, and glued forms like appservices@ or dsalesmobilesupport@). It cannot tell you that eb@handwerkerpro.com is a person and crm@zohomobile.com is a mailbox. Treat it as a sorting aid, and use email + email_domain when you need certainty.

---

🔐 Personal data — what this actor gives you control over

Apple's trader register is business contact data published under EU law. But a real share of it is a named individual's work mailbox and mobile number, and a sole-trader developer's declared address can be their home. Measured over a 100-row run on 2026-09-08: of the 57 rows carrying an email, 28 were role addresses (support@, info@, hallo@, appservices@) and 29 looked like a named person (matt.ackerman@csdental.com, tom.linehan@seapointclinic.ie). It is close to a 50/50 split, and the classifier is a word-match heuristic — see limit 9 above.

The actor ships that as-published, and gives you three switches plus two flags:

• Drop named-individual email addresses (excludePersonalNameEmails) — keeps only role mailboxes and reports how many were removed per row in personal_emails_redacted
• Include the trader phone number (includeTraderPhone) — off blanks it everywhere
• Include the trader postal address (includeTraderAddress) — off blanks it everywhere
• email_is_role_address and email_is_freemail on every row, if you would rather filter downstream than at scrape time

---

🎛️ Filters that pay for themselves

Every filter runs on the finished row, and a developer it removes is never delivered and never charged:

requireTraderContact · requireEmail · requireWebsite · excludeFreemailLeads · minPortfolioApps / maxPortfolioApps · minPortfolioRatings · minAverageRating · onlyPaidDevelopers · categoryIds (applied before enrichment, so it costs nothing) · newestReleaseAfter · firstReleaseAfter / firstReleaseBefore · excludeDeveloperIds

categoryIds bites in both places: before enrichment when discovery already surfaced an app (free), and again on the finished row against portfolio_category_ids — so it still filters when you supplied bare developer IDs or /developer/ start URLs and there was no discovered app to match against. Either way a developer it removes is never delivered and never charged.

Example, measured: requireTraderContact + minPortfolioApps: 2 + minPortfolioRatings: 5 + excludeFreemailLeads on crm/ie delivered 8 clean rows and removed 20 candidates after enrichment — all 20 unbilled.

---

🧑‍💼 Who buys this

• Agencies and dev shops selling to app publishers — a verified legal entity, a phone number and a portfolio size on one row is a qualified outbound list, not a scrape
• SDK / API / analytics / monetisation vendors — filter to onlyPaidDevelopers + minPortfolioRatings and you have publishers with a working paid product
• M&A and app-portfolio buyers — portfolio_app_count, portfolio_total_ratings, tenure_years and newest_release_date are the first four columns of a target list
• Compliance and brand-protection teams — the DSA trader block is exactly the record you need to identify who is actually behind an app
• Market researchers — chart mode gives you the top 100 of any category with the publisher, their rank and their whole catalogue attached

---

❓ FAQ

Does this return one row per app or per developer? Per developer, always. Apps are collapsed on Apple's artistId before anything is charged — 645 app rows became 561 developers in the measured run. The app the lead came through is kept on the row as lead_app_*.

Where does the email actually come from? email_source tells you per row. apple-dsa-trader means Apple's EU trader register — the developer legally attested to it. app-description means it was in the App Store description text. If neither exists, email is null; the actor never guesses an address.

Why is country set to Ireland by default? Because it is the English-language EU storefront, and only EU storefronts carry the trader contact block. Ireland gives you the register and readable English metadata.

Can I get US developers with contact details? Yes — set country: "us" and contactFallbackCountries: ["ie"]. Measured: 0% → 68% trader fill. Most sizeable US publishers also distribute in the EU and therefore declare there.

Do I need a proxy? The Apify datacenter proxy is on by default and is enough — 100% success across every measured run. Without a proxy, a single IP measured 15/20. Residential works but costs more for no gain.

Does it need a login, an API key or a browser? No, none of the three. Four plain HTTP GETs that return JSON. That is also why it runs at 256 MB.

How many developers can I actually get? Charts alone are roughly 26 categories × 3 charts × ~90 developers ≈ 6,600 per storefront, and there are 27 EU storefronts. Keyword search adds ~90–170 developers per keyword with keywords uncapped.

What happens if I hit my charging limit mid-run? The run stops, delivers only what it could pay for, and says "the charging limit you set (maxTotalChargeUsd, or your free-tier balance) left no room" — naming the cap as the cause. You are never left holding rows you were not billed for, or billed for rows you did not get.

What does a zero-row run mean? It names the real reason: your filters removed everything, dedupeAcrossRuns had already delivered them, the charging cap, this run's own time budget, or Apple genuinely returning nothing for what you asked. It never blames Apple for something the actor did.

Can I run it on a schedule and only get new developers? Yes. Turn on Skip developers delivered by earlier runs. Developer ids are remembered in a named key-value store that survives between runs, so a scheduled run becomes a new-publishers feed and you never pay twice for the same lead.

How fresh is the data? Live. Every field is read from Apple at run time; nothing is cached between runs except the dedupe list of ids you have already been sent.

Can I export to CSV? Yes — the row is deliberately flat by default. portfolio_apps and lead_app_description are the only heavy fields and both are opt-in.

---

🗂️ Output views

The dataset ships with three ready-made table views: Developer leads (the contact columns), Portfolio economics (catalogue size, traction, tenure) and Lead app (the app and its chart rank). A RUN_STATS record is written to the run's key-value store with request counts, retries, 429s, per-field fill over the delivered rows, what each filter removed, and why the run stopped.

---

⚖️ Legal & fair use

This actor reads publicly available App Store data — the same pages and endpoints Apple's own web store front-end uses, with no login, no token, no credential and no access control bypassed. The trader contact block is information Apple is required to publish under Regulation (EU) 2022/2065 (Digital Services Act), Article 30, precisely so that traders can be identified.

robots.txt disclosure. The endpoints this actor reads are Disallowed in Apple's robots.txt. Quoted verbatim, read 2026-09-07:

# https://apps.apple.com/robots.txt
Disallow: /api/*
Disallow: */search?*

# https://itunes.apple.com/robots.txt
Disallow: /search*
Disallow: /*/rss/*
Disallow: /*/lookup?

robots.txt is a crawler-courtesy convention, not an access control and not a contract. We state it plainly rather than hiding it; the data itself is public, unauthenticated and, in the case of the trader register, published by legal mandate.

Your obligations, not ours. The trader block can contain a named individual's work email, mobile number and — for sole traders — a home address. If you are in the EU/EEA or contacting people there, GDPR applies to what you do with it: have a lawful basis (usually legitimate interest for B2B outbound), honour objections and opt-outs, and identify yourself. Marketing rules (ePrivacy/PECR and the equivalents) apply to how you use the emails and phone numbers. The excludePersonalNameEmails, includeTraderPhone and includeTraderAddress switches exist so you can narrow the data before it reaches your systems. Not legal advice — talk to your own counsel.

Apple, App Store, iTunes and the Apple logo are trademarks of Apple Inc. This actor is not affiliated with, endorsed by, or sponsored by Apple Inc.