← Guides

How-to

How to run App Review Teardown & Insights (AI)

Step-by-step: the exact input, what each field does, and the real rows that come back from App Store & Google Play.

You open this actor when you need to know what an app’s users actually say, and you don’t have an afternoon to spend finding out. Usually that’s a product manager going into a prioritisation meeting, a competitive-intel or GTM person building a battlecard, or someone who just shipped a release and wants to know what the reviews turned into. The manual route is open to anyone: an app’s reviews are public, you can scroll them on the store page, and for a handful of reviews that is genuinely the right call. It stops being reasonable at a few hundred — you’re reading, tagging in a spreadsheet, and by the time you’re done you’ve built a rough tally by hand, for one app, once. This actor reads the same public reviews and asks an LLM to write the tally for you.

What you’ll need

Nothing but an Apify account. The actor talks to App Store & Google Play directly.

No proxy, no login, no API key of your own — the app-store endpoints are open, and the LLM that writes the teardown is the actor’s, not yours. Its cost is already inside the per-teardown price below, so there’s no second bill to set up. The proxyConfiguration field exists for completeness; you can leave it off.

Step 1 — Open the actor

Open App Review Teardown & Insights (AI) on the Apify Store and press Try for free. The actor’s own page on this site lists its live health and pricing.

The App Review Teardown & Insights (AI) listing on the Apify Store
The listing on the Apify Store. Pricing and the nightly health record are both public.

Step 2 — Fill in the input

The input form for App Review Teardown & Insights (AI) in the Apify Console
The input form, as it appears in the Apify Console.
FieldTypeRequiredWhat it does
appsarrayyesApps to analyze — an app name (e.g. ‘Notion’), an App Store / Google Play URL, an Apple numeric id, or a Google Play package (com.x.y). One competitive teardown per app.…
maxReviewsintegernoReviews sampled per app (most-recent first) and fed to the AI. Caps cost; more reviews = richer teardown. (default 100)
countrystringnoTwo-letter store country code for reviews (e.g. ‘us’, ‘gb’, ‘de’). (default us)
compareAppsbooleannoWhen 2+ apps are given (default on), add a cross-app comparison record — a strengths/weaknesses matrix plus sales battlecards (their weaknesses, where you win, what to watch… (default True)
yourAppstringnoOptional. Name one of the apps as yours, and battlecards are framed as YOUR app vs each competitor. Leave empty for a neutral comparison.
compareToPreviousbooleannoWhen on (default), diff each app against the previous run and report what changed — rating delta, emerging vs resolved complaints, sentiment delta. Run on a schedule to track… (default True)

Two fields decide what you get back. apps is the whole job: one teardown per entry, and the entries can be plain names (Notion), an App Store URL, a bare Apple id, or a Google Play package like com.evernote. A name is resolved by searching the store and taking the top hit, so if the name is ambiguous — half a dozen apps are called “Wallet” — pass the store URL or id instead and remove the guesswork. maxReviews decides how much the AI has to work with: it samples the most-recent reviews up to that cap (10 to 500, default 100). More reviews means a teardown grounded in more of what people wrote; fewer means a thinner one. It is always the most recent slice, never a random or representative sample of the app’s whole review history.

country picks the store front (us, gb, de…), and it matters more than people expect — the reviews on the German store are written by German users about a partly different experience. Leave compareApps and compareToPrevious on unless you want a single, isolated snapshot.

A working input:

{
  "apps": [
    "Notion",
    "Evernote"
  ],
  "yourApp": "Notion",
  "maxReviews": 100,
  "compareToPrevious": true
}

Step 3 — Run it

Press Start. Rows are pushed to the dataset as they’re found, so the run log fills in as it works.

A healthy run produces one record per app in apps, plus one extra (comparison) record when you gave it two or more apps and left compareApps on. So the input above returns three records: Notion, Evernote, and the battlecard that compares them. Most of the wall-clock time is the LLM writing the teardown, not the scraping — the review fetch is a handful of JSON requests.

An empty teardown on a record almost never means the actor broke. It means one of two things: the app reference didn’t resolve to anything on the store (a misspelling, or a name that matched nothing), or it resolved but the store returned no reviews for that country. Those records are still pushed so you can see what happened, and they are not charged.

Step 4 — Read the output

Each run returns a labelled table, not raw JSON:

The output fields returned by App Review Teardown & Insights (AI)
The output view — every field the actor returns, named and typed.

Every row looks like this — a real row from a real run:

{
  "app": "Notion",
  "app_name": "Notion: Notes, Tasks, AI",
  "apple_id": "1232780281",
  "sources": [
    "apple"
  ],
  "overall_rating": 4.78,
  "review_count_analyzed": 100,
  "teardown": {
    "summary": "Notion is praised as a powerful, flexible workspace but is dragged down by mobile bugs, a steep learning curve, and an intrusive AI button.",
    "strengths": [
      "Powerful, flexible all-in-one workspace",
      "Great for notes, tasks, and databases"
    ],
    "weaknesses": [
      "Buggy on iOS/iPad with crashes",
      "Steep learning curve on mobile",
      "Intrusive AI chat button"
    ],
    "top_complaints": [
      "app crashes / bugs",
      "confusing mobile navigation",
      "free-tier upload limits"
    ],
    "feature_requests": [
      "offline mode",
      "remove/hide the AI button",
      "better mobile editor"
    ],
    "themes": [
      {
        "theme": "Bugs and crashes",
        "sentiment": "negative",
        "mentions": 6
      },
      {
        "theme": "Power and flexibility",
        "sentiment": "positive",
        "mentions": 5
      }
    ],
    "sentiment_score": 62
  },
  "first_seen": false,
  "rating_delta": -0.03,
  "emerging_complaints": [
    "app crashes / bugs"
  ],
  "resolved_complaints": [],
  "sentiment_delta": -4,
  "source_url": "https://apps.apple.com/us/app/id1232780281"
}
FieldExample valueMeaning
appNotionThe app reference you supplied
app_nameNotion: Notes, Tasks, AIResolved app name
sources["apple"]Stores that contributed reviews (apple, gplay)
overall_rating4.78Store-reported average rating
review_count_analyzed100Reviews fed to the AI
teardown.summaryOne-paragraph competitive summary
teardown.strengths / weaknessesWhat users love / dislike
teardown.top_complaintsThe most common complaints

The field people come for is teardown — and specifically top_complaints and feature_requests, because those are the two lists you can take straight into a meeting. themes is the same material with a sentiment label and a mention count attached, which is what you want if you’re building a chart rather than a bullet list.

Now the part worth being blunt about: everything under teardown is written by an LLM. It is a synthesis of the reviews the run sampled, not a measurement of them. The model is instructed to base its answer only on the supplied reviews, but a summary still flattens nuance, and a mentions count is the model’s tally, not a verified count of matching strings. Treat the teardown as a fast, cheap read of a review corpus you’d otherwise have to skim yourself — a starting point you can check against the source, not a number to put in a board deck unchecked. The fields either side of it are the factual ones: overall_rating is what the store reports, review_count_analyzed is how many reviews were actually fed in, and source_url is the store page so you can go read them.

A few practical nulls. overall_rating comes from Apple’s lookup, so it’s empty for an app found only on Google Play. sources tells you which stores actually contributed — Apple is the reliable one (the official iTunes feed); Google Play is best-effort and quietly drops out rather than failing the run, so a record with ["apple"] alone is normal. On the first run for an app, first_seen is true and every delta field is null; the deltas only mean something from the second run on.

Step 5 — Export it

Open the Dataset tab and export to CSV, JSON, or Excel — or pull the same rows from the API, which is what you want if this is going to run on a schedule.

Calling it from an agent

The mcp in the name is about how you call it, and it’s worth being precise, because the name promises more than the actor ships. There is no MCP server inside this actor — it is an ordinary Apify Actor. What makes it agent-callable is the platform: Apify exposes Store actors as tools to MCP-aware clients, so an agent can invoke this one, pass an app name, and get the teardown back as structured JSON without a human opening the Console. That’s the real angle, and the reason the output is a typed object rather than a wall of prose: an agent can read top_complaints as a list. If you were expecting a standalone MCP server you can point your own client at, this isn’t that.

What it costs

One AI-insight event per insight produced, at $0.05 each — 20 teardowns is $1.00. An app that can’t be resolved, or that comes back with no reviews, produces no teardown and is not charged. Note that the cross-app (comparison) record is an AI insight too, so the two-app example above bills three events: Notion, Evernote, and the battlecard. The price is per teardown, not per review — a 100-review run and a 500-review run cost the same event. Apify’s own platform usage (compute) is billed separately on your plan, as with every actor.

Where the data comes from

This reads App Store & Google Play directly. The target is App Store / Google Play public JSON endpoints.

Apple’s side is the dependable one: the official iTunes search/lookup endpoints resolve the app, and the customer-reviews RSS feed returns reviews as JSON. The annoyance is that the feed is paginated and capped at roughly ten pages, so “all reviews ever written” is not on the table for anybody, us included — you get a most-recent slice. Google Play has no equivalent official feed; it’s read best-effort through a reverse-engineered endpoint, and if it fails the run continues on Apple alone rather than dying. A nightly canary does check that this actor still runs and still returns the factual fields (app, app_name, source_url) against the live stores, which catches an endpoint that has changed shape — but it cannot check whether the AI’s summary is right, because there’s no fixed correct answer to diff against. See what “verified” means for what that signal does and doesn’t cover.

See it used

AI Teardown of an App’s App Store Reviews is the single-app version — one app in, one teardown out. Find the Top Complaints in an App’s Reviews points it at your own app for prioritisation, and Compare Two Competitor Apps’ Reviews is the two-app battlecard.

Different job entirely, but the same instinct: Shopify Store Intel tears down a competitor’s storefront rather than their reviews — reach for it when the thing you’re sizing up sells online instead of shipping an app.

Last updated 2026-07-13