- App Store Connect reporting lags; Apple's signal doesn't. Sales and Trends is a processed report delayed roughly a day or more, and proceeds are monthly. StoreKit 2 and Server Notifications v2 announce events in near-real-time.
- iOS MRR is a run-rate, not a payout. Normalise every active auto-renewable subscription to a monthly value and sum. It will never match Apple's monthly proceeds, which are net of Apple's commission and their own timing.
- Watch the five movements. New, renewals, expansion/contraction from up- and downgrades, churn (including involuntary billing-retry churn), and refunds. Renewals and involuntary churn are the two a top-line number hides.
- You have three honest ways to track it today. App Store Connect's own reports, a StoreKit-based tool (RevenueCat, Appfigures), or a spreadsheet from Apple's downloadable reports. Each is a real option with real trade-offs.
- The shared gap is the cause. A report shows the number moved. It rarely shows, in the same view, who churned and what — often a failed renewal or an error — caused it.
- Crossdeck reads and verifies Apple's signal. It joins each iOS MRR move to the customer and the error behind it, delivered to Telegram — and it does not change Apple's reporting or payouts.
Definitions used in this guide
What tracking App Store subscription revenue really means
Tracking App Store subscription revenue means watching your iOS recurring revenue and the movements that change it, from a source fresh enough that you learn about a meaningful move while you can still act on it. Most founders start and stop at one place: the App Store Connect dashboard. It is the official record, it is accurate, and it is the natural first stop. The catch is that it was built to be a reconciled financial report, not a live feed — so the number you see this morning is describing yesterday, or the day before, and the money side is settled monthly.
The honest version of "tracking App Store revenue," then, has two halves. The first is knowing what Connect gives you and reading it correctly — including that iOS MRR is a run-rate, not the proceeds Apple pays you. The second, which is where most of the value hides, is reaching past the lagging report to Apple's own real-time signal, and then joining each move back to the customer and the cause behind it. The first half is widely understood; the second is the subject of this guide.
What App Store Connect gives you — and why it lags
App Store Connect is genuinely good at what it is for. Its Subscriptions report shows active subscriptions, new subscribers, and churn by product; Sales and Trends shows units and proceeds; and the Payments and Financial Reports settle what Apple actually owes you. For a great many apps, this is a complete and correct picture of the business. Nothing here is a knock on Apple's reporting.
The one thing to understand about it is timing. Sales and Trends is a processed, aggregated report, typically delayed by around a day and often more, and Apple's proceeds and payments are reported on a monthly financial cycle. That is by design: these are reconciled records, corrected for refunds and currency and Apple's commission, not an event stream. The practical effect for a founder is a real wait — you can launch a promo at noon and not see it clearly land in Connect until tomorrow, and you cannot see this month's proceeds resolve until the financial cycle closes. That wait is the exact frustration behind every search for real-time App Store revenue. We treat why the reports alone fall short of product decisions in why App Store revenue reports are not enough for product decisions.
It is worth being precise, because it is easy to overstate: the lag is in the reports, not in Apple's knowledge of the event. Apple knows the moment a renewal succeeds or a subscriber cancels. It simply surfaces that in the dashboard on a reporting schedule and in the financials on a monthly one. Which is exactly why the next section matters.
Apple's real-time signal: StoreKit 2 and Server Notifications v2
Here is the part that gets lost in the frustration with the dashboard: Apple does emit a real-time signal — it is the Connect report that lags, not the underlying data. There are two live sources, and together they cover the whole subscription lifecycle.
StoreKit 2 exposes verified transaction and renewal information on device. When a purchase or renewal occurs, your app can read a cryptographically verified transaction immediately — no waiting on a report. This is the same verified data a tool can check to confirm a purchase is real rather than trusting a client's word for it; we cover the mechanics in StoreKit 2 subscription analytics: what developers should track and the validation angle in how to validate App Store purchases without building subscription infrastructure.
App Store Server Notifications v2 is Apple's server-to-server webhook. Apple sends your server a signed notification the moment a subscription event happens — purchased, renewed, upgraded, downgraded, entered billing retry, recovered, expired, cancelled, or refunded. Because each notification carries the event type, it is the cleanest live source for the movements behind iOS MRR: it tells you a renewal from a cancellation from a billing-retry failure, long before any of it settles into the financial reports. The founder-level walk-through is in App Store Server Notifications v2 explained for founders.
| Question | App Store Connect reports | StoreKit 2 + Server Notifications v2 |
|---|---|---|
| How fresh? | ~a day or more; proceeds monthly | Near-real-time, per event |
| What it is | Reconciled financial record | Live event stream / verified transaction |
| Sees a single renewal? | Aggregated, after the fact | Yes — the moment it happens |
| Sees billing retry / involuntary churn? | Eventually, in the totals | Yes — as its own event type |
| Best for | Settled finance and reconciliation | Real-time monitoring and entitlements |
Read the two columns as complements, not rivals. Connect is the reconciled truth you close your books against; the real-time signal is what tells you a subscriber just churned this afternoon. A tool that ingests and verifies StoreKit transactions can know about a move and alert you before the Connect report catches up — which is the honest, accurate version of "real-time App Store revenue." The closest treatment of that specific idea is how to see app revenue in real time before App Store Connect catches up; this guide is the subscription-MRR companion to it.
The five movements behind iOS MRR
iOS MRR — the normalised monthly value of your active auto-renewable subscriptions — moves for the same five reasons any subscription business does, but each has an App Store-specific shape worth knowing. The net number you usually stare at is all five fighting each other, which is why the net is such a poor teacher on iOS in particular: renewals and involuntary churn, the two biggest forces, are exactly the ones it smooths over.
| Movement | What it is on iOS | What it signals |
|---|---|---|
| New MRR | New subscribers and trials that convert to paid | Acquisition working — but a trial start is not yet revenue |
| Renewals | Auto-renewable subscriptions renewing on schedule | The bulk of iOS MRR; quiet until one stops |
| Expansion / contraction | Upgrades, downgrades and cross-grades between tiers | Value moving up or slipping down without a full cancel |
| Churn | Cancellations, plus involuntary churn after billing retry fails | The most preventable loss — often a payment failure, not a decision |
| Refunds | Apple-granted refunds that claw back a counted charge | A downward move that can arrive after the sale was booked |
Two of these deserve emphasis because they are where iOS surprises founders. Renewals are the engine — most of your iOS MRR each month is subscriptions renewing, not new sales — so a small dip in renewal rate matters more than a headline about new installs. And involuntary churn is the quiet one: a card expires, a renewal fails, Apple's billing retry and grace period run their course, and a subscriber who never chose to leave simply lapses. That is churn with a fixable cause behind it, and it is invisible in a top-line number. The failed-renewal case is important enough that we give it a full guide: how to monitor failed payments and billing retry in your app. The mechanics of iOS MRR itself mirror the Stripe treatment in the sibling guide, how to monitor MRR in real time.
How people track App Store revenue today
There are three genuinely reasonable ways to track App Store subscription revenue right now, and none is wrong. The right choice depends on how much you want to build and whether you also earn on other rails. Here they are, named fairly, with each trade-off.
App Store Connect's own reports. Free, official, and the source of record. The Subscriptions and Sales and Trends views give you active subscriptions, new and lost subscribers, and proceeds without any setup. The limitation is the one already covered — the reporting lag and the monthly financial cycle — plus that it is Apple-only. If your product also earns on Google Play or Stripe, Connect is one rail of a multi-rail number.
A StoreKit-based subscription tool. Tools like RevenueCat and Appfigures ingest StoreKit and App Store Server Notifications for you and present MRR, trials, conversion, cohorts and churn without you building the pipeline. They are well-made and, for many teams, the sensible answer — a proper subscription-analytics view without wiring up Apple's server notifications yourself. The trade-offs are cost as you scale, and that they are a revenue-and-subscription layer: they explain the number thoroughly but stay within it.
A spreadsheet from Apple's reports. The oldest option, and still fine when you are small. Download the subscription and sales reports, normalise plans to a monthly value, and sum. You own it completely and it costs nothing but time — plus the fragility, since it is only as current as the last download, it inherits the report lag, and normalisation slips creep in quietly.
| Approach | Best for | Real-time? | Shows the cause behind a move? |
|---|---|---|---|
| App Store Connect reports | The official record, any app | No — report lag, monthly proceeds | No — revenue layer only |
| StoreKit tool (RevenueCat, Appfigures) | Teams wanting depth fast | Yes, from Apple's signal | No — stays within subscriptions |
| Spreadsheet from Apple's reports | Small, cost-sensitive teams | No — inherits the report lag | No — and only as fresh as the last download |
| App intelligence layer (Crossdeck) | Multi-rail apps that need the why | Yes — verifies StoreKit as it arrives | Yes — joined to the customer and the error |
Read down the last column. All three tell you that iOS MRR moved and by how much; none, by design, tells you the customer behind the move or the reason for it — because each is a revenue-and-subscription tool, and the reason usually lives in a different layer entirely.
The gap: the number without the cause
Here is the moment every iOS founder who has watched their revenue knows. iOS MRR dips. Say it drops noticeably overnight. Your subscription tool shows the dip cleanly, attributes it to churn, and stops there. You now know iOS MRR fell and that a cancellation or a lapse caused it — and you know nothing about which customer, or why they went. The tool has told you the score changed and left you to open other tools to find out what happened.
So the investigation begins: the subscription dashboard to find the lapsed subscription, your customer records to see who they were, your error monitoring to check whether they hit a failure. And often — often enough that it should change how you think about iOS revenue — you find the churn was not a decision at all. The renewal failed, Apple's billing retry could not recover the card, the grace period ran out, and the subscriber lapsed involuntarily. Or worse, the customer hit a checkout or paywall error and never completed the purchase in the first place. The MRR drop was the last event in a chain that started with a failed renewal or an error, and your revenue tool could see only the final link.
This is the structural gap, stated plainly: a report shows you that iOS MRR moved; it rarely shows you, in the same view, the customer who moved it and the cause behind the move. That is not a flaw in any product — App Store Connect, RevenueCat and Appfigures all do their job accurately. It is that the answer to "why" lives across three layers — revenue, identity, and errors — and a single-layer revenue tool holds only one. The number and its cause are separated by the exact join no subscription report was built to make.
iOS MRR joined to its cause
The fix for that gap is not a fresher chart. It is a join. Crossdeck is the app intelligence layer: it verifies StoreKit transactions as Apple's signal arrives, monitors revenue across rails — Apple, Google, Stripe — and joins each iOS MRR move to the customer behind it and to any error on that customer's timeline, by identity. That join is the cross-match, and it is the difference between a number that moved and a number that arrives with its explanation attached. When iOS MRR dips, you are not handed a figure to go investigate; you are handed the lapsed customer and the failed renewal or error that preceded their churn, on one timeline, in one view. The contrast is easiest to see side by side.
| When iOS MRR drops… | A static iOS MRR number | iOS MRR joined to its cause |
|---|---|---|
| What you see first | The total fell by an amount | The total fell — and the customer who caused it |
| Which movement | "Churn" as a category | The specific cancellation, refund or failed renewal |
| Voluntary or involuntary? | Not distinguished | Billing-retry failure flagged as involuntary |
| Who | Unknown — go look it up | The named customer, on their timeline |
| Why | Not in this view | The checkout or renewal error that preceded it, if any |
| Across which rails | Apple only | Apple, Google and Stripe, joined |
| Your next step | Open three other tools | Recover the renewal, or reach the customer |
To be careful about the claim: Crossdeck reads and verifies Apple's own signal and surfaces it earlier and joined to its cause — it does not change App Store Connect's reports, and it does not speed up or alter Apple's payouts, which still follow Apple's monthly cycle. It is the intelligence layer plus its delivery, not a full BI suite, and every figure is read from your live Crossdeck data rather than estimated. What it does is hold revenue, identity and errors in one hand, so "why did iOS MRR move?" has an answer where the move appears. For the wider pattern this sits inside — monitoring the whole business in real time, not one metric at a time — see the hub guide, real-time business monitoring.
Tracking iOS MRR from your phone
Once iOS MRR is joined to its cause, where you read it matters less. You do not need to sit in front of App Store Connect to track App Store revenue; it can reach you where you already are. Crossdeck delivers the joined view to Telegram, in private chat, three ways.
- The Mini App shows your iOS MRR and its trend from your phone — the current figure and which way it is moving, alongside the other rails. Sign in to the dashboard with Telegram; it is the same live figure the web view shows.
- Hard-data commands. Ask
/revenueand the bot replies with your live recognised revenue and recent trend on demand — the fastest way to check the number: a message, an answer, no dashboard. - Prism, for the "why". This is the part a report cannot do from your pocket. Ask in plain English — "is App Store MRR down this week, and is it tied to a failed renewal or an error?" — and Prism answers off your live numbers, joining the revenue move to the customers and errors behind it.
One honest note on Prism, because it matters: Prism runs on your own AI model, with your own key, connected once in the Prism tab. It is your model reasoning over your live Crossdeck data — Crossdeck does not run an AI on your data or train on it. Connect a model first, and from then on you can ask iOS MRR questions in words. The alerts, Mini App and commands work in private chat today; shared team and group chats are on the roadmap, not shipped yet. You can see Prism itself at cross-deck.com/prism.
Alerts and honest real-time
iOS revenue alerts. An alert is a message when App Store revenue moves in a way worth knowing about — a cancellation, a refund, a run of failed renewals, or a large downgrade. Most tools can send a threshold alert or a daily summary, which is genuinely useful. But a plain threshold alert hits the same gap as before: it tells you the number moved, not who moved it or why, so it lands as a notification rather than the start of a fix. An alert earns its interruption when it names the customer behind the drop and the error or failed renewal, if any, that preceded it — only possible when the alert is fired from joined data.
Real-time App Store revenue is real, with one honest caveat worth stating plainly: it is as fresh as Apple's signal, and no fresher. StoreKit 2 transactions and Server Notifications v2 arrive quickly, so iOS MRR built on them sits close to live — earlier than the Connect dashboard. But nothing a third party does speeds up Apple's reporting or payouts; the financial reconciliation still follows Apple's monthly cycle. Crossdeck surfaces the current figure on demand from the verified signal and is clear about the difference between the live movement and the settled proceeds, rather than presenting a smoothed guess as fact.
How to start tracking App Store revenue well
You do not need to rebuild your stack to track App Store subscription revenue properly. Start where you are and add the missing layer.
- Keep App Store Connect as your record of truth. Its reports and financials are the reconciled source; do not try to replace them. Just stop treating the lagging dashboard as your real-time view.
- Read Apple's live signal for freshness. Use StoreKit 2 and App Store Server Notifications v2 — directly or via a tool — so you learn about a renewal, cancellation or refund when it happens, not a day later.
- Watch the five movements, not just the total. Split iOS MRR into new, renewals, expansion/contraction, churn and refunds — and separate involuntary churn out, because it is the most recoverable loss you have.
- Close the gap to the cause. Make sure a move can be traced to the customer and to any failed renewal or error behind it — the join a revenue-only report cannot make, and the difference between knowing iOS MRR fell and knowing why.
- Put it where you'll see it. A number you check beats a dashboard you don't. Whether that is App Store Connect or a
/revenuemessage in Telegram, choose the surface you actually look at.
Tracking App Store subscription revenue is easy to do shallowly and valuable to do properly. The shallow version is yesterday's number in a lagging dashboard; the proper version is the live signal, split into its five movements, across every rail, with each move joined to the customer and the cause behind it — the number arriving with its explanation. That join is the whole difference between watching iOS MRR and understanding it.
Frequently asked questions
How do you track App Store subscription revenue?
You track App Store subscription revenue by reading it from one of three places: App Store Connect's own Sales and Trends and Subscriptions reports, a StoreKit-based tool that ingests StoreKit 2 transactions and App Store Server Notifications v2, or a spreadsheet built off Apple's downloadable reports. To turn it into an MRR figure you normalise every active auto-renewable subscription to a monthly value and sum them. The gap most of these share is that they show the number moved without showing the customer behind the move and the failed renewal or error that caused it in the same view.
Why does App Store Connect revenue lag?
App Store Connect's Sales and Trends reporting is a processed, aggregated report rather than a live feed, so it is typically delayed by around a day and often more, and Apple's proceeds and payments are reported on a monthly financial cycle. That is by design — the reports are reconciled financial records, not an event stream. The practical effect is that a founder watching only the Connect dashboard can wait a day or longer to see whether a sale, renewal or cancellation happened, which is the real frustration behind searches for real-time App Store revenue.
Does Apple provide real-time subscription data?
Yes. Separate from the Sales and Trends reports, Apple emits a real-time signal: StoreKit 2 exposes verified transaction and renewal information on device, and App Store Server Notifications v2 sends your server a message when a subscription event happens — a purchase, a renewal, an upgrade or downgrade, a cancellation, a billing-retry entry or a refund. So App Store subscription events are available in near-real-time; it is the Connect dashboard and financial reports that lag, not the underlying signal. A tool that ingests and verifies StoreKit transactions can know about a move before the Connect report catches up.
What moves iOS subscription MRR up and down?
iOS MRR is moved by the same five forces as any subscription business, expressed in App Store terms. New MRR comes from new subscribers and trials that convert. Renewals are the bulk of iOS MRR — auto-renewable subscriptions that renew on schedule. Expansion and contraction come from upgrades, downgrades and cross-grades between tiers. Churn comes from cancellations and from involuntary churn, where Apple's billing retry cannot recover a failed renewal after the grace period. Refunds are their own downward move, since Apple can refund a charge after it is counted. Renewals and involuntary churn are the two that a top-line number hides most.
How do you track iOS MRR in real time?
You track iOS MRR in real time by reading Apple's live signal — StoreKit 2 transactions and App Store Server Notifications v2 — rather than waiting on the Connect dashboard, and normalising active auto-renewable subscriptions to a monthly figure. Crossdeck verifies StoreKit transactions as they arrive, joins each move to the customer and any error behind it, and answers /revenue with your live iOS MRR and trend in Telegram, with the Mini App showing it from your phone. It is real-time to the freshness of Apple's signal; it does not change Apple's own reporting or payout timing.
What is App Store Server Notifications v2 used for?
App Store Server Notifications v2 is Apple's server-to-server webhook for subscription lifecycle events. Apple sends your server a signed notification when a subscription is purchased, renewed, upgraded, downgraded, entered billing retry, recovered, expired, cancelled or refunded. It is what lets a backend keep entitlements current and know about renewals and involuntary churn without polling. Because it carries the event type, it is also the cleanest real-time source for the movements behind iOS MRR — a renewal versus a cancellation versus a billing-retry failure — long before those settle into the Connect financial reports.
Why did my App Store MRR drop?
An App Store MRR drop is one of the loss movements — a cancellation, a downgrade, an involuntary churn where billing retry failed, or a refund — but the number alone will not tell you which, or who, or why. On iOS the most common hidden cause is involuntary: a renewal fails, Apple's billing retry and grace period run out, and the subscriber lapses without ever deciding to leave. Answering why iOS MRR dropped means joining the revenue move to the specific customer and to any billing-retry failure or error on their timeline — the join a single-layer revenue report is not built to make.
Does Crossdeck change Apple's reporting or payouts?
No. Crossdeck reads and verifies Apple's own signal — StoreKit 2 transactions and App Store Server Notifications v2 — and surfaces it earlier and joined to its cause. It does not alter App Store Connect's reports, and it does not change when or how much Apple pays out; proceeds and payments still follow Apple's own monthly financial cycle. Crossdeck's role is to make the already-existing real-time signal legible and to join each iOS MRR move to the customer and error behind it, not to be a system of record for Apple's finances.
Do you need to set anything up to ask Prism about App Store MRR?
Prism runs on your own AI model with your own key, connected once in the Prism tab — it is your model answering off your live Crossdeck numbers, not an AI that Crossdeck runs on or trains on your data. Once a model is connected, you can ask in plain English, for example "is App Store MRR down this week, and is it tied to a failed renewal or an error?", and get an answer built from live figures in private chat. The bot's alerts, Mini App and commands work in private chat today; shared team and group chats are on the roadmap.
See it live on your own numbers
Connect your rails and get real-time alerts that name the customer, the plan, and the money — plus a Mini App and plain-English answers, live in Telegram. Free to start.