An app's average rating tells you little about why people leave. Written reviews can reveal a broken login flow, confusing subscription terms or a feature customers keep requesting. A useful research workflow keeps the review text next to its rating, version, date and source, so a product team can check the evidence behind each conclusion.
This guide shows how to collect a small Android and iOS review sample, export it, and normalize the two formats for analysis. The tools below are ours: we build API Vault's Apify Actors. The workflow works with JSON exports and ordinary Python; you do not need a separate AI subscription.
Start with a question and a comparable sample
Pick one app or a short list of competitors. Decide whether you are investigating a recent release, recurring complaints or feature requests. Keep the requested storefront and language consistent where possible, and record the collection date. A storefront selection is not proof of each reviewer's location.
Begin with 100 reviews per app. Collect the available recent feedback before narrowing to one-star reviews: an issue that sounds serious in isolation may appear in only a few records. A sample is evidence about the collected reviews, not a representative survey of all customers.
Export Android reviews from Google Play
Open Google Play Reviews Scraper in Apify. For an initial run, paste this into the JSON input editor:
{ "mode": "reviews", "appInputs": ["com.whatsapp"], "country": "us", "language": "en", "sort": "newest", "maxReviews": 100, "maxResults": 100 }
Replace the example package name with your target app. Set a small run spending limit, start the Actor, and inspect the Dataset. Each delivered review has its own row. Useful fields include reviewId, content, score, at, reviewCreatedVersion and, when available, replyContent and repliedAt.
Export the Dataset as JSON and save it as android.json. CSV and Excel exports are also available. Read the run's SUMMARY and error records before treating the collection as complete. Review pagination follows the source's continuation tokens, but configured limits, source restrictions and failures can stop it early.
Export iOS reviews from the App Store
Open App Store Reviews Scraper and use a numeric app ID or an App Store URL:
{ "appInputs": ["310633997"], "countries": ["us"], "sort": "newest", "maxReviews": 100, "maxResults": 100 }
The examples use the Android and iOS versions of WhatsApp as recognizable inputs, not as a claim that either has a particular product problem. Save the iOS Dataset JSON as ios.json.
The iOS output uses reviewId, rating, title, text, version and updatedAt. Its source is Apple's bounded public RSS window: up to 10 pages of 50 exposed reviews per app, storefront and sort order. Fewer may be available. This product does not provide a complete historical archive or developer replies. Check SUMMARY, COVERAGE and ERRORS in the run's key-value store.
Normalize both exports with Python
The platforms use different field names. This standard-library script creates one CSV without pretending that the source date fields mean exactly the same thing:
import csv import json rows = [] for platform, filename in [("android", "android.json"), ("ios", "ios.json")]: with open(filename, encoding="utf-8") as source: reviews = json.load(source) for review in reviews: android = platform == "android" rows.append({ "platform": platform, "app_id": review.get("appId"), "review_id": review.get("reviewId"), "stars": review.get("score" if android else "rating"), "text": review.get("content" if android else "text"), "version": review.get("reviewCreatedVersion" if android else "version"), "source_date": review.get("at" if android else "updatedAt"), "date_field": "at" if android else "updatedAt", }) if rows: with open("reviews.csv", "w", newline="", encoding="utf-8-sig") as output: writer = csv.DictWriter(output, fieldnames=list(rows[0])) writer.writeheader() writer.writerows(rows) print(f"Exported {len(rows)} review rows")
Open the CSV in your analysis tool. If opening untrusted review text in a spreadsheet, import the text columns as text rather than allowing formula interpretation.
Turn feedback into a research queue
Group reviews into a small, explicit set of themes: login, payments, performance, usability and feature requests. Keep an unclassified bucket. If you use an LLM to suggest labels, ask it to retain the review IDs and verify a sample yourself; a generated label is not an established fact.
For each theme, record the count in your collected sample, the affected versions when present, and a few review IDs for inspection. Separate Android and iOS before comparing them. Different source windows and collection times make raw cross-platform counts misleading.
For repeat collection, save app ID, platform and review ID, with storefront where relevant. Update changed records rather than counting every scheduled export as entirely new feedback. Scheduling is available through Apify; the persistent comparison database is something you supply.
Costs and a sensible first run
As checked on 23 October 2026, both Actors list review-event fees of $0.02 per 1,000 useful delivered reviews, plus Apify platform resources. That is $0.002 in review events for 100 delivered rows from one Actor, not a quote for the whole run. Check the current Pricing tab before scaling. An Apify account is required; no Google or Apple login is needed for these public review sources.
Start with 100 Google Play reviews and 100 App Store reviews. Check relevance and coverage, then expand only the apps, storefronts and dates that answer your research question.