Valuation guide · asset type
What is a mobile app worth?
App multiples are the loudest numbers in our dataset and the least useful taken at face value. Here are our live figures for apps, the sample they come from, and why the biggest multiples in that sample are a statement about tiny profit figures rather than about price.
Read live from our public /api/stats endpoint when this page loads, counting
only non-demo rows that carry a sold price. Nothing here is baked into the HTML, and no
figure is published from fewer than five comparables.
This is the thinnest sample we publish a median for
Apps are the smallest asset type we publish a median for — two figures of tracked deals against three for e-commerce, content and SaaS. The count above clears our five-comp floor, so we publish the median rather than withholding it, but clearing a floor is not the same as being representative. Read the second figure before the third: it tells you how many sales the median actually rests on.
That sample is also narrow in a way the count alone does not show. Every app row we held when this page was written came from one venue's reserve-met auctions, all closing inside a single three-month stretch of 2026. One marketplace's auction floor is not the app market; it is the part of the app market that publishes outcomes. Our methodology and the source register in our data policy set out which venues we read and which publish nothing usable.
The big multiples are a denominator problem
A multiple is a price divided by a profit figure, so a small enough denominator produces an enormous quotient out of a trivial sale. In our app sample, every multiple at 5× or above came from a listing that stated under $100 of annual profit. The largest was a $320 sale of an app whose listing stated $12 of profit for the year: 26.67×, arithmetically correct and economically meaningless. A buyer paid $320 for an app, not 26 years of earnings.
This is why the median matters more than the range, and why we publish the median stated profit beside it. When the typical denominator is in the low hundreds of dollars a year, the multiple is measuring rounding error. Read the figures the other way round: what apps in this sample sold for is the honest headline, and the multiple is a ratio derived from a number the seller typed into a listing form.
There is a second wrinkle specific to app listings. On most app rows that state both figures, the stated annual revenue and the stated annual profit are the same number — the seller reports one figure and it lands in both fields. When that happens, the "profit multiple" is a revenue multiple wearing a different label, and no cost of running the app has been subtracted anywhere. We keep the row, because the price is real and cited, and we flag what it is rather than dropping evidence we find inconvenient. We wrote up what that does to the two bases in revenue multiple vs profit multiple.
What actually moves an app's price
With multiples this noisy, the price in a small app sale is set mostly by things that are not in the multiple at all. In rough order of how much they move the number in this size band:
- Whether the revenue survives the transfer. Ad revenue tied to the seller's ad-network account, or an IAP catalogue tied to their store account, is revenue you may not inherit on day one. Revenue that keeps arriving under new ownership is worth a multiple; revenue that stops is worth nothing.
- Install base and ratings, not downloads. Lifetime downloads is the number sellers quote. Active installs, retention past day 30, and the rating count that survives the transfer are what a buyer can monetise.
- Where the traffic comes from. An app ranking organically for a searched term is an asset. An app whose installs came from paid acquisition that stopped when the seller stopped paying is a codebase.
- What you receive. Source, signing assets, store listing, backend, and any third-party accounts the app depends on. A repository without the backend it calls is a rewrite quoted as an acquisition.
- Platform maintenance debt. An app that has not shipped against a current SDK target may be one store policy deadline away from removal, which is a cost the buyer carries and should price.
Check that the app can be transferred at all
App sales have a failure mode the rest of our asset types do not: the deal can close and the asset can still be stuck. Apple publishes the criteria an app must meet before it can move between developer accounts, and several of them are things a seller can be genuinely unaware of. Per Apple's app transfer criteria, the app must have had at least one version released to the App Store; it cannot be in a review-pending state such as Waiting for Review or Pending Developer Release; its in-app purchase product IDs cannot collide with product IDs already in the buyer's account; and Apple Arcade apps cannot be transferred at all.
Apple's overview of app transfer is equally worth reading for what does and does not come with the app. Reviews, ratings and the bundle ID transfer with it. TestFlight beta testing has to be turned off first, and an Apple Pay merchant ID does not transfer. Ask the equivalent questions on the Android side before you agree a price, and confirm them against the platform's own current documentation rather than the seller's summary of it — the answers decide whether you are buying a live listing or a source archive.
Getting a range instead of a number
The honest output for an app this size is a range with its sample attached, not a point estimate. The calculator prices against the comps we actually hold, shows how many there were, and refuses to quote when the sample is too thin or when your app is several times larger than the typical comparable. The paid report adds public-web comparables, a risk register and seller questions — and states plainly when our transaction data cannot carry the valuation on its own.
how these figures are computed · what a profit multiple actually means · all valuation guides