iOS App Update Tracker — Version & Changelog Monitor | $1/1K | No Key

Competitor intelligence teams, ASO managers, and app review sites use this actor to get notified the moment a competitor ships a new iOS version — before it hits the charts.

$1.00 per 1,000 app snapshots. Change-detection events billed additionally when a version update is detected.

Worked example:

• 100 apps tracked daily = 100 snapshots/day → $0.10/day (~$3/month)
• 500 apps tracked weekly = 500 snapshots/week → $0.50/week (~$2/month)
• 1,000 apps (one-time batch metadata pull) = 1,000 snapshots → $1.00

Snapshot iOS app version, changelog, ratings and metadata from the Apple iTunes lookup API (itunes.apple.com/lookup). Fully public — no API key, no authentication.

Use with scheduled runs to detect when a competitor (or your own app) releases a new version. Each run produces a snapshot; compare datasets to see what changed.

Best practice: schedule this actor to run daily via Apify Scheduler. The release_notes field tells you exactly what changed before users do. Set up a webhook to Slack or email when version changes. Use with n8n or Zapier to auto-post to Slack when a competitor updates.

Sample output

{
  "app_id": "284882215",
  "name": "Facebook",
  "version": "473.0",
  "release_date": "2026-05-28T00:00:00Z",
  "release_notes": "Bug fixes and performance improvements.",
  "rating": 2.3,
  "rating_count": 8200000,
  "developer": "Meta Platforms, Inc.",
  "parse_confidence": 1.0
}

---

Features

• Version string + release date for the current version
• Changelog / release notes (what changed in this update)
• Ratings (overall + current version), rating count
• Price, file size, genres, content rating, minimum OS version
• Developer name, bundle ID, artwork URL
• Multi-app batch: pass up to hundreds of IDs in one run
• Country code selector — compare same app across App Stores
• parse_confidence + warnings in every record — drift detection built in
• Pay Per Result (PPE) — you only pay for actual snapshots returned

Input

Field	Type	Required	Description
appIds	list	Yes	App Store IDs (e.g. 284882215) or App Store URLs
country	string	No	Country code, default us. Examples: gb, de, jp

App ID formats accepted:

• Plain numeric: 284882215
• App Store URL: https://apps.apple.com/us/app/facebook/id284882215

Output schema

Field	Type	Notes
app_id	str	Numeric App Store ID
name	str	App name
version	str	Current version string
release_date	ISO str	currentVersionReleaseDate
release_notes	str|null	Changelog text for current version
first_release_date	ISO str	Original release date
price	float	0.0 for free
currency	str	ISO 4217 (e.g. USD)
rating	float|null	Average user rating
rating_count	int|null	Total ratings
rating_current_version	float|null	Rating for current version only
developer	str	Developer name
primary_genre	str|null	Primary App Store category
genres	list	All genres
description	str|null	Long app description
content_rating	str|null	Age rating (e.g. 12+)
minimum_os_version	str|null	Min iOS version
file_size_bytes	int|null	Download size in bytes
store_url	str	App Store URL
artwork_url	str|null	512×512 icon URL
country	str	Queried country code
bundle_id	str|null	Bundle identifier
scraped_at	ISO str	Run timestamp
parse_confidence	float	0.0–1.0 parse quality score
warnings	list	Machine-readable quality flags

FAQ

Do I need an API key? No. This actor uses Apple's public iTunes lookup API — no auth, no proxy.

What formats can I export? JSON, CSV, Excel, or JSONL — from the Apify dataset UI or REST API.

How do I get alerted when an app updates? Use Apify Scheduler (daily) + a webhook to Slack or email. Pipe results to n8n or Zapier to compare version across runs and fire alerts on change.

What if an app ID is not found? The actor logs a warning and skips that ID. Apps not available in the selected country storefront will be marked as not_found_in_country in the run summary.

---

Use cases

• Competitor monitoring — schedule daily runs to catch version bumps and read changelogs before users do
• Release tracking — track your own app's release history across countries
• App metadata auditing — collect pricing, rating and genre data at scale
• App Store research — batch-lookup hundreds of apps for market research

vs. alternatives

Feature	This actor	AppFollow	Sensor Tower	AppTweak
Batch 100s of apps	✅	✅	✅	✅
Changelog / release notes	✅	✅	✅	partial
Per-country tracking	✅	partial	✅	partial
Pay-per-use (no subscription)	✅	❌	❌	❌
Cost	$1/1K	$99+/mo	$99+/mo	$99+/mo

(Verify competitor prices at publish time — adjust table accordingly.)

parse_confidence — every record carries a 0.0–1.0 data quality score. Score < 0.5 → check the warnings field.

Use with AI agents (MCP)

All actors in this suite are available via the Apify MCP server. Connect to Claude, GPT-4o, or n8n to let AI agents pull live App Store data on demand — market research, competitor monitoring, and ASO tracking automated end-to-end.

MCP config: https://mcp.apify.com/?tools=bovi/app-update-tracker

Also in this suite

• Apple App Store Scraper — full metadata + reviews
• Google Play Store Scraper — Android ecosystem
• ASO Keyword Rank Tracker — ranking intelligence
• App Store Charts Scraper — market surveillance

Technical notes

• Endpoint: https://itunes.apple.com/lookup?id={ids}&country={cc}&entity=software
• Batching: up to 100 IDs per request (API supports 200; conservative for safety)
• Rate limits: handled with exponential backoff
• Stack: Python 3.13 + Apify SDK

Integrations

Built for competitor-intelligence and ASO teams detecting the moment a rival iOS app ships a new version — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

• Appstore Charts
• Appstore Reviews
• ASO Keyword Tracker
• Google Play Scraper
• Google Search (SERP) Scraper
• Similarweb Traffic Scraper

Chain any of them together from the Integrations tab (the Run succeeded trigger) to build a multi-step workflow — one actor's output feeds the next.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.