Paddle and Apple revenue in one view
A small software business can have a good week and still spend ten minutes trying to find out whether anything happened. The reason is not a lack of data. It is that the data lives in different places, with different definitions and different delays.
If you sell a Mac app through Paddle and an iPhone app through the App Store, your revenue is split across two very capable systems. Add Stripe, Polar, or a second storefront and the morning ritual gets longer: open a dashboard, find the right date, translate the number, open another dashboard, then try to remember what the first number meant.
This guide is about making that ritual smaller. It is not financial advice and it is not a recommendation to replace either provider. It is a way to design a trustworthy daily revenue view while keeping the detailed reports where they belong.
Start by naming the number
Most revenue dashboards become confusing at the moment they combine numbers that describe different moments in the money’s journey. A customer purchase, a reported transaction, a payout, and money in a bank account are related, but they are not interchangeable.
Before building a combined view, choose a label for every value:
- Sales: customer purchases recorded by the provider.
- Proceeds: the amount attributed to the developer after the store’s rules and deductions.
- Payouts: money scheduled or sent by a provider.
- Refunds and adjustments: events that change the meaning of an earlier sale.
A good overview can show all four, but it should never make the reader guess which one is the headline. “Revenue” without a definition is a decoration, not a useful metric.
Why Paddle and App Store Connect feel so different
Paddle is transaction and subscription oriented
Paddle’s reporting is designed for the operational questions around billing: subscriptions, transactions, adjustments, products, fees, and payout reconciliation. That depth is valuable when you need to investigate a customer, reconcile a period, or understand retention.
It can be more detail than you need when the question is only, “Did a sale come in since yesterday?” The answer exists, but it is surrounded by the machinery required to run a billing platform.
Apple is store and fiscal-period oriented
App Store Connect brings together releases, reviews, TestFlight, agreements, app analytics, and financial reporting. Its proceeds and payments follow Apple’s reporting and fiscal calendar, which means the number you see is not necessarily a live bank balance or a same-day settlement.
That is not a flaw. Apple is giving developers a reliable store ledger. The mismatch appears when a solo developer tries to compare it directly with a transaction feed from another provider.
The useful product is a revenue pulse
“Analytics” suggests a large dashboard. A revenue pulse is smaller. It answers the questions that influence today’s work:
Show new sales, refunds, and meaningful changes since the last check.
Make the app, plan, or product visible so the number has a story.
Compare today with the last seven days and month-to-date, using the same definition each time.
Leave room for a note: reply to a customer, improve a page, ship an update, or do nothing.
The pulse should be quick to read and difficult to misunderstand. Provider detail can stay available behind the transaction or product, rather than taking over the first screen.
A simple daily workflow
Here is the routine I would use for a small portfolio of apps.
- Check one overview. Read today, seven-day, and month-to-date figures. Keep the provider split visible.
- Open the feed only when something changed. Identify the product, currency, provider, and event date.
- Write one sentence of context. “Revenue Bear appeared in yesterday’s App Store search” is more useful than another screenshot of a chart.
- Choose one action. Follow up with the buyer, update the product page, write a useful post, or leave the system alone.
- Review the source reports weekly. Use Paddle and App Store Connect for reconciliation and tax records, not for nervous refreshing.
The discipline is in separating the quick check from the accounting check. They are both important, but they are different jobs.
Questions a trustworthy combined view must answer
Is the figure gross or net?
Put the answer next to the figure. If the sources provide different stages of the money flow, show separate cards rather than one impressive total.
What date does “today” mean?
Use the provider’s event or report timestamp and show the timezone. If a report is delayed, say so. A quiet day may be a quiet day, or it may simply be a reporting delay.
How are currencies handled?
Keep the original currency available. If you convert, show the rate or mark the result as an estimate. Precision without context is misleading.
Where are credentials stored?
A read-only revenue view should use the narrowest access possible, keep secrets in the platform’s secure storage, and make it clear when data was last synced. “Private” should describe a concrete design choice, not just a marketing adjective.
What I would build first
The first release does not need cohort analysis or a dozen chart types. It needs a reliable answer and an honest trail back to the source:
- a combined overview with provider labels;
- today, seven-day, and month-to-date views;
- a searchable transaction feed;
- per-product totals for a portfolio of small apps;
- refund and adjustment visibility;
- last-synced timestamps and an export path to the provider reports;
- read-only connections wherever the provider supports them.
That is enough to reduce the morning tour from several dashboards to one calm decision. The detailed systems remain authoritative; the small view simply makes the first answer easier to reach.
Why this matters for small app makers
A larger company can assign someone to reconcile reports. A solo developer usually becomes the finance team, product manager, support desk, and marketing department at the same time. Every unnecessary dashboard switch competes with the work that could create the next sale.
That is why a focused iPhone view can be useful even when Paddle and Apple already provide excellent web reporting. It is not trying to replace the source systems. It is shortening the distance between “I wonder if anything happened” and “I know what changed, and I know what I will do next.”
If your immediate problem is not revenue reporting but deciding which SEO page deserves attention, Rank for Mac applies the same principle to Search Console: one signal, one next action, one way to check whether it worked.
See Revenue Bear for iPhone