App Store & Google Play Scraper & Monitor
Pricing
from $2.00 / 1,000 successful app checks
App Store & Google Play Scraper & Monitor
Scrape App Store and Google Play app metadata, ratings, prices, releases, reviews, and developer replies in one normalized dataset. Monitor up to 500 iOS and Android apps for exact changes and new reviews—no API key, login, or browser required.
Pricing
from $2.00 / 1,000 successful app checks
Rating
0.0
(0)
Developer
Vadim Bezrukov
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
3 days ago
Last modified
Categories
Share
Scrape App Store and Google Play app metadata and reviews into one normalized Dataset, then monitor iOS and Android apps for new releases, version changes, prices, ratings, new reviews, and developer replies.
Paste up to 500 numeric App Store IDs, Google Play package IDs, or full store
URLs. Use snapshot mode for a current app-data or review export, or monitor
mode for a reusable baseline and exact changes. No API key, login, or browser is
required, and direct HTTP normally works without a proxy.
What data can this App Store and Google Play scraper extract?
- one normalized app record for every input, including explicit
SUCCESS,PARTIAL,NOT_FOUND,RATE_LIMITED,FAILED,INVALID_INPUTorSKIPPED_BILLING_LIMITstatus; - first successful monitor run as
BASELINE, then exact changed fields; NEW_RELEASE,VERSION_CHANGED, price/free/paid, rating and metadata changes;- deterministic rating/count deltas and semantic fingerprints;
- only newly observed reviews on later runs, with a first-class 1–2 star feed;
- developer-reply-added events where the public source exposes replies;
- a compact last-successful state per store/app/country/language in Apify KVS.
A failed or partial check never overwrites good state. A source error can never masquerade as zero reviews, a rating drop or an app removal.
How to scrape App Store and Google Play apps
- Add one or more App Store IDs, Google Play package IDs, or full listing URLs
to
apps. - Choose
snapshotfor a current export ormonitorfor baseline-and-change tracking. - Turn reviews on or off, set the maximum review window, and optionally select star ratings.
- Run the Actor and open the Dataset in Apify, or retrieve the rows through the API in JSON, CSV, Excel, XML, or another supported format.
Use structured objects when you need country, language or your own IDs:
{"apps": [{"store": "google_play","id": "com.spotify.music","country": "US","language": "en","externalId": "spotify-android","groupId": "spotify"},{"store": "app_store","id": "324684580","country": "US","externalId": "spotify-ios","groupId": "spotify"}],"mode": "monitor","outputMode": "changesOnly"}
Full store URLs also work in the same id field:
{"apps": [{"store": "app_store","id": "https://apps.apple.com/us/app/spotify-music-and-podcasts/id324684580"},{"store": "google_play","id": "https://play.google.com/store/apps/details?id=com.spotify.music&hl=en&gl=US"}],"mode": "snapshot","outputMode": "all"}
groupId is an explicit join key supplied by you. The Actor never guesses that
an iOS and Android listing are the same product.
Saved Apify Tasks automatically isolate monitoring state by Task ID. For direct
API runs, set a stable monitorId when you need multiple independent baselines
for the same app/storefront.
App Store and Google Play scraper output
Every input produces an app status row. Review collection adds one row per matching review or developer-reply event. Records use stable source IDs, timestamps, semantic fingerprints, and explicit status/change types:
[{"record_type": "app","store": "google_play","app_id": "com.example.music","status": "SUCCESS","change_type": "NEW_RELEASE","previous_version": "1.9.0","current_version": "2.0.0","rating": 4.6,"scraped_at": "2026-09-01T10:00:00Z"},{"record_type": "review","store": "google_play","app_id": "com.example.music","review_id": "review-example-001","rating": 1,"text": "Playback stops after the latest update.","change_type": "NEW_NEGATIVE_REVIEW"}]
The apps Dataset view selects app-status columns and reviewEvents selects
review columns. Views select columns but do not filter row types; API consumers
should filter record_type when they need only apps or only reviews.
App Store and Google Play scraper workflows
Export app metadata for ASO and market research
Set mode to snapshot, outputMode to all, and includeReviews to false.
This returns current releases, versions, prices, ratings, counts, categories,
descriptions, screenshots, and explicit per-app status without creating state.
Export App Store and Google Play reviews
Set mode to snapshot, outputMode to all, and includeReviews to true.
Choose maxReviewsPerApp and reviewRatings to export current review text,
public author display names, app versions, helpful votes, and Google Play
developer replies. The resulting Dataset is ready for CSV, Excel, JSON, or API
use.
Competitor watchlist and new releases
Keep the defaults (monitor + changesOnly) and schedule the same input daily.
The first run establishes a baseline. A later version/timestamp change produces
NEW_RELEASE with previous_version, current_version, release notes and
detected_at.
New 1–2 star reviews
{"apps": [{"store": "google_play", "id": "com.spotify.music", "country": "US"},{"store": "app_store", "id": "324684580", "country": "US"}],"mode": "monitor","outputMode": "changesOnly","includeReviews": true,"maxReviewsPerApp": 100,"reviewRatings": [1, 2]}
The baseline stores existing IDs without alerting them. Later unseen 1–2 star
IDs are NEW_NEGATIVE_REVIEW and are ready for a webhook payload.
Changing maxReviewsPerApp starts a fresh review-window baseline for each app.
This deliberately prevents older reviews exposed by a wider window from being
misreported as newly posted; app metadata monitoring continues from its existing
baseline.
Automate app monitoring with schedules and webhooks
Create one Apify Task with the watchlist input and attach a daily schedule in the Apify Console. Keep the same Task/KVS between runs; starting each run under a new storage scope creates a new baseline.
A practical daily schedule is 0 6 * * * (06:00 UTC). Through the API, create
an Apify schedule whose action runs the saved Task; do not run this monitor from
a local cron job that stops when your machine is offline.
For alerts, add a Dataset-item webhook to the Task run and route records where:
record_type == "app" AND change_type NOT IN ("BASELINE", "UNCHANGED")ORrecord_type == "review" AND change_type IN("NEW_REVIEW", "NEW_NEGATIVE_REVIEW", "DEVELOPER_REPLY_ADDED")
The supplied Dataset views select useful columns but do not filter rows. API and
webhook consumers should always apply the record_type and change_type
conditions above themselves.
Use with AI agents through Apify MCP
Expose the Actor as a typed tool in an MCP-compatible client with Apify's hosted MCP server:
https://mcp.apify.com?tools=automa-flow/app-store-google-play-monitor
Example prompt:
Run automa-flow/app-store-google-play-monitor in snapshot mode for these AppStore IDs and Google Play package IDs. Return app metadata and up to 100 recentreviews per app, group 1–2 star reviews by recurring complaint, and preserveeach record's source_url in the answer.
For recurring agent workflows, use mode: monitor with a stable monitorId
and act only on explicit change types. FAILED and PARTIAL rows mean the
source was not fully verified; they never mean that nothing changed.
How much does it cost to scrape App Store and Google Play?
The Actor uses pay per event:
- $0.002 app check for each distinct app/storefront that returns
SUCCESS, including a quiet monitor check where nothing changed; - $0.002 app change for a deterministic non-baseline app change delivered to the Dataset;
- $0.0005 review result for each baseline or newly observed review, or newly added developer reply, delivered to the Dataset.
Invalid, failed, partial, rate-limited and billing-skipped checks are not charged. Retries, duplicate app aliases and unchanged reviews are never charged. Set an Apify run spending limit when processing a new large watchlist.
App Store and Google Play scraper limits
- Apple public reviews are capped at 10 pages × 50 reviews per app/country.
- Apple developer replies are not in the public feed and remain
null. - Google Play is an undocumented public web protocol, so schema health checks deliberately fail closed when Google changes it.
- Country changes availability, price, rating and counts. Monitor each country as a separate watchlist entry.
- Direct HTTP is the default; expected proxy cost is $0 and browser time is zero.
- Metadata is one request/app. At 100 reviews, Apple normally needs two additional requests and Google one additional request.
Public store data can still be subject to platform terms, copyright and privacy rules. You are responsible for your use and redistribution. The Actor keeps only compact monitoring state and does not retain raw source payloads.
Review rows include the public review text and the author's public display name. The Actor does not enrich or contact reviewers. Compact KVS monitoring state keeps review IDs and developer-reply fingerprints, not author names or review text; Dataset retention is controlled by your Apify storage settings.
FAQ
Do I need an App Store, Google Play, or developer API key?
No. The Actor reads public App Store and Google Play listing/review data without a login or developer account. Apple metadata uses its public Lookup API; Google Play data comes from public web responses and an undocumented public review protocol.
Can I export App Store and Google Play reviews to CSV or Excel?
Yes. Run a review snapshot, open the Apify Dataset, and export it as CSV, Excel, JSON, XML, or another supported format. You can also retrieve the same rows via the Apify API.
Can I monitor competitor app releases and ratings?
Yes. Keep the same saved Task in monitor mode. The first successful run creates
a baseline; later successful runs return exact release, version, price, rating,
count, metadata, review, and developer-reply changes.
Does an empty review result mean the source failed?
No. A successful empty review window is different from a source failure. Failed, partial, unavailable, rate-limited, and invalid inputs receive explicit status rows and never overwrite the last successful monitoring state.