Apple App Store Reviews Scraper (No API Key, No Login)

Apify Actor · Public data · No source-site login · JSON / CSV / Excel · Pay per stored result

Collect recent written customer reviews for public Apple App Store apps. Enter numeric app IDs or App Store URLs, choose a two-letter storefront, and set a per-app cap. Each row is one review with app name, rating, title, text, author, version and update date. Use it for repeatable research, lightweight monitoring and clean exports. Results are stored in your Apify dataset with public source links when available.

Start with the prefilled example, check the fields and press Run.

Table of contents

• What it collects · Who uses it · Fields · How to run · Input · Output · Workflows · Limits · Pricing · API and MCP · FAQ · Related searches · Disclaimer · Resources · 中文说明

What it collects

• appstore-reviews-scraper records from public pages or feeds.
• One structured row per valid entity, launch, listing or written review.
• Flat top-level fields for table, CSV and spreadsheet use.
• Nulls where the public source does not provide a value.
• Bounded inputs and result caps for predictable runs.

The Actor does not ask for passwords or cookies. It does not bypass login, CAPTCHA, private content or another access control. HTTP 200 by itself is not treated as business success; a valid row must be stored.

Who uses it

Product and market researchers, developers, analysts, newsletter writers, monitoring workflows and AI automation builders can use the dataset as a starting point. Keep the source URL and run timestamp when you need to audit a comparison.

Fields

Field	Type	Description
appId	string	Numeric App Store application identifier.
appName	string	Name resolved from Apple lookup.
author	string or null	Public reviewer display name.
title	string or null	Review title.
review	string or null	Written review text.
rating	number or null	Star rating from 1 through 5.
version	string or null	App version shown with review.
updated	string or null	Apple update timestamp.

Nullable fields can be absent on the source. Arrays can be empty if the page does not expose members. The overview is a convenience table; the full dataset API keeps all returned fields.

Field-by-field notes

appId. Numeric App Store application identifier. The value comes from the public source or the submitted identifier; no private account data is added.

appName. Name resolved from Apple lookup. The value comes from the public source or the submitted identifier; no private account data is added.

author. Public reviewer display name. The value comes from the public source or the submitted identifier; no private account data is added.

title. Review title. The value comes from the public source or the submitted identifier; no private account data is added.

review. Written review text. The value comes from the public source or the submitted identifier; no private account data is added.

rating. Star rating from 1 through 5. The value comes from the public source or the submitted identifier; no private account data is added.

version. App version shown with review. The value comes from the public source or the submitted identifier; no private account data is added.

updated. Apple update timestamp. The value comes from the public source or the submitted identifier; no private account data is added.

How to run it

1. Open Input and review the prefilled public example.
2. Add a public target or choose a supported mode.
3. Stay within the input maximums.
4. Start the run and inspect the overview view.
5. Export CSV/Excel or retrieve every field with the Dataset API.
6. Save the run time and dataset ID to compare later snapshots.

Input example

{
  "appIds": [
    "284882215"
  ],
  "country": "us",
  "maxPerApp": 10
}

appIds accepts numeric IDs or public App Store URLs. country is a two-letter storefront code; maxPerApp is a per-app cap.

Output example

This example came from a live public-source run. Current values can change.

{
  "appId": "284882215",
  "appName": "Facebook",
  "author": "Tryarthurdent",
  "title": "Seat 2A on a flight",
  "rating": 1,
  "version": "580.0.0",
  "updated": "2026-09-27T16:14:48-07:00"
}

The overview view selects common columns. Use Full JSON or /items without a view to read the full item.

Workflows

1. App feedback sample. Collect a small recent sample by app ID for manual product review.
2. Country comparison. Run separate storefronts such as us, gb and de; review sets differ.
3. Release monitoring. Schedule repeated runs and group by appId and updated.
4. Version QA. Group low-star reviews by version to investigate release feedback.
5. Localization review. Select a storefront per run and keep country with the dataset.
6. Text analysis. Export titles and text to a sentiment pipeline; this is not a representative survey.
7. Multi-app batch. Pass several app IDs and cap rows per app.
8. App page validation. Compare appName and ID with the live listing before analysis.

Limits and data quality

The public feed contains written reviews, not ratings-only entries or developer responses. Apple can return empty pages between populated pages; the core scans the bounded page range rather than stopping at the first empty page. Results are recent and storefront-specific, not a full archive.

Invalid inputs, source denials and empty results fail without writing a billable result row. A valid plan-limit response exits cleanly with no new rows.

No paid-proxy free-plan quota is enabled for this Actor. Apple can still omit or limit public feed results; an empty written-review feed does not mean there are no ratings.

Pricing

PAY_PER_EVENT pricing is $0.00008 per stored result item. Only a row written to the default dataset triggers the result-item event. Failed runs, invalid inputs, quota-blocked runs and empty results have no result-item charge. Apify retains its configured 20% share. The verified acceptance route used zero proxy bytes per result; platform usage, if shown separately by Apify, is not part of this event price.

Start with a small cap. Increase it only after checking the input maximum and your run spending limit.

API, MCP and integrations

Keep your Apify token in an environment variable. Do not paste it into a public notebook.

Run synchronously

curl -X POST "https://api.apify.com/v2/acts/myagizm/appstore-reviews-scraper/runs?waitForFinish=300" \
 -H "Authorization: Bearer $APIFY_TOKEN" -H "Content-Type: application/json" -d '{"appIds":["284882215"],"country":"us","maxPerApp":10}'

Start asynchronously

curl -X POST "https://api.apify.com/v2/acts/myagizm/appstore-reviews-scraper/runs" \
 -H "Authorization: Bearer $APIFY_TOKEN" -H "Content-Type: application/json" -d '{"appIds":["284882215"],"country":"us","maxPerApp":10}'

Read dataset

$curl "https://api.apify.com/v2/datasets/DATASET_ID/items?clean=true&format=json" -H "Authorization: Bearer $APIFY_TOKEN"

Apify MCP can run the same public input and read the dataset. You can also use schedules, Make, n8n, webhooks and spreadsheet exports. Integrations do not change what the source makes public.

FAQ

What does one row mean?

One row is one valid public entity or review described in the field table. Notes and failed targets are not result rows.

Do I need a source login?

No. The Actor reads public pages or feeds that do not require a source-site login.

Do I need a source API key?

No customer source API key is required. You still need an Apify account to start a run.

Why can fields be null?

The source may omit a value. Missing counts or metadata remain null instead of being guessed.

Does the cap guarantee that many rows?

No. It is a maximum. A source can return fewer items, or a target can be unavailable.

What happens on invalid input?

The run fails cleanly before a billable result row is stored.

What happens at the free limit?

For limited backends, the Actor returns a clear quota note and stores no new rows.

Can I export CSV?

Yes. Use the Apify dataset export menu or Dataset API in supported formats.

Can I schedule runs?

Yes. Use Apify schedules and retain the dataset ID and timestamp.

Are private pages supported?

No. Login-gated, private or removed content is not bypassed.

Are results historical?

No. Results describe the public source during this run.

Can I batch targets?

Yes, within the input maximum in the schema.

Are array fields always populated?

No. Arrays can be empty when the source does not expose members.

Can I use MCP?

Yes. Apify MCP can run the same input and read the resulting dataset.

Does overview show every field?

No. Full JSON and Dataset API show the complete row.

How do I validate a row?

Open the source URL and compare stable fields; dynamic counters can change.

What is the price unit?

One dataset result item. Failed and empty runs have no result-item charge.

Are platform costs separate?

Apify may show platform usage separately; check the run usage panel.

Can I redistribute the output?

Check source terms and applicable law before reuse or republication.

How do I report a problem?

Open an Apify issue with run ID, public input and the incorrect field. Never attach credentials.

Related searches

app store reviews scraper · apple app store reviews · ios app reviews · review export · app reviews by id · recent iOS reviews · app version reviews · review sentiment · public Apple review feed · country storefront reviews · app review monitor · iPhone reviews · app review CSV · app review JSON · Apple customer reviews · competitor reviews · release feedback · storefront data · app review text · Apple app metadata · review analysis · feedback dataset · App Store public data · app ratings · written reviews

Disclaimer

This is an independent data tool and is not affiliated with Apple. It reads public data only. Follow source terms, applicable law and your retention policy. Public visibility does not grant permission to republish copyrighted text or trademarks.

Resources

• Apify API
• Datasets
• Schedules
• Integrations
• Apify MCP
• myagizm tools

中文说明

Actor 用途

读取 Apple App Store 公开应用的近期文字评论。输入数字应用 ID 或 App Store URL，选择两位 storefront 代码并设置每个应用的上限。每条数据对应一条评论，包含应用名称、评分、标题、正文、作者、版本和更新时间。 可用于公开数据研究、轻量监控和结构化导出。结果写入 Apify 默认 Dataset，并保留来源提供的链接。Actor 不索取源站密码或 Cookie，也不会绕过登录、CAPTCHA、私有页面或访问控制。结果反映本次运行时的公开数据，不是永久档案。

适用对象

产品和市场研究人员、开发者、分析师、新闻简报作者、监控流程以及 AI 自动化构建者都可以使用该数据集。需要审计比较时，请保留来源链接和运行时间。

字段表

字段	类型	说明
appId	string	Numeric App Store application identifier.
appName	string	Name resolved from Apple lookup.
author	string or null	Public reviewer display name.
title	string or null	Review title.
review	string or null	Written review text.
rating	number or null	Star rating from 1 through 5.
version	string or null	App version shown with review.
updated	string or null	Apple update timestamp.

字段解释

appId。 Numeric App Store application identifier. 该值来自公开来源或输入标识符，不加入私有账号数据。

appName。 Name resolved from Apple lookup. 该值来自公开来源或输入标识符，不加入私有账号数据。

author。 Public reviewer display name. 该值来自公开来源或输入标识符，不加入私有账号数据。

title。 Review title. 该值来自公开来源或输入标识符，不加入私有账号数据。

review。 Written review text. 该值来自公开来源或输入标识符，不加入私有账号数据。

rating。 Star rating from 1 through 5. 该值来自公开来源或输入标识符，不加入私有账号数据。

version。 App version shown with review. 该值来自公开来源或输入标识符，不加入私有账号数据。

updated。 Apple update timestamp. 该值来自公开来源或输入标识符，不加入私有账号数据。

使用步骤

1. 打开 Input 并检查预填公开示例。
2. 添加公开目标或选择支持模式。
3. 遵守输入最大值。
4. 启动运行并检查 overview 视图。
5. 导出 CSV/Excel，或使用 Dataset API 读取全部字段。
6. 如需比较快照，请保存运行时间和数据集 ID。

工作流

1. App feedback sample。 Collect a small recent sample by app ID for manual product review.
2. Country comparison。 Run separate storefronts such as us, gb and de; review sets differ.
3. Release monitoring。 Schedule repeated runs and group by appId and updated.
4. Version QA。 Group low-star reviews by version to investigate release feedback.
5. Localization review。 Select a storefront per run and keep country with the dataset.
6. Text analysis。 Export titles and text to a sentiment pipeline; this is not a representative survey.
7. Multi-app batch。 Pass several app IDs and cap rows per app.
8. App page validation。 Compare appName and ID with the live listing before analysis.

限制与数据质量

公开 feed 仅包含文字评论，不包括只有星级的评分或开发者回复。Apple 可能在有内容的页面之间返回空页；core 会扫描有限页面范围，不会在首个空页停止。结果按 storefront 区分且仅覆盖近期内容，不是完整档案。

无效输入、来源拒绝或空结果会失败，不会写入可计费结果行。有效额度限制会以成功状态返回，不新增结果。

本 Actor 未启用付费代理免费额度。Apple 仍可能省略或限制公开 feed 结果；没有文字评论不代表没有评分。

价格

本 Actor 使用 PAY_PER_EVENT，当前价格为 每条已存储结果 $0.00008 美元。只有写入默认 Dataset 的行才触发结果事件。失败、无效输入、额度阻止和空结果不产生结果项费用。Apify 按配置保留事件价格的 20%。验收路由直连，每条结果代理流量为零；如果 Apify 单独显示平台使用费，该费用不属于事件价格。

首次运行请使用小上限。提高上限前检查输入最大值和 Apify 支出限制。

API、MCP 与集成

请将 Apify Token 保存在环境变量中。可以通过 API 同步启动、异步启动并读取 Dataset，也可以设置 Schedule 或连接 Make、n8n、Webhook 和表格导出。MCP 使用相同输入，不会改变源站公开范围。

常见问题

一条数据代表什么？

一条数据是字段表定义的一个有效公开实体或评论。说明和失败目标不会写入结果行。

需要源站登录吗？

不需要。本 Actor 只读取无需登录的公开页面或 feed。

需要源 API Key 吗？

不需要客户自己的源站 API Key。启动运行仍需要 Apify 账号。

字段为何为 null？

公开来源可能没有提供该值。缺失数据会保持 null，不会猜测。

结果上限是保证行数吗？

不是。它只是最大值；来源可能返回较少项目，目标也可能不可用。

无效输入如何处理？

运行会清晰失败，不会写入可计费结果行。

达到免费额度后会怎样？

受额度限制的后端会返回清晰说明，不会写入新结果。

可以导出 CSV 吗？

可以。使用 Apify Dataset 导出菜单或 Dataset API。

可以定时运行吗？

可以。使用 Apify Schedule，并保存数据集 ID 和运行时间。

支持私有页面吗？

不支持，不会绕过登录限制、私有页面或已删除内容。

结果是历史数据吗？

不是。结果对应本次运行时的公开来源。

可以批量传目标吗？

可以，但需遵守 Schema 中的最大值。

数组字段总有内容吗？

不保证。来源未提供成员数据时数组可能为空。

可以使用 MCP 吗？

可以。Apify MCP 可运行相同输入并读取 Dataset。

概览显示所有字段吗？

不会。Full JSON 和 Dataset API 展示完整记录。

如何验证结果？

打开来源链接并核对稳定字段；动态计数可能变化。

价格单位是什么？

每条 Dataset 结果项。失败和空结果不产生结果项费用。

平台费用是否另计？

Apify 可能单独显示平台使用费，请查看运行用量面板。

可以重新发布数据吗？

请先核对源站条款和适用法律。

如何反馈问题？

在 Apify Issues 中提供运行 ID、公开输入和有误字段，不要附带凭据。

相关搜索

Apple App Store 评论抓取 · iOS 评论导出 · App Store 评分与评论 · Apple 评论数据 · 按应用 ID 获取评论 · 按国家获取评论 · 应用版本评论 · 近期 iPhone 评论 · 评论情感分析 · Apple 公开 feed · 反馈数据集 · 评论监控 · 评论 CSV · 评论 JSON · 竞品评论分析

免责声明

本 Actor 是独立数据工具，与 Apple 无关联，只读取公开数据。请遵守源站条款、适用法律和组织的数据保留政策。公开可见不等于可以重新发布受版权保护文本或商标。

资源

• Apify API 文档
• Apify Dataset
• Apify Schedule
• Apify 集成
• Apify MCP
• myagizm 的其他工具

Repeatable operating notes

1. Keep comparison inputs stable. Repeat the same public targets, storefront or topic, cap and run mode. A changed input can explain a different row count without any change to the Actor.
2. Keep the run timestamp. Public listings and feeds change during the day. Save the Apify run ID, start time and dataset ID next to exports so later readers know when the snapshot was taken.
3. Inspect more than the table. The overview view is a selected projection. Open a raw dataset item when a value appears blank; the complete JSON may contain fields that the table does not show.
4. Do not read an empty page as proof of no data. Public sources can return sparse pages, no current feed entry or an entity with no written records. Use the source-specific limits above before drawing a conclusion.
5. Use identifiers as join keys. Prefer the stable app ID, entity ID, handle or launch ID over a display name. Names can change, be localized or collide across unrelated records.
6. Treat counts as snapshots. Ratings, followers, votes and review totals can change after a run. Compare them with timestamps; separately collected pages are not guaranteed to update at the same moment.
7. Preserve source URLs. A source link makes a row easier to audit and lets a reviewer check context. Redirect links can change destination, so open them before using them in a long-lived report.
8. Understand nullable fields. Null means the public source did not provide a usable value in this run. It does not mean zero, false or a value inferred from another record.
9. Keep arrays intact. Track lists, makers, genres and categories can contain multiple values. Do not flatten them into a comma-separated string if you need exact membership.
10. Start with a small cap. A three-row sample is enough to validate field names and source alignment. Increase the cap only when the first sample is correct and the destination is ready.
11. Split large batches by purpose. Separate unrelated searches or storefronts when their results need different retention, review or notification rules.
12. Deduplicate with stable keys. If feeds or searches overlap, use the entity identifier or canonical URL. Do not use a title alone as a deduplication key.
13. Check the requested output shape. Confirm the input selected the intended mode and that the returned row type matches it before joining rows to another dataset.
14. Keep notes out of business rows. Run notes explain partial data or limits; they are not result items and should not be included in a customer export as if they were records.
15. Separate source limits from Actor failures. A field absent from a public source is a coverage limit. A blocked request or invalid target is a failed input and should not be described as a successful empty result.
16. Review billing before scaling. Charges follow stored rows, not the number of rows you hoped to receive. Start with a small cap and read the run charge summary after the sample.
17. Use a deliberate schedule. A daily cadence is enough for many public snapshots. Running more often does not make the source update faster and can create duplicate observations.
18. Keep downstream assumptions explicit. If a workflow requires a rating, date or URL, validate that field before using the row. Do not silently coerce null to zero or an empty string.
19. Export the full dataset when needed. A displayed column is not the entire record. Use the full JSON endpoint for analysis that depends on fields outside the overview projection.
20. Re-check after schema updates. A task saved before an input change may contain an old field shape. Review saved task input before rerunning it against a new build.
21. Treat public text carefully. Review text, taglines and descriptions are user-generated or copyrighted material. Keep excerpts short when sharing and follow the source terms.
22. Retain only what you need. Decide how long to keep raw text and identifiers in your own storage. Apify dataset retention and downstream retention are separate choices.
23. Report reproducible issues. Include a run ID, public sample target, the field that differs and expected behavior. This is more useful than a screenshot of a blank table alone.
24. Do not send credentials in support requests. Public URLs and run IDs are enough to investigate most data-shape or source-availability questions.
25. Check the first record before automating follow-up actions. A correct schema does not prove every row is relevant to a business decision.
26. Preserve the original input beside transformed data. If a downstream job normalizes names or categories, keep the source row so the transformation can be audited.
27. Compare like with like. Do not compare a daily feed to an app detail page or a US storefront to a UK storefront as if they were the same sample.
28. Record exceptions instead of hiding them. If a source omits a field or a target fails, keep a note or failure record in your own workflow rather than filling in a guessed value.
29. Validate joins before counting. A duplicate or malformed identifier can multiply records in a spreadsheet or warehouse even when the Actor output is correct.
30. Use modest concurrency. Public data availability can change under bursts; begin sequentially and increase parallelism only after a bounded real test.

可重复运行的操作说明

1. 比较变化时保持输入一致。重复相同的公开目标、storefront 或主题、上限和运行模式。输入不同也会导致行数变化。
2. 保存运行时间。公开列表和 feed 会变化。导出文件旁保存 Apify run ID、开始时间和 Dataset ID，便于确认快照时间。
3. 不要只看表格。概览视图只显示选定字段。若某列为空，请打开原始数据项；完整 JSON 可能包含表格未显示的字段。
4. 空页不等于没有数据。公开来源可能返回稀疏页面、暂时没有 feed 条目，或实体没有文字记录。请结合上文来源限制判断。
5. 用标识符关联数据。优先使用应用 ID、实体 ID、handle 或发布 ID，不要只依赖显示名称。名称可能变化、本地化或重复。
6. 把计数视为快照。评分、关注者、投票和评论数可能变化。比较时保留时间戳；不同页面不一定同时更新。
7. 保留来源 URL。来源链接便于审计和核对。跳转链接的目标可能变化，长期使用前请先验证。
8. 理解可空字段。null 表示本次运行未从公开来源获得有效值，不代表零、false 或可从其他记录推断的值。
9. 保留数组结构。曲目、发布者、流派和分类可能包含多个值。需要精确保留时不要压成逗号分隔字符串。
10. 先用小上限。三条样本通常足以核对字段和来源。确认样本正确、下游目标准备好后再提高上限。
11. 按用途拆分大批次。不同搜索或 storefront 若有不同保留、审核或通知规则，请分开运行。
12. 用稳定键去重。不同 feed 或搜索可能重叠，使用实体 ID 或规范 URL；不要只用标题去重。
13. 核对输出形状。合并到其他数据集前，确认输入模式正确，返回行类型符合预期。
14. 不要把 notes 当业务行。运行说明用于解释部分数据或限制，不是结果记录，不应作为客户数据导出。
15. 区分来源限制和 Actor 失败。公开来源没有字段属于覆盖限制；请求被阻止或目标无效属于失败输入，不应描述为空成功结果。
16. 扩大运行前检查账单。费用按实际写入行计算，不按预期行数计算。先用小上限并查看运行费用摘要。
17. 选择合适计划周期。很多公开快照每天运行一次即可。频繁运行不会让来源更快更新，还可能产生重复观察。
18. 明确下游假设。若工作流要求评分、日期或 URL，请使用前验证字段。不要把 null 默默转换成零或空字符串。
19. 需要完整记录时导出全量数据。页面显示的列不是完整记录。依赖概览以外字段时，请使用完整 JSON 接口。
20. Schema 更新后重新检查。输入字段变化后，旧 Task 可能保留旧结构。新 build 运行前先检查已保存输入。
21. 谨慎处理公开文本。评论、标语和描述可能受版权保护或由用户撰写。分享时尽量引用短片段并遵守源站条款。
22. 只保留必要数据。为原始文本和标识符制定保留期限。Apify Dataset 与下游存储的保留设置彼此独立。
23. 报告可复现问题。提供 run ID、公开样本目标、异常字段和预期行为，比单独提供空表截图更有帮助。
24. 支持请求不要附凭据。大多数字段或来源问题只需公开 URL 和运行 ID 即可调查。
25. 自动执行后续动作前检查首条记录。Schema 正确并不能证明每行都适合某项业务决策。
26. 在转换数据旁保留原始输入。下游任务若规范化名称或分类，请保留来源记录以便审计。
27. 只比较同类数据。不要把每日 feed 与应用详情页，或 US 与 UK storefront，当作同一个样本比较。
28. 记录例外而不是隐藏。来源缺字段或目标失败时，在自己的工作流保留说明，不要填入猜测值。
29. 统计前验证关联。重复或格式错误的标识符可能让表格或仓库中的记录倍增。
30. 并发从低开始。公开数据可用性可能受突发请求影响，先顺序运行，再在有界实测后增加并发。

Errors & billing

Input errors finish with status SUCCEEDED, no results and no charge; see the OUTPUT record for the reason.

错误与计费

输入错误会以 SUCCEEDED 状态结束，不产生结果且不收费；原因请查看 OUTPUT 记录。