Open any App Store revenue dashboard and look for the date printed near the subscriber count. There is usually one, somewhere small. As of, and then a day that is not today.
That caption is honest, and it is also the whole problem. A figure from two days ago is a figure you could have read in App Store Connect yourself, in the same three taps, for free. Somebody built a product on top of it anyway.
Why the reports are always behind
Apple's sales and subscription reports are files, generated per day, closed on a Pacific time day boundary and published some hours after that boundary passes. Ask for today and you get nothing, because today has not closed. Ask at the wrong hour of your own morning and yesterday is not there either.
Nothing about that is broken. It is what a batch report is. A tool that reads only those files inherits the lag exactly, and no amount of pulling to refresh moves it, because the file on the other end is the same file.
The other half of the data
Apple also sends App Store Server Notifications. Your server gets a POST within seconds of a subscription starting, converting from a trial, cancelling, being refunded, or running into a billing problem. It is the same account, the same subscriptions, arriving as events instead of as a file.
On its own, the event stream cannot tell you your subscriber count either, for the mirror image reason. It starts at zero on the day you point Apple at your endpoint. Everyone who subscribed before that day is invisible to it, forever.
The two halves fit
Here is the part that took us a while to see. One source is complete up to a date and blind after it. The other is blind before a date and complete after it. If the second date is earlier than the first, the two windows meet with no gap and no overlap.
The report covers everything through its own closing day. The event feed covers everything since. Add them and the sum is whole.
So the current subscriber count is the report's count, plus the starts since the report closed, minus the cancellations and refunds since the report closed. Same for MRR. Same for the per-app split, which has to move at the same moment the total does, or the screen contradicts itself.
The seam has to be exactly one date. Take events from the instant the report's day ends, in Pacific time, and every subscription is counted once. Take them from an hour earlier and you will double count a night's worth of signups, which is the kind of bug that looks like good news.
When the sum does not work
Two cases. In both, say so.
The feed started too late. If notifications were pointed at your account after the last report closed, the window between them is covered by neither source. There is no honest way to fill that gap, so the right answer is the report, captioned with its date, until the feed has been running long enough to overlap.
Some figures have no live source at all. Ratings, written reviews, downloads and release adoption arrive only in reports. For those, the report is the true figure, and a date caption is the correct thing to show. Downloads that claim to be live are guessing.
Why bother
Because the question people open these apps to ask is a present tense one. How many subscribers do I have right now. A dashboard that answers with a number from Wednesday has quietly changed the question into one App Store Connect already answers.
Reading the report is the easy half. Standing up an endpoint for the notifications, keeping the events, and joining them at the right instant is a week of work nobody ever sees. It is also the only part that makes the figure worth opening.
How StudioDash handles this
StudioDash takes the report as the base and the notification feed as everything since, joined at the report's own closing day, so the subscriber count and MRR on the home screen are current rather than captioned. Where a figure has no live source, it says the date it came from.
