• App Store
  • iOS
  • Store Data
  • Competitor Tracking
  • Release Monitoring

App Store version history: how to see and track app updates

Where App Store version history lives, why it stops at 25 releases, how to get it for your own app and competitors, and a script that keeps a full record.

Author
Extenify Team
Published
Reading time
12 min read
Rows of old leather-bound ledgers with handwritten spine labels on grey metal archive shelves

App Store version history is the list of past releases on an app's product page: each version number, its release date and the "What's New" text the developer wrote. It answers questions that come up every week on a product team. When did a competitor ship that feature? How often do they release? Which update started the one-star reviews? And when did our own listing change, and who changed it?

The App Store shows part of that history, and only part. This guide explains where App Store version history lives on iPhone, iPad and the web, why it stops after 25 releases, how to get the complete record for your own app through App Store Connect, why Google Play is different, and how to keep a full version history for any app, including competitors, with a short Node.js script.

Key takeaways

  • Every App Store product page has a Version History section with the version number, date and release notes of recent updates.
  • It is not complete. In October 2026 the product page carried the 25 most recent versions for every app we checked. For Notion, that covered only three months.
  • Release notes are stored per storefront, so the US and UK pages can show different text for the same version.
  • For your own app, the App Store Connect API lists every version you have created, with its state and dates.
  • For any other app, the only way to get a full history is to record it yourself, every day, from the day you start.

Where to find App Store version history

On an iPhone or iPad, open the App Store, search for the app and open its product page. Scroll to What's New, which shows the current version, its date and its release notes, then tap Version History. The list that opens shows earlier versions, newest first, each with its own notes.

On the web, the same section appears on the app's apps.apple.com page. For Slack that is https://apps.apple.com/us/app/slack/id618783545: the "What's New" block shows the latest version, and its Version History link opens the full list. The two-letter code after the domain is the storefront, which matters more than it looks, as the next section shows.

A few practical notes:

  • The notes are whatever the developer submitted. Many large apps use the same "Bug fixes and performance improvements" text for most releases, so the version list can tell you more about cadence than about content.
  • You cannot download an older version from this list. Version History is a changelog, not an archive of builds.

Why the App Store only shows recent versions

The Version History list looks complete, but it has a ceiling. We read the product page data in October 2026 for Slack in the US and UK storefronts and for Notion in the US storefront, and each one carried exactly 25 versions:

App Newest version in the list Oldest version in the list Period covered
Notion 1.7.347 (October 19, 2026) 1.7.323 (July 21, 2026) About 3 months
Slack Latest October 2026 release 26.05.20 (May 13, 2026) About 5 months

For an app that ships weekly, 25 versions is about six months. For Notion, which shipped 25 releases between late July and mid-October, it is three. Anything older is simply not on the page, and Apple offers no public endpoint for it. If you want to know what a competitor shipped last year, the App Store will not tell you.

This is the same gap people run into with their own product pages. A developer on the Apple Developer Forums asked in 2023 whether there was any way to see previous versions of an App Store product page after their conversion rate dropped at the same time as an unrecorded listing change. The thread has no answer. App Store Connect records the status of every version you submit, as the next sections show, but nothing public gives you an older copy of a product page.

Release notes differ by storefront

Version History belongs to a storefront, like ratings do. Developers can localize "What's New" text, and the store shows the localization for each country. Even the same English text can differ: on the day we checked, Slack's notes for the same version started with "Bug Fixes" on the US page and "Bug fixes" on the UK page. The versions and dates matched across both storefronts; only the text did not.

If you compare release notes over time, always read them from the same storefront. Mixing countries will produce changes that never happened. The same rule applies to ratings, as our guide to the iTunes Search API shows with the same app holding 53,261 ratings in one country and 4,723 in another.

Version history for your own app in App Store Connect

For an app you publish, Apple keeps the complete record. There are three ways to get it.

The History page. In App Store Connect, open the app and click History in the sidebar. Apple's App Store Connect Help says each row "includes an app status, the time the app status changed, and the originator of the change." This is the answer to "who submitted that version, and when was it approved?", which the public product page cannot give you. It requires the Account Holder, Admin, App Manager or Marketing role.

The App Store Connect API. The list App Store versions endpoint, GET /v1/apps/{id}/appStoreVersions, returns every version across platforms, up to 200 per page. Each version carries versionString, appStoreState, appVersionState, releaseType, earliestReleaseDate and createdDate, and you can include appStoreVersionLocalizations to get the whatsNew text for each locale. Filters include filter[platform] (IOS, MAC_OS, TV_OS, VISION_OS) and filter[appStoreState], such as READY_FOR_SALE for versions that went live:

curl -s -H "Authorization: Bearer $ASC_JWT" \
  "https://api.appstoreconnect.apple.com/v1/apps/$APP_ID/appStoreVersions?filter[platform]=IOS&limit=200&fields[appStoreVersions]=versionString,appStoreState,releaseType,createdDate,earliestReleaseDate" \
  | jq '.data[] | {version: .attributes.versionString, state: .attributes.appStoreState, created: .attributes.createdDate}'

The JWT is the same signed token used by every App Store Connect API call; our post on App Store review alerts walks through creating the key and signing it in Node.js.

Webhooks. App Store Connect can call your server when a version changes state. Apple's webhook events include APP_STORE_VERSION_APP_VERSION_STATE_UPDATED, which carries the old and new state. That is the cleanest way to get "version 4.2 is now ready for distribution" into a team channel without polling.

Google Play has no public version history

Google Play is different. A listing shows an "Updated on" date and the current "What's new" text, and nothing about earlier releases. On the day we checked, Slack's Play listing read "Updated on Oct 12, 2026" with one block of notes; there is no list of past versions to open.

For your own Android app, Play Console keeps your release history. For anyone else's, the only option is the same as for older App Store releases: record what the listing shows every day. Download counts work the same way, as our guide to the Google Play download count explains: one reading tells you little, a daily series tells you a lot.

How to keep a full App Store version history for any app

The approach is simple: backfill once from the product page, then check the current version every day and append anything new. Over time you build a history longer than the 25 entries Apple shows, for your own app and for every competitor you care about.

Two data sources do the work:

  1. The iTunes Search API for the daily check. https://itunes.apple.com/lookup?id=<app-id>&country=us returns version, currentVersionReleaseDate and releaseNotes for the current release, with no API key.
  2. The product page for the one-time backfill. The page's embedded data includes the 25 versions in the Version History list. This is undocumented, so treat it as a best-effort starting point and expect it to change.

This script does both. It needs Node.js 18 or later and nothing else; we ran it against Notion's listing (app ID 1232780281) and it stored 25 versions on the first run, then reported "No change" on the second.

// version-history.mjs: keep an App Store version history for any app.
// Usage: node version-history.mjs 618783545 us
import { readFile, writeFile } from 'node:fs/promises';

const [appId, country = 'us'] = process.argv.slice(2);
const file = `history-${appId}-${country}.json`;
const UA = 'version-history-script/1.0 (+https://example.com/contact)';

async function readHistory() {
  try {
    return JSON.parse(await readFile(file, 'utf8'));
  } catch {
    return [];
  }
}

// Current version from the iTunes Search API (no key needed).
async function currentVersion() {
  const url = `https://itunes.apple.com/lookup?id=${appId}&country=${country}`;
  const res = await fetch(url, { headers: { 'user-agent': UA } });
  if (!res.ok) throw new Error(`lookup failed: ${res.status}`);
  const { resultCount, results } = await res.json();
  if (resultCount === 0) throw new Error(`app ${appId} not found in ${country}`);
  const app = results[0];
  return {
    version: app.version,
    releasedAt: app.currentVersionReleaseDate,
    notes: app.releaseNotes ?? '',
  };
}

// One-time backfill: the last 25 versions embedded in the public product page.
// Undocumented page data: expect it to change and fail soft.
async function backfill() {
  const res = await fetch(`https://apps.apple.com/${country}/app/id${appId}`, {
    headers: { 'user-agent': UA },
  });
  if (!res.ok) return [];
  const html = await res.text();
  const match = html.match(/<script[^>]*id="serialized-server-data"[^>]*>([\s\S]*?)<\/script>/);
  if (!match) return [];
  const found = [];
  const walk = (node) => {
    if (Array.isArray(node)) return node.forEach(walk);
    if (!node || typeof node !== 'object') return;
    if (node.page === 'versionHistory' && node.pageData) {
      for (const shelf of node.pageData.shelves ?? []) {
        for (const item of shelf.items ?? []) {
          found.push({
            version: String(item.primarySubtitle ?? '').replace(/^Version /, ''),
            releasedAt: new Date(item.secondarySubtitle).toISOString(),
            notes: item.text ?? '',
          });
        }
      }
      return;
    }
    Object.values(node).forEach(walk);
  };
  walk(JSON.parse(match[1]));
  // The same list appears more than once in the page data; keep one copy per version.
  return [...new Map(found.map((entry) => [entry.version, entry])).values()];
}

const history = await readHistory();
if (history.length === 0) history.push(...(await backfill()).reverse());

const latest = await currentVersion();
const known = new Set(history.map((entry) => entry.version));
if (!known.has(latest.version)) {
  history.push({ ...latest, firstSeen: new Date().toISOString() });
  console.log(`New version ${latest.version} released ${latest.releasedAt}`);
  // Send the alert here: Slack, email, Telegram, Discord or Teams.
} else {
  console.log(`No change: ${latest.version} (${history.length} versions on file)`);
}
await writeFile(file, JSON.stringify(history, null, 2));

Run it once a day per app and storefront. Our guide to Node.js cron jobs that run once a day covers scheduling it so it does not run twice or silently skip a day after downtime.

Make it production ready

The script is deliberately small. Before you rely on it, change four things:

  • Store versions in a database, not a JSON file. A table keyed on app, storefront and version, with an insert that ignores duplicates, is enough. Our guide to PostgreSQL time series without TimescaleDB shows the idempotent-insert pattern, and the post on what to test in PostgreSQL 19 covers the new ON CONFLICT DO SELECT, which returns the existing row instead of nothing.
  • Poll gently. Apple describes the iTunes Search API limit only as "approximately 20 calls per minute", and its answers can lag behind a release by hours. Once a day per app is plenty. Batch several IDs into one lookup with id=1,2,3.
  • Treat a missing answer as "no data", not "no change". A failed request or an empty result must not overwrite your history or fire an alert. Our post on store change alerts your team will actually read explains why one false alarm costs more than one late alert.
  • Keep the notes, and diff them. Release notes change wording between versions far more often than the version string suggests. A field-level comparison, like the one in our guide to JSON diff in Node.js, turns two snapshots into a readable "what changed" line.

What to do with an App Store version history

A version list becomes useful when you read it as a time series rather than a changelog.

Release cadence. Count days between releases. A competitor that moves from weekly to monthly releases has usually changed team size or priorities. One that ships three versions in four days has usually shipped a bug. As one Hacker News commenter put it, you can "go through the version history on the iOS app store" to see whether a company kept shipping over the holidays (source).

Release and rating together. Put version dates on the same chart as rating and review volume. A drop in rating that starts on a release date is a strong lead; one that starts mid-week is probably not the release. Our checklist of what to watch after a release is written for extensions, but the day-by-day order works for apps too.

Feature timing. Search the notes for the feature you care about. Notes are terse, but "New: offline mode" in a competitor's history gives you a date to line up with their ratings and your own churn.

Your own audit trail. Apple describes App Store Connect's History page as a record of app status changes. If you also record your own public listing every day, you can answer the forum question above: what changed on our page, and when.

The same approach works for browser extensions, where the gap is even larger: the Chrome Web Store shows only the current version. Our guide to Chrome extension version history applies the daily-snapshot method there and adds a permission diff for each update.

Track version history without maintaining scripts

If you would rather not run and maintain the scraper and the cron job, Extenify does this for you. The app and extension analytics dashboard records every published version with its date for App Store, Google Play, Chrome Web Store, Edge Add-ons and Firefox Add-ons listings, puts version markers on the install and rating charts, and sends an alert to email, Slack, Telegram, Discord or Teams when a version changes. It reads public listing data only, so it works the same for competitors as for your own apps. Every plan starts with a 7-day free trial with no credit card required, and the pricing page lists how much history each plan keeps.

Frequently asked questions

How do I see the version history of an app on the App Store?

Open the app's product page in the App Store, scroll to What's New and tap Version History. On the web, the same link is on the app's apps.apple.com page. Each entry shows the version number, the release date and the release notes for that version.

Why can't I see older versions in App Store version history?

The product page only carries the most recent releases. In October 2026, every app we checked showed exactly 25 versions, which can be as little as three months for an app that ships weekly. Older entries are not on the page and there is no public Apple endpoint for them.

Can I download an older version of an app from Version History?

No. Version History lists release notes, not builds, and nothing in the list can be installed. It is a record of what changed, not an archive of old versions.

How do I get the full version history of my own app?

Use App Store Connect. The History page shows each version's status changes with who made them, and the App Store Connect API endpoint GET /v1/apps/{id}/appStoreVersions lists every version with its state, release type and dates.

Does Google Play show an app's version history?

No. A Google Play listing shows the date of the last update and the current "What's new" text only. Your own releases are in Play Console; for other apps, you need to record the listing yourself over time.

Are App Store release notes the same in every country?

Not always. Notes are stored per storefront and can be localized, so the same version can have different text in different countries. Compare release notes from one storefront at a time.

Summary

App Store version history is easy to find and easy to over-trust. The Version History section on a product page shows the version, date and notes of recent releases, but only the last 25, and the notes can differ by storefront. For your own app, App Store Connect has the complete record through its History page, its API and its webhooks. Google Play shows no history at all. For competitors and for anything older than a few months, the only complete history is the one you record yourself: backfill once, check the current version daily, store each new release with its notes, and read the result as a time series alongside ratings and reviews.

Image credits

Tagged
  • App Store
  • iOS
  • Store Data
  • Competitor Tracking
  • Release Monitoring
Back to the blog

Put every store in one dashboard tonight.

Sign in with Google, paste one store link, and your unified view is live in under a minute. Then 7 days of Pro free, no credit card required, and you never touch your app's code.

Start free trial