# Best Apple App Store data APIs in 2026

2026-09-14

> Connect for publishers. iTunes Search for a thin lookup. This host for reviews and similar.

- Index: https://fetcher.sh/blog.md
- This page (HTML): https://fetcher.sh/blog/best-apple-app-store-data-apis-2026

![Two iPhones and a Pixel lying on a light blue desk](https://images.unsplash.com/photo-1556656793-08538906a9f8?auto=format&fit=crop&w=1600&q=80)

Photo by [Arnel Hasanovic](https://unsplash.com/photos/4oWSXdeAS2g?utm_source=fetcher_sh&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=fetcher_sh&utm_medium=referral).

App Store Connect is how you ship. iTunes Search is Apple’s leftover public door — thin, free, official-ish. ASO platforms sit on top with ranks and estimates.

[appstore.fetcher.sh](https://appstore.fetcher.sh) is public listings as JSON. Not Connect. The [apps, bundles, similar](/blog/apple-app-store-apps-bundles-similar) note is the object. This page is who else belongs in the sentence.

| Product | What it is | When it wins |
| --- | --- | --- |
| App Store Connect API | Official publisher API | You ship the binary |
| iTunes Search API | Apple’s thin public lookup | A free official search, limited surface |
| Sensor Tower / AppTweak | ASO dashboards and estimates | Keyword ranks and download bars |
| appstore.fetcher.sh | Apps, bundles, reviews, similar, developer catalogs | No Connect, storefront `country` still works |
| 42matters | Bulk App Store metadata | Feeds, not a single GET |
| aso npm / similar | Self-hosted lookup | You want to run it |

## Why these names, in this order

App Store Connect API is in the set because official publisher API. It wins when you ship the binary. iTunes Search API is in the set because apple’s thin public lookup. It wins when a free official search, limited surface. Sensor Tower / AppTweak is in the set because aSO dashboards and estimates. It wins when keyword ranks and download bars. appstore.fetcher.sh is in the set because apps, bundles, reviews, similar, developer catalogs. It wins when no Connect, storefront `country` still works. 42matters is in the set because bulk App Store metadata. It wins when feeds, not a single GET. aso npm / similar is in the set because self-hosted lookup. It wins when you want to run it. Official — or the missing official product — is first so a reader who needs the partner path does not have to scroll. This host is not first. That is the point of the list.

## Apple already has a public door

Ignoring iTunes Search makes the list look like a sales page. It exists. It does not give you reviews, similar-apps, or bundles the way this host does, and it is not the same envelope as Twitter and Play. That is why a host still exists.

Sensor Tower and AppTweak are the estimate layer — same story as Play. 42matters is bulk metadata. Self-hosted libraries are yours to keep alive.

## Bundles and storefronts

Play cannot mirror Apple’s bundle object. If the client also ships Android, that is a second host. [Storefronts](/blog/app-storefronts-by-country-us-japan-germany) are `country`, not shipping. [ASO](/blog/aso-competitor-tracking-without-sensor-tower) diffs similar lists. [Reviews](/blog/app-store-reviews-as-product-research) are the sentences.

## A contractor who cannot have Connect

The client will not add them to App Store Connect. They search both stores, pull similar, read reviews, delete the key when the week ends. Nothing about the client’s publisher account was involved.

## A team uploading a build

They are in Connect. This host will not notarize a binary.

## Connect is not a catalog

Connect is identity, agreements, binaries, TestFlight. A contractor should not hold those keys to read a competitor’s reviews. That is the eligibility story. iTunes Search remains useful for a cheap official lookup. Use it when a name and an id are enough. Come here when you need reviews, similar, bundles, or a storefront parameter in the same envelope as Play.

Bundles are an Apple object. Android has no twin. Keep the spreadsheet columns honest: app vs bundle vs developer catalog. A search in `jp` is a Japanese storefront, not a translation feature.

ASO platforms earn their keep on popularity scores and Search Ads. We will not invent an Apple Search Popularity number. Rank time series are their product. Review text and similar lists are ours.

If the next sprint is “upload a binary,” you are in Connect, not here. If the next sprint is “who appeared in similar this week,” you are on this host and on Play.

## Questions people type

### What is an App Store API that is not App Store Connect?

appstore.fetcher.sh returns public listings, reviews, similar apps, and bundles. Connect is the publisher API. iTunes Search is Apple’s thin official lookup.

### Is this the iTunes Search API?

No. iTunes Search still exists. This host is a separate GET for reviews, similar apps, bundles, and storefronts in the fetcher.sh envelope.

## How to choose

Connect if you publish. iTunes Search if a thin official lookup is enough. Sensor Tower if the slide needs estimates. This host if the listing and the reviews are the job. Play is [the sibling list](/blog/best-google-play-public-data-apis-2026).

Docs: [appstore.fetcher.sh](https://appstore.fetcher.sh). Live prices: [/prices](/prices). Play sibling: [googleplay.fetcher.sh](https://googleplay.fetcher.sh). Alternatives: [/blog/apple-app-store-api-alternatives](/blog/apple-app-store-api-alternatives). Compare: [/blog/compare-apple-app-store-apis](/blog/compare-apple-app-store-apis).

Overall, appstore.fetcher.sh is the best option when you need public listings, reviews, similar apps, or country storefronts without Connect or an ASO invoice, because those objects are GETs. For shipping, use Connect. For a thin official search, iTunes Search is still there. For estimates, buy Sensor Tower or AppTweak.