Apple App Store Version History Scraper

Export complete Apple App Store release histories as clean, structured data.

Give the Actor an iPhone, iPad, Apple TV, Apple Watch, or macOS app URL—or just its numeric app ID—and receive one dataset row per historical version.

Each row includes the app name, storefront, version number, ISO release date, full release notes, canonical app link, source link, and scrape timestamp.

Use it to monitor competitor shipping cadence, build ASO research datasets, audit release communication, or power product-intelligence workflows without manually opening every Version History dialog.

What does Apple App Store Version History Scraper do?

Apple App Store Version History Scraper reads the public, server-rendered Version History section of Apple App Store app pages.

It turns a page designed for browsing into records designed for analysis.

For every requested app, the Actor:

• 📱 resolves a numeric app ID or validates an App Store URL;
• 🌍 preserves the selected country storefront;
• 🗓️ extracts locale-independent ISO release dates;
• 📝 captures full release notes and version numbers;
• 🔗 retains canonical and fetched source URLs;
• 🧹 removes duplicate release records;
• 📦 exports results to JSON, CSV, Excel, XML, RSS, or API clients.

The output is newest-first, matching Apple’s public version history.

Who is this Apple App Store scraper for?

ASO and mobile growth teams

Track how often competing apps ship, compare update messaging, and identify seasonal release patterns.

Product and competitive-intelligence analysts

Build timelines of product activity and detect changes in release cadence across a watchlist.

QA and release engineering teams

Compare public release notes with internal release records and verify when a version appeared in a storefront.

Investors and market researchers

Use shipping frequency and changelog detail as repeatable signals when monitoring mobile-product execution.

Data engineers

Refresh a stable row-per-version dataset in a scheduled Actor task and load it into a warehouse or dashboard.

Why use this version history extractor?

Apple’s App Store interface is useful for reading one app at a time, but awkward for recurring analysis.

This Actor is designed for repeatable data work:

• ✅ no Apple account, login, cookies, or API key required;
• ✅ accepts both app URLs and compact numeric IDs;
• ✅ handles several apps in one run;
• ✅ stores dates in YYYY-MM-DD format regardless of displayed locale;
• ✅ emits simple primitive fields instead of a deeply nested app object;
• ✅ keeps storefront in the deduplication key;
• ✅ uses lightweight HTTP extraction rather than an expensive browser;
• ✅ fails clearly if none of the requested apps can be extracted.

What Apple App Store data can I extract?

Field	Type	Description
appId	string	Numeric Apple App Store application ID
appName	string	Public app name from Apple structured data
storefront	string	Two-letter country storefront code
version	string	Version label published by the developer
releaseDate	string	ISO date from Apple’s page markup
releaseNotes	string	Full public notes for this version
appUrl	URL	Canonical Apple App Store app page
sourceUrl	URL	Final URL fetched for this storefront
scrapedAt	string	UTC timestamp for dataset freshness

Every dataset item is one historical release.

There is no mixed app-summary or error entity in the default dataset, so downstream tables remain easy to query.

How much does it cost to scrape Apple App Store version history?

The Actor uses pay-per-event pricing.

A $0.005 start charge covers run initialization, followed by a charge for each historical release saved.

Apify plan tier	Price per historical release
Free	$0.000047126
Bronze	$0.000040979
Silver	$0.000031964
Gold	$0.000024588
Platinum	$0.000016392
Diamond	$0.000011474

Committed Apify plans receive the automatic per-result discounts above. Active prices and the maximum run charge are displayed before you start.

Example at the BRONZE rate, including the start charge:

• 25 saved versions: about $0.0060 total;
• 100 saved versions: about $0.0091 total;
• 500 saved versions: about $0.0255 total.

At the Free tier rate, $5 of platform credit covers roughly 105,000 historical releases after one start charge, assuming no other account usage.

You pay for records saved, not for pages that fail to produce data.

How to scrape App Store release notes

1. Open the Actor input page.
2. Add one or more Apple App Store URLs or numeric app IDs to App URLs or IDs.
3. Choose a two-letter storefront such as us, gb, de, or jp for raw IDs.
4. Set Maximum versions per app if you only need recent releases.
5. Leave concurrency at the conservative default unless processing a large watchlist.
6. Click Start.
7. Open the dataset and export it in your preferred format.

For a quick smoke test, use app ID 324684580 with storefront us and a limit of 25 versions.

Input parameters

apps

Required array of Apple App Store URLs or numeric app IDs.

Valid examples:

324684580
id324684580
https://apps.apple.com/us/app/spotify-music-and-podcasts/id324684580

Only https://apps.apple.com URLs are accepted.

Unsupported hosts and URLs without an app ID fail closed instead of being fetched.

storefront

Two-letter storefront used when an entry is a raw numeric ID.

Default: us.

If an input URL already contains a storefront, that URL storefront takes precedence.

maxVersionsPerApp

Maximum releases emitted independently for each app, newest first.

Use a low limit for recent-change monitoring or a high limit for backfills.

maxConcurrency

Number of app pages requested in parallel.

The allowed range is 1–10, with a conservative default of 5.

Input example

{
  "apps": [
    "324684580",
    "https://apps.apple.com/us/app/youtube-watch-listen-stream/id544007664"
  ],
  "storefront": "us",
  "maxVersionsPerApp": 50,
  "maxConcurrency": 2
}

Duplicate app/storefront entries are fetched once.

The per-app limit is applied after Apple’s release rows are parsed newest-first.

Output example

{
  "appId": "324684580",
  "appName": "Spotify: Music and Podcasts",
  "storefront": "us",
  "version": "9.1.66",
  "releaseDate": "2026-07-20",
  "releaseNotes": "We’re always making changes and improvements to Spotify...",
  "appUrl": "https://apps.apple.com/us/app/spotify-music-and-podcasts/id324684580",
  "sourceUrl": "https://apps.apple.com/us/app/spotify-music-and-podcasts/id324684580",
  "scrapedAt": "2026-07-24T00:00:00.000Z"
}

Dates are strings because App Store releases are date-granular, not time-granular.

The scrape timestamp is a full UTC date-time.

Storefront and localization behavior

A storefront can affect availability, app naming, and release history.

Raw app IDs use the storefront input.

Full App Store URLs retain the country code included in their path.

The Actor uses Apple’s machine-readable datetime value, so releaseDate remains ISO formatted even when the page displays localized text such as “3d ago” or “Jul 7.”

If an app is unavailable in a storefront, the Actor logs the affected app and continues with other valid inputs.

If every requested app is unavailable or unparseable, the run fails instead of returning a misleading empty success.

Tips for reliable app update monitoring

• 🎯 Use numeric IDs when your watchlist already stores Apple identifiers.
• 🌐 Use full URLs when each app must retain a specific storefront.
• 🧪 Start with one app and 25 versions when validating a new workflow.
• 📅 Schedule recurring tasks daily or weekly for competitor monitoring.
• 🔑 Deduplicate downstream on appId, storefront, version, and releaseDate.
• 🕒 Use scrapedAt to distinguish data freshness from the public release date.
• 📉 Lower maxVersionsPerApp after an initial historical backfill.

The Actor itself removes duplicates inside a run.

For cross-run change detection, compare the stable deduplication key in your database or automation platform.

Integrations and automation workflows

Google Sheets or Excel

Export the dataset as CSV or Excel, then build update-cadence pivots by app and month.

Make

Schedule the Actor, watch for completed runs, and send newly observed versions to Slack or Notion.

Zapier

Trigger a run from a watchlist update and route recent release notes into a research workflow.

Webhooks

Attach an Apify run webhook to notify your service when a refresh succeeds or fails.

Data warehouses

Fetch dataset items through the API and upsert on the four-field deduplication key.

AI analysis

Pass release-note rows to an LLM to classify themes such as reliability, monetization, AI features, design changes, or platform support.

Run with the Apify API using JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('automation-lab/apple-app-store-version-history-scraper').call({
    apps: ['324684580', '544007664'],
    storefront: 'us',
    maxVersionsPerApp: 50,
    maxConcurrency: 2,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Use environment variables for tokens rather than hard-coding credentials.

Run with the Apify API using Python

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ['APIFY_TOKEN'])
run = client.actor('automation-lab/apple-app-store-version-history-scraper').call(
    run_input={
        'apps': ['324684580'],
        'storefront': 'us',
        'maxVersionsPerApp': 25,
        'maxConcurrency': 1,
    }
)

items = client.dataset(run['defaultDatasetId']).list_items().items
print(items)

The dataset remains available after the run according to your Apify account retention settings.

Run with cURL

curl -X POST \
  "https://api.apify.com/v2/acts/automation-lab~apple-app-store-version-history-scraper/runs?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "apps": ["324684580"],
    "storefront": "us",
    "maxVersionsPerApp": 25,
    "maxConcurrency": 1
  }'

Poll the returned run ID or use the synchronous endpoint when appropriate for your client timeout.

Never commit your Apify token to source control.

Use with Apify MCP and AI assistants

Connect the Actor to Claude Code with:

$claude mcp add --transport http apify "https://mcp.apify.com?tools=automation-lab/apple-app-store-version-history-scraper"

For Claude Desktop, Cursor, or VS Code, add an HTTP MCP server configuration:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=automation-lab/apple-app-store-version-history-scraper"
    }
  }
}

Example prompts:

• “Get the last 25 Spotify iOS versions and summarize recurring release-note themes.”
• “Compare YouTube and Instagram update cadence in the US storefront.”
• “Export these five app IDs as a chronological release timeline.”
• “Highlight weeks where more than one monitored competitor shipped an update.”

MCP lets the assistant start the Actor and inspect structured results without custom integration code.

Scheduling a competitor release monitor

Create an Apify task with a stable list of app IDs.

Run it daily or weekly, depending on how quickly you need update alerts.

After the first historical backfill, your downstream workflow can ignore already-seen deduplication keys.

Recommended pattern:

1. schedule the Actor task;
2. receive a successful-run webhook;
3. fetch the new dataset;
4. upsert releases into your store;
5. alert only on unseen keys;
6. summarize the new notes for stakeholders.

This separates reliable extraction from custom notification logic.

Error handling and troubleshooting

The Actor validates input before making requests.

Per-app failures use typed log codes:

• APP_FETCH_FAILED for HTTP or request failures;
• VERSION_HISTORY_NOT_FOUND when Apple returns an app page without historical rows;
• INVALID_APP_PAGE when the response does not contain expected app identity.

Other valid apps continue even when one entry fails.

A run with zero extracted versions exits non-zero so automation can distinguish failure from an unchanged watchlist.

Is scraping Apple App Store version history legal?

The Actor extracts publicly accessible information displayed on Apple App Store product pages.

No login, private account, or access-control bypass is used.

You are responsible for using the data in accordance with applicable laws, Apple’s terms, privacy obligations, database rights, and your own contractual requirements.

Avoid excessive request volume, do not use the output for harassment or deception, and consult qualified legal counsel when your use case has regulatory implications.

This documentation is general information, not legal advice.

Frequently asked questions

Does it return the latest release only?

No. It returns historical rows rendered in Apple’s Version History section, up to maxVersionsPerApp.

Can I provide an app ID instead of a URL?

Yes. Use a numeric ID such as 324684580 or id324684580 and set the desired storefront.

Does it scrape Android or Google Play history?

No. Inputs are strictly limited to Apple’s apps.apple.com domain and Apple app IDs.

Why did one app produce no rows?

The app may be unavailable in that storefront, removed, age-restricted, or missing a public version-history section. Check the logged typed error and try the canonical URL for the intended storefront.

Why did the whole run fail?

The Actor fails when every requested app fails validation, fetching, or extraction. This prevents a false successful run with an empty dataset.

Are dates localized?

No. releaseDate uses Apple’s ISO date attribute, while the visible localized label is intentionally ignored.

Does it need a proxy?

No proxy is used by default. The public server-rendered App Store page currently provides the required history over ordinary HTTP requests.

Can two storefronts contain the same version?

Yes. Storefront remains part of the output and deduplication key, so equivalent versions from different storefronts are retained.

Related Apple App Store scrapers

Use these automation-lab Actors for adjacent workflows:

• Apple App Store Scraper for current app metadata.
• Apple App Store Reviews Scraper for customer review analysis.
• Apple App Store Top Charts Scraper for ranking and category monitoring.
• Apple App Store Developer Portfolio Scraper for apps published by a developer.
• Apple App Privacy Labels Scraper for declared data-use and privacy fields.

Choose this Actor when the primary entity you need is a historical app release.

Data quality and change resilience

The extractor anchors version records on semantic page elements: the Version History heading, list rows, and time[datetime] dates.

It does not depend only on generated CSS class names.

App identity comes from Apple’s SoftwareApplication structured data.

HTML entities are decoded, line breaks are retained where available, and whitespace is normalized.

Duplicate rows are removed before saving and charging.

If Apple materially removes server-rendered history, the Actor fails visibly rather than emitting guessed fields.

Support

If a valid public App Store app unexpectedly fails, include:

• the app URL or numeric ID;
• the storefront;
• the Actor run URL;
• whether the app opens publicly in a browser;
• the expected version visible on Apple’s page.

Do not include passwords, private account information, or unrelated personal data.

Clear reproduction details make storefront and markup issues faster to diagnose.