SerpApi, the Austin, Texas search data company, published a guide on October 16, 2026 that strings together two of its own APIs and two open-source language models to pull App Store reviews of competing apps, keep only the negative ones and sort them into seven complaint categories. In the guide's sample run for the search term "to do list," incompleteness accounted for 38.16% of classified complaints and advertising for 1.67%. The guide does not say how many apps or reviews produced those figures, and its text describes a sorting step that its code no longer performs.

In Short

A company that sells search data wrote instructions for a small program that reads what people say about rival apps in Apple's App Store and counts which complaints come up most. In its example for to-do list apps, the biggest complaint was that apps were missing things, and the smallest was too many ads. The numbers are a demonstration of the method, not a survey, and the instructions contain a few errors, including one step the text promises but the code does not do.

What the guide covers

The post, titled "How to analyze App Store reviews for your competitors' apps," sits in the App Store Optimization section of SerpApi's blog and carries the bylines of Emirhan Akdeniz and Corbin Davenport, with a listed reading time of 10 minutes. Its subtitle summarizes the approach: "You can use local language models and SerpApi to read reviews in the Apple App Store, and categorize them for easy analysis."

According to SerpApi, the motivation is competitive. "When building your own mobile application, understanding the frequent complaints and problems in competitors' offerings can be invaluable," the guide states. It positions the Apple App Store Search API and the Apple App Store Reviews API as app store optimization tools and claims that, combined with natural language models, "it's easy to analyze user reviews and general information for other apps."

The article is not new in substance. Akdeniz published an earlier version on behalf of SerpApi on January 23, 2023, under the title "Analyzing the distribution of problems in competition reviews." That version used the same two models, the same seven complaint labels and the same four-stage structure. What changed in the October 2026 edition is the search term in the worked example, which moved from "Coffee" to "to do list," a rewritten question-answering function, step-by-step setup instructions for Mac and Windows, and the removal of one URL parameter that the surrounding text still describes.

Four stages, two APIs, two models

The script runs in a single Python file. SerpApi lists four third-party libraries in its setup text: transformers, torch, python-dotenv and requests. The models download from Hugging Face the first time the script runs, which, according to the guide, makes the first run "take the longest."

Stage one: collecting app IDs

The first function calls SerpApi's search endpoint with engine=apple_app_store and a search term, then pulls the id field from every entry in the organic_results array. The output is a flat list of App Store product IDs for apps that rank for that term.

SerpApi describes its Apple App Store Search Scraper API as "a tool used for gathering in-depth metrics, keyword rankings, the number of app downloads, and many more details of an app in the iOS App Store, or Mac App Store." It adds that the tool "gives you good insight into how the App Store's ranking algorithm works." The guide does not identify which response field carries download numbers, and the script itself uses only the app ID.

Stage two: collecting reviews

For each ID, a second function calls the endpoint again with engine=apple_reviews and extracts the text field from each review. A third function runs those calls through asyncio.gather and merges every list into one pool.

The guide flags a design choice in that pool. "Notice that it doesn't store which reviews belong to which app name," the post states. The analysis therefore describes complaints across the top-ranking apps for a keyword collectively, not for any single competitor.

Stage three: filtering for negative reviews

The filtering step uses facebook/bart-large-mnli, a model run through the transformers zero-shot classification pipeline, with two candidate labels: "negative" and "positive." Each review gets whichever label scores higher, and only those labelled negative continue. SerpApi calls these "absolutely negative reviews."

The reasoning, according to the guide, is that star ratings are an unreliable filter. "Sometimes, an app could have a little number of reviews, or a user might give a 1-star but a positive review," it states. Classifying the text itself, rather than the rating, is meant to surface "genuine negative reviews of your competition." The approach is a form of sentiment labelling, though the script never reads the star rating that the guide cites as the problem.

Stage four: extracting and classifying the complaint

Each negative review then goes to bert-large-uncased-whole-word-masking-finetuned-squad, a question-answering model, with the fixed question "What is the problem?" The function feeds the question and review into the tokenizer with a 512-token limit, truncating only the review, and selects the span of the review with the highest start and end scores. The result is a phrase lifted from the review, not generated text.

SerpApi explains the purpose with an example review: "Screenshots are nice. But they don't represent the app." According to the guide, the goal is to isolate "the concern for the honesty of the developer from this review which is the latter sentence."

Those extracted phrases then go back through the BART classifier, this time against seven preset labels: bugs, too many advertisements, inefficiency, dishonesty, unenjoyable, incompleteness and expensiveness. The script counts how often each label wins and divides by the total to produce a percentage distribution, sorted from most to least frequent.

Both models are small by current standards and run locally, so classification and extraction involve no paid model calls; only the SerpApi requests count against an account. The guide calls them "local language models," a description that places them well below the scale of the LLM systems that dominate current AI coverage. Every review passes through BART at least once, and every negative review passes through BERT and then BART again, so inference time on an ordinary laptop scales with the size of the review pool.

The sample output

According to SerpApi, running the script for "to do list" produced this distribution:

  • incompleteness: 38.16%
  • unenjoyable: 22.49%
  • expensiveness: 19.98%
  • inefficiency: 8.73%
  • dishonesty: 5.62%
  • bugs: 3.35%
  • too many advertisements: 1.67%

The seven figures sum to exactly 100%. The guide provides no count of apps returned by the search, reviews collected, reviews classified as negative, or the date the run took place. Without those denominators, there is no way to judge whether 38.16% represents dozens of complaints or thousands, and no basis for treating the output as a measurement of the to-do app category.

The 2023 version offers a point of comparison. Its "Coffee" run ranked unenjoyable first at 29.28%, incompleteness second at 27.03% and expensiveness third at 12.61%, with too many advertisements at 8.11% and bugs at 5.86%. Different search terms, different years and an undisclosed sample size make any comparison between the two runs illustrative only. Both runs did, however, put the same three labels in the top three.

The labels themselves are fixed by the person running the script. Zero-shot classification assigns each phrase to whichever preset label fits best, so a complaint that matches none of them still lands in one. Bugs at 3.35% may reflect few bug complaints, or it may reflect how BART weighs the word "bugs" against "inefficiency" and "incompleteness" for a phrase such as "it keeps crashing." The guide does not address that overlap.

Where the guide contradicts itself

Several passages in the October 16 guide do not match the code or the instructions printed alongside them.

Review sorting. After the review-collection function, the guide says it "returns a list of reviews for that app, sorted from most negative to least negative with the help of sort=mostcritical parameter." The code comment in the full script repeats that claim: "Collect reviews of an individual app from most negative to least negative." Neither the snippet nor the full script includes sort=mostcritical in the request URL. The 2023 version of the same script did include it. As printed, the request falls back to whatever default order the reviews engine applies, and because the script reads only one response per app with no pagination, the sort order determines which reviews enter the analysis at all.

Dependencies. The setup text says to "install the transformers, torch, python-dotenv, and requests Python libraries." The command printed directly beneath it is pip install transformers requests python-dotenv, which leaves out torch. The script imports torch directly and calls torch.no_grad() in the extraction step.

Wrong store. The SerpApi account section states: "You need a free SerpApi account before you can use the Google Play Store APIs." The guide does not use any Google Play API. Every request goes to the Apple engines.

File name. The guide tells readers to create a script "called main.py," then gives python ./script.py as the command to run it.

Pipeline wording. The text describes using "a question-answering pipeline to summarize the reviews." The 2026 code does not use the transformers pipeline for this step; it loads the tokenizer and model separately and selects the answer span by hand. The output is an extracted phrase rather than a summary in the usual sense.

Concurrency. The review functions are declared with async and gathered concurrently, but each one calls the synchronous requests.get. In Python, that blocks the event loop, so the requests run one after another rather than in parallel. The script still works; it simply does not gain the speed that the asynchronous structure suggests. This last point is PPC Land's reading of the code rather than something the guide states.

Cost and limits

SerpApi's page advertises a free plan of 250 searches a month. One run of the script uses one search request for the App Store query plus one reviews request per returned app, so the number of apps in organic_results sets the cost. The guide does not say how many apps a typical search returns.

That budget arithmetic is familiar from SerpApi's other recent tooling. On October 8, the company released an open-source Review Audit tool that, as PPC Land reported, reads the 200 newest Google Maps reviews of a place for roughly 42 credits, enough for about five places on the free plan. That tool relied on statistical pattern checks rather than language models. The App Store guide goes the other way, handing the judgment entirely to two pretrained classifiers with no published accuracy figures for this task.

Key handling follows a standard pattern. The guide stores the API key in a .env file and warns: "Make sure to not share your .env file with anyone! If the key is leaked or stolen, you can make a new one from the SerpApi account dashboard." The script then passes the key as a query-string parameter in every request URL. Exposed keys have caused trouble elsewhere this year; in February, researchers found thousands of public Google API keys that had quietly gained access to Gemini.

What SerpApi says the data is for

The final section turns the to-do output into product suggestions. According to SerpApi, "the top problems among the competition's negative reviews for the search term 'to do list' are incompleteness, unenjoyable, and expensiveness." For incompleteness, the guide proposes identifying missing features through "market research, surveying customers, localization demands, notifications for bugs or gathering data on the features of competitors' apps." For unenjoyable experiences, it proposes gathering customer feedback. For expensiveness, it suggests studying competitor pricing and adding "in-app purchase options or subscription models."

The conclusion frames the exercise in ranking terms. "Outranking the competition in the search results requires gathering and analyzing customer feedback, understanding the competition, and implementing solutions to address the identified problems," the guide states. Elsewhere, it claims that understanding the ratio of problems in competitors' reviews "is a crucial part of mechanics in app ranking, user acquisition, and overall store intelligence." The guide offers no evidence connecting review complaint distributions to App Store ranking positions.

Why this matters for app marketers

App Store search is where much of iOS acquisition happens, and it has become more contested. Apple has said nearly 65% of App Store downloads follow a search, a figure it cited when it disclosed plans to add more ad positions to App Store search results in December 2025. Those extra placements began rolling out on March 3, 2026, starting in the UK and Japan, and advertisers cannot choose or bid on specific positions. More paid slots above organic listings raise the value of anything that improves conversion on the product page itself.

Apple has also given developers more ways to change that page. At WWDC26 in June, it added Creative Assets that can appear in a product page's header and in search results, and developers can submit them for review without shipping an app update. In August, Apple released the Apple Ads Platform API, with the older Campaign Management API scheduled to shut down on January 26, 2027. Review mining of the kind SerpApi describes sits upstream of both: it feeds decisions about which features to highlight, which complaints to address in screenshots, and which keywords competitors are weak on.

The guide is also a reminder of where SerpApi's business sits. The company's core product is search results collected through web scraping, and Google sued it under the DMCA in December 2025. A judge dismissed that complaint in July 2026 with partial leave to amend, Google refiled, and SerpApi moved in August to dismiss the amended complaint. The App Store engines are not part of that litigation. Still, the company has been widening its catalogue beyond Google, and three days before this guide it released the Extract API, which fetches and crawls arbitrary public web pages for 250 free credits a month. Publishing how-to material built on its Apple engines fits that same direction.

What the guide does not provide is any validation. There is no hand-labelled sample showing how often BART's negative or positive call agrees with a human reader, no check on whether BERT's extracted span captures the actual complaint, and no test of how stable the seven-way distribution is from one run to the next. A marketer reading 38.16% against 1.67% has a ranking produced by two models, seven chosen words and an unknown number of reviews, drawn in an order the text describes but the code does not request.

Timeline

Summary

Who: SerpApi, LLC, an Austin, Texas search data API company, through a blog post by Emirhan Akdeniz and Corbin Davenport. The analysis targets developers and marketers of iOS and Mac apps, and the reviews it reads come from users of competing apps in Apple's App Store.

What: A Python guide that queries SerpApi's Apple App Store search and reviews engines, filters reviews to negative ones with the facebook/bart-large-mnli model, extracts each complaint with a BERT question-answering model, and classifies the complaints into seven preset labels. Its sample run for "to do list" put incompleteness at 38.16% and too many advertisements at 1.67%, with no sample size given. The text describes a sort=mostcritical parameter that the code omits, lists torch as a dependency the install command leaves out, refers to Google Play APIs it never uses, and names the script main.py before running script.py.

When: Published October 16, 2026, as a reworked version of a January 23, 2023 post that used the same models and labels.

Where: SerpApi's blog, in its App Store Optimization section. The models run locally on the user's machine, while app and review data come from SerpApi's endpoint, available on a free plan of 250 searches a month.

Why: SerpApi presents complaint distributions in competitors' reviews as an input for feature, pricing and app store optimization decisions. The guide arrives as Apple adds paid placements to App Store search and new product-page tools, which raises the stakes on organic conversion, and as SerpApi widens its product line beyond the Google search data at the centre of its legal dispute with Google.