See App Store Connect sales in real time

Why App Store Connect makes you wait — the short answer

App Store Connect does not show your sales in real time: its Sales and Trends reporting lags by roughly a day — sometimes more — and proceeds are reported monthly and paid out well after the sale, so refreshing the dashboard the moment a purchase clears usually shows you nothing yet. This is the frustration nearly every iOS founder hits early. You ship, someone buys, and you want the small, honest jolt of knowing it happened — and the one place you would look to confirm it is precisely the place designed to answer later.

It helps to say plainly what is and isn't true here, because the internet is full of half-answers. It is not true that Apple gives developers nothing real-time. It is true that the App Store Connect dashboard — the thing most people mean by "App Store Connect" — is reporting after the fact, on purpose, and was never meant to be a live ticker. Those are two different statements, and the whole answer to "how do I see App Store sales in real time?" lives in the gap between them. The dashboard is slow; the signal underneath it is not.

So this guide does two things in order. First, the genuinely useful, free part: exactly what App Store Connect shows and when, why it is delayed, the difference between Sales and Trends and Payments, and how developers check sooner today with tools they already have. Then the accurate mechanism: the real-time signal Apple already emits, and what it takes to read it so a sale finds you the instant it happens instead of a day later in a report.

What App Store Connect shows, and when

App Store Connect is very good at what it is for. The confusion comes from expecting one tool to do two jobs that run on two very different clocks. It is worth separating them cleanly, because most "why is my revenue delayed?" questions dissolve the moment you see which report you are actually looking at.

Sales and Trends — quick, and estimated

Sales and Trends is the analytical view: units sold and estimated proceeds, aggregated into daily, weekly, and monthly windows. It is the closest thing Connect has to a "how are we doing?" dashboard, and it is useful for spotting movement — a launch bump, a dip after a release. But two properties matter for real-time expectations. It is delayed: the day's sales report typically finalises the following day, and the view can take roughly a day to settle. And it is estimated: the proceeds shown are an approximation, not the final figure you will be paid. Good for trends, by name and by design — not for confirming that one specific purchase just happened.

Payments and Financial Reports — final, and monthly

Payments and Financial Reports is the accounting view: final, reconciled proceeds by fiscal month, after refunds, taxes, and currency conversion are settled. This is the number Apple actually pays you, and it is the one that belongs in your books. Its clock is the slowest of all — proceeds are reported per fiscal month and paid out after the period closes, so the money for a sale you make today arrives on a monthly cadence, well down the line. That is normal, and it is the correct behaviour for an accounting system whose job is to be right and auditable rather than instant.

Hold the two side by side and the shape is clear: one report is quicker but approximate, the other is final but monthly, and neither is trying to tell you the second a sale clears. If your question is "did that purchase go through, right now?", you are asking a reporting surface a real-time question it was never built to answer. We go deeper on reading these reports well in the complete guide to App Store Connect revenue, and on why the reports alone can't drive product decisions in why App Store revenue reports aren't enough.

Why the reporting is delayed — factually

The delay is not a flaw and it is not Apple being unhelpful; it is the direct consequence of what each report is for. Naming the reasons matters, because it tells you exactly why the dashboard is the wrong place to look for immediacy — and points you at the right place instead.

• Aggregation runs in batches. Sales and Trends rolls raw events up into daily and weekly totals. Aggregation of that kind finalises after a window closes, not continuously — which is why the current day looks incomplete and settles by the next.
• Financial reporting has to be reconciled. Final proceeds require refunds, chargebacks, taxes across jurisdictions, and currency conversion to be settled first. You cannot report a final, payable number the instant a sale happens, because part of that number isn't known yet.
• Payouts follow the fiscal calendar. Apple closes a fiscal month, then reports and pays. That cadence is monthly by design, so proceeds are always reported and paid well after the individual sale.

Every one of those is a good reason for a system that must be correct and auditable. None of them is a reason a founder should have to wait to know a sale occurred — because "did it happen?" and "what am I finally owed after reconciliation?" are different questions, and only the second one needs to wait. The delay belongs to the accounting, not to the fact of the sale.

How long does App Store Connect take to show sales?

The direct answer, because it is the most-searched version of this question: expect Sales and Trends to lag by roughly a day — the daily report for a given day generally finalises the following day, and the dashboard can take about that long to settle — while final, payable proceeds appear monthly in Payments and Financial Reports, after the fiscal period closes. So "how long for App Store Connect to show sales?" has two answers depending on which you mean: about a day for the estimated trend, and a month-plus for the final money.

That is the honest range, and it is why so many developers describe the same small ritual — making a sale, opening Connect, and finding the dashboard hasn't caught up. The report isn't broken; you are simply early for it. The useful move is to stop treating a delayed reporting surface as a real-time one, and to read the signal that is real-time instead. Before we get there, the free ways people bridge the gap today are worth knowing, because you can get a real version of "sooner" without any platform at all.

What developers do to check sooner today

You are not stuck with the dashboard's clock while you wait for anything fancier. Several free or standard approaches get you closer to the moment of sale, and they are genuinely worth using. Here is the fair map.

• The App Store Connect mobile app. Apple's own app surfaces the same Sales and Trends data on your phone. It is convenient, but it reads the same delayed reporting — it is a nicer window onto the same lagging number, not a faster number.
• Consume Apple's server notifications yourself. The real-time route: point an endpoint at App Store Server Notifications V2, verify the signed payloads, and you can react to a purchase as it lands. This is the correct mechanism — the cost is that you are building and maintaining a verification pipeline, which is real engineering. We wrote the founder's version of how these work in App Store Server Notifications V2, explained.
• Read StoreKit 2 transactions in-app. On the device, StoreKit 2 gives you verified transactions the moment a purchase completes — the client-side half of the signal, useful for reacting in your own app. What developers should track from it is covered in StoreKit 2 subscription analytics.
• Use a tool that verifies the signal for you. Rather than building the pipeline, you can point the existing notifications at a service that ingests and verifies them and hands you the result as an alert. This is the shortcut the rest of this guide describes — and it avoids building subscription infrastructure just to validate a purchase.

Notice the split: the mobile app is the same slow data in a better wrapper, while the last three all read Apple's real-time signal — the difference being how much you build yourself. That is the whole practical question, so it deserves its own section: what exactly is the signal Apple emits? We have a companion piece dedicated to the closest version of this — how to see app revenue in real time before App Store Connect catches up — which walks the event-stream approach step by step; this post picks up where it leaves off, with the alert.

Apple already emits a real-time signal

Here is the fact that reframes the whole problem, and it is worth stating carefully because it is so often mangled. Apple's App Store Connect dashboard is delayed, but Apple itself emits purchase information in near-real-time. The two are not in tension; they are two outputs of the same platform aimed at two different needs. The dashboard aggregates for reporting, slowly. The notification fires for reaction, immediately.

That real-time signal comes in two forms. App Store Server Notifications V2 are server-to-server messages Apple sends to an endpoint you configure whenever a meaningful purchase event happens — a new purchase or subscription, a renewal, a failed renewal, a refund, a billing retry. They arrive in near-real-time and carry signed transaction data you can verify, which makes them the authoritative source for "what did this customer just do?". StoreKit 2 transactions are the device-side counterpart: verified purchase records available the instant a purchase completes in your app. Together they mean the information you want — a sale just happened — exists on Apple's side long before Sales and Trends settles.

So the real question was never "does the data exist yet?" It does. The question is "who is reading and verifying it?" Consuming server notifications correctly — verifying signatures, handling every event type, staying current as the format evolves — is real, ongoing engineering, which is exactly why most solo developers and small teams never wire it up and fall back to refreshing a delayed dashboard. The signal is public and real-time; the friction is the pipeline. Close that gap and the delay disappears.

Reading the signal: an App Store sale alert on your phone

This is where Crossdeck fits, and it fits at exactly one honest point: reading and verifying the signal Apple already emits, then putting the result where you'll see it. Crossdeck ingests and verifies App Store Server Notifications V2 and StoreKit 2 transactions, so it knows about a purchase in near-real-time — and it sends a "you just made a sale" alert to Telegram before the App Store Connect dashboard catches up. No pipeline for you to build; the notifications point at Crossdeck, and Crossdeck does the verifying.

Two things make this trustworthy rather than a novelty. First, the number is recognised revenue — drawn straight from the verified transaction, not an estimate — so an alert that says a sale happened means a sale happened. Second, the alert lands in Telegram, live today, in private chat via @Crossdeck_bot, alongside the hard-data commands you'd expect: /revenue for this month's recognised revenue, /people for the latest customers and signups, /status for business health at a glance. The sale that Connect will show you tomorrow is on your phone the moment it clears today.

And because Crossdeck is multi-rail — Apple, Google, and Stripe — the same alert stream covers your other rails without you assembling three separate setups. App Store sales, Play Store sales, and Stripe charges arrive in one place, each read from that rail's own real-time signal. The iOS case is the sharpest, because App Store Connect's delay is the one founders feel most, but the pattern is the same across rails: read the live signal, don't wait on the report.

The join: who bought, on which plan, and what they're worth

A raw "a sale happened" ping is nice for morale and thin on usefulness. The reason to read the signal through Crossdeck rather than a bare webhook is that Crossdeck joins it to everything else it knows about the customer. Through the cross-match — revenue, entitlements, errors, analytics, and identity joined by identity — a sale alert can carry not just that a purchase cleared, but who it was, which plan they took, whether they're new or renewing, and their lifetime value so far.

Picture the illustrative version. Instead of "new sale," the alert reads: a new customer just took the annual plan, first purchase, and here is their entitlement now active. Or: a renewal on your top tier just cleared for a long-standing customer, lifting their lifetime value into your best cohort. Same real-time signal, but arriving with the context that tells you whether to send a welcome, a thank-you, or nothing at all — decided in one read, from your phone, without opening a dashboard that wouldn't have the answer yet anyway.

When you want to go further than the alert, Prism is the plain-English layer. Ask a follow-up in words — "how many new App Store customers this week, and what's their average first-purchase value?" — and your own connected AI model answers off your live Crossdeck data. The detail that makes it trustworthy: Prism runs on your model, with your key. Crossdeck does not run AI on your data or train on it; you connect a model in the Prism tab once, and from then on it reasons over your real, recognised numbers. It is the natural-language companion to the alert, covered in full in asking your business data in plain English. This joined, phone-native view is the subject of the cluster hub, real-time business monitoring, and the wider context lives in the complete guide to app revenue intelligence.

Two honest notes to keep expectations exact. Prism is not zero-setup — you connect a model in the Prism tab once before it can answer. And this all runs in private chat by default, with single-use tap-actions on alerts; shared team and group-chat monitoring, where a whole team gets the sale alerts and asks Prism together, is on the roadmap, not shipped today.

App Store Connect timing vs the verified real-time signal

Put the two next to each other and the choice stops being "delayed or nothing" and becomes "which surface answers which question." The dashboard is still where the final, reconciled money lives; the verified signal is where the fact of a sale lives, instantly.

Read the last row twice, because it is the one people most want to misread. Seeing a sale in real time is about knowing sooner, not being paid sooner. The money still moves on Apple's monthly schedule. What changes is that you stop outsourcing the simple, immediate question — did it happen? — to a report built for the slow, complicated one.

What this does — and doesn't — do

It is worth being blunt about the boundary, because over-claiming here would be both wrong and easy to disprove. Crossdeck reads and verifies the real-time signal Apple emits. It does not change anything on Apple's side. Specifically:

• It does not speed up App Store Connect. Sales and Trends still settles on its own clock; Crossdeck does not touch it.
• It does not change Apple's reporting or reconciliation. Final proceeds are still Apple's figures, reconciled Apple's way, on Apple's calendar.
• It does not move your payout a day earlier. The monthly payout schedule is Apple's, and no third party alters it.
• It does read the existing signal for you. The purchase notifications and StoreKit 2 transactions are already emitted in near-real-time; Crossdeck verifies them and turns them into an alert, so you learn about the sale as it happens instead of a day later.

That honesty is the point, not a disclaimer bolted on the end. The value is precise and real: the gap between "a sale happened" and "you found out" collapses from about a day to about a moment — using information Apple already provides, joined to the customer, delivered to your phone. Nothing more is claimed, because nothing more needs to be.

How to start

You can get value in stages, and the early stages cost nothing — which is the right way to approach this.

1. Set expectations correctly. Treat Sales and Trends as a next-day trend and Payments as the monthly final number. Once you stop expecting the dashboard to be real-time, the frustration mostly evaporates.
2. Turn on the App Store Connect mobile app. Free, and a nicer window onto the delayed data. Just know it is the same clock, not a faster one.
3. Decide whether to build or read the signal. If you enjoy owning the pipeline, wire up App Store Server Notifications V2 and StoreKit 2 yourself — start with the founder's guide to V2. If you'd rather not maintain verification code, point the notifications at a tool that reads the signal for you.
4. Get the alert where you already are. Route the verified sale signal to Telegram so a purchase finds you the moment it clears — with the plan, the new-vs-renewing flag, and the customer's value attached, not just a bare number.
5. Add the follow-up question. Connect a model in the Prism tab once, and you can ask your live numbers a plain-English question from the same chat — no dashboard, no export.

The through-line is simple and worth holding onto. App Store Connect is not slow because Apple withholds your data — it is slow because reporting and accounting should be careful. But the fact of a sale doesn't need to wait for careful, because Apple already emits it in real time. Read that signal, join it to the customer, and put it on your phone, and you get the honest thing every iOS founder actually wanted from the dashboard: to know, the moment it happens, that someone bought. You can see how the cross-match works on cross-deck.com, ask your own numbers a question with Prism, or start free and wire the first real-time App Store alert into Telegram today.

Frequently asked questions