Old apps do not rank higher. Apps that started accumulating earlier do.

I shipped my first app on iPhone OS 2. The App Store had opened a few weeks earlier with around 500 apps in it, and you could scroll the entire thing in an afternoon.

Ever since, I have carried the suspicion that apps with a long history hold something a new app cannot buy at any price. Not nostalgia, an actual mechanical advantage. I finally went and checked, because if it is true it changes the advice I give every client who wants to spend four months polishing before a single person sees anything.

It is true. The reason is not the one I assumed for years, and the real reason turns out to be a much better argument for shipping early than the one I had been making.

App age is not a ranking factor

Start with the part that kills the lazy version of my theory. Neither store has an age input.

Apple describes its own search ranking like this: "Search results are based on a number of factors, including text relevance (matches for your app's title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more)." No release date anywhere in that sentence.

App Radar's 2026 breakdown lists sixteen ranking factors across both stores and app age is not one of them. AppTweak's Google Play list does not carry it either. What both say, in nearly the same words, is that the stores care about installs per day far more than installs to date. An app taking 500 fresh installs a day outranks an older app with a bigger lifetime total and no momentum. Review velocity works the same way: 4.2 stars with a hundred fresh reviews a week typically sits above 4.5 stars with five.

Apple also deletes old apps on purpose. The App Store Improvements process has removed roughly 2.8 million of them. The trigger is not being old, it is being old and inert. No update in three years, combined with a download count near zero over a rolling twelve months, gets you an email and 90 days to do something about it.

So a 2012 app sitting untouched has no protection whatsoever. Seniority on its own buys nothing.

What compounds is not age, it is accumulation

Here is the distinction it took me a while to see. The stores rank on behaviour, and behaviour accumulates. Age is just the container the accumulation happens in.

An old app that kept shipping is not winning because it is old. It is winning because it has had more calendar months to build four specific assets, and there is no way to compress those months. You cannot buy them, borrow them, or engineer around them. They arrive at one month per month, and the meter starts on the day you release.

1. Ratings stopped resetting in 2017

This is a genuine before-and-after in App Store history, and most people who started after it happened have no idea it happened.

Before iOS 11, your star rating reset with every version. Ship an update, go back to zero, start collecting again. Every single release turned you back into a new app in the one number buyers actually look at. Developers used to delay updates specifically to protect it.

Since iOS 11, ratings carry across versions by default. Apple kept a reset button and made it deliberately awkward: you can only use it when releasing a new version, you cannot restore the previous rating afterwards, and it does not touch the written reviews, which stay on your page either way.

Read that for what it is. Since 2017 the rating count has been a one-way ratchet with no decay. A rating you earn this week still counts in 2034. An app that shipped in 2018 has been accruing for eight years without interruption. A new app has zero, and there is no cheque you can write for the number.

It matters because rating count is what converts. AppsFlyer puts the move from three stars to four at up to an 89% increase in conversion rate. Apps sitting under 4.0 convert 30 to 40% worse than apps at 4.5 and above. And volume settles the choice between two good apps, because people pick 4.5 stars with several hundred ratings over 5.0 stars with two, every time.

Now close the loop: conversion rate is itself a ranking factor in both stores. So what buyers do with your rating count feeds directly back into where you rank, which decides how many buyers see you, which decides how fast the count grows.

A new app is not locked out of that loop because the algorithm is unfair to it. It is locked out because the numerator is empty, and the only thing that fills it is time spent live.

2. Apple wrote the head start into the rules

Guideline 4.3(b), verbatim: "Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience."

Read who that protects. Every dating app, flashlight, wallpaper app and simple timer already on the store got in before that sentence applied to anybody. They are not required to be meaningfully different from anything. They are the thing you now have to be meaningfully different from.

The list grows. Guideline 4.3(b) now catches generic AI chat, AI image and AI summariser apps, which were perfectly shippable in 2024 and are a rejection today. Guideline 4.3 is reported as the single most common rejection reason on the store, around 28% of them.

The purest version of this lives on the Mac App Store, where apps that were already in the store before sandboxing became mandatory are simply exempt from it. Same store, same year, two different rulebooks, and the only thing separating them is a ship date.

None of this is Apple deliberately favouring incumbents. The rule is quality control and it does real work. But a rule that asks whether you are meaningfully different from what already exists has its difficulty set by everyone who shipped before you, and that set only ever grows.

3. The queue behind you gets longer every quarter

When I shipped my first app there were about 500 apps to be different from. On the day I am writing this, 42matters counts 2,560,201 apps on the App Store.

The flow rate matters more than the total. Apple took 557,000 new apps in 2025, up 24% on 2024 and the first meaningful increase since 2016. Then 2026 went vertical. Nearly 560,000 new apps arrived in the first half of the year alone, roughly matching the whole of 2025 in six months, with iOS releases up 80% year over year in the first quarter. The store is on pace to beat its all-time record of about a million new apps, set back in 2016.

The cause is AI-assisted development, and that is the part worth sitting with for a moment. The same tools that make it cheap for your client to build an app this quarter make it cheap for everyone else with the same idea. Waiting was never free, and it is no longer priced the way it was. A year of hesitation in 2015 cost you a few hundred thousand new competitors. A year of hesitation starting now costs you a million.

4. The flywheel needs mass before it turns

Every signal the stores actually rank on requires users you already have. Install velocity needs a base to grow from. Retention is measured on people who installed. Review velocity is a fraction of installs. Update cadence only means anything if there is something live to update.

That cadence is not gentle at the top. 74% of the top 1,000 App Store apps ship at least monthly and 26% ship weekly, and the median gap between updates for top free apps is 18 days. You cannot hold a rhythm like that from inside a private repository. It begins on release day and not before.

There is academic support for the plain version of this too. A survival analysis of the Korean App Store charts found that early-entrant advantage is real, that it comes from the ranking system itself combined with consumer learning, and that it is stronger on the free chart than on the grossing chart. That is exactly the shape you would expect if the mechanism is accumulation rather than privilege.

Newness is an asset as well, and it expires unused

The one thing a new app owns that an old one does not is that it is new, and Apple pays for that.

Since 2024 you can nominate your own app for editorial featuring inside App Store Connect, and a new app launch is one of the three nomination types. Apple asks for two weeks of notice as a minimum and recommends up to three months of lead time for wider consideration.

You get one launch. It does not improve while you sit on it. Delay by eight months and you still get exactly one launch, only later, for a product nobody has been waiting for. The newness was going to be spent either way, so the choice is between spending it and letting it lapse.

It is worth remembering where the traffic goes in the meantime. Apple's own figures are that 70% of App Store visitors use search to discover apps and almost 65% of downloads happen directly after a search. Search position comes from keyword history, rating count and conversion rate. All three start at zero, and all three only move once you are live.

Shipping early is not shipping thin

This is where the advice usually gets misused, so let me be precise about it.

Guideline 4.2 says that if your app is not particularly useful, unique or app-like, it does not belong on the App Store. Guideline 4.3(b) rejects opportunistic variants of things that already exist. A first version that does five things badly is not an early release, it is a rejection, and a rejection costs you the exact weeks you were trying to save.

Minimum viable has to mean narrow, not shallow. One job, done completely, with the platform behaviour a reviewer expects: real permission handling, native UI, sane offline behaviour, an onboarding that survives first launch. That app clears review in days and starts accruing immediately. An app that does a little of everything does not clear review at all. I went through that failure mode in detail in Apple is rejecting useless apps.

Eighteen years of this is mostly knowing which corners are load-bearing and which ones are decoration. That is what makes a first version fast and shippable at the same time, and it is the whole difference between an early release and a wasted one.

If the first version embarrasses you

Reid Hoffman's line is that if you are not embarrassed by the first version of your product, you launched too late. It gets quoted as permission to ship rubbish, which it is not, but the fear underneath it is real and deserves a direct answer.

The fear is that early bad ratings are permanent. Given the ratchet described further up, that is a reasonable thing to worry about rather than a silly one.

The answer is that you have exactly one escape. When you release a new version you can reset the overview rating. Once you do, the previous rating cannot be restored, and the written reviews stay on the page regardless. So the star average is recoverable, the reviews are not, and you can use it once without it looking like a habit.

One clean slate is more than most people assume they have, and considerably less than something you would want to build a plan around.

What I would do with an unreleased app

• Ship the narrowest complete version rather than the smallest incomplete one. One job done fully clears guideline 4.2. Five jobs half done does not.
• Ship under the app name and bundle ID you intend to keep. History accrues to an identity, and changing that identity later throws the accrual away.
• Turn the rating prompt on in version 1. Ratings have the longest lead time of anything you own, so start that clock before you start any other.
• Check 4.3(b) against your category before you build rather than after. The list of effectively closed categories keeps growing, and discovering yours is on it at review time is the expensive way to find out.
• Nominate the launch for featuring. Two weeks of notice minimum, up to three months for serious consideration, and it costs you a form in App Store Connect.
• Then hold a cadence. Eighteen days is the median at the top of the free charts. Three years of silence is what gets an app deleted, so age only ever helps the people who kept shipping.

The clock, not the calendar

The advantage I felt as a developer who started in 2008 was never seniority, and I had it slightly wrong for the better part of two decades. Nothing in either store checks how long I have been around. What I actually had was a start date on a day when the queue was 500 apps long and every rating I collected was going to keep counting forever.

That same clock is available to an app shipping next month. It runs at the same speed and it counts the same things. It just starts later, and while the app is still a specification in a document, it is not running at all.