RevenueCat answers "how much did this app sell?" very well. It does not answer "did this app make money?", because it never sees what the app costs to run.
This guide shows how to get from the number RevenueCat gives you to a profit figure for each app, and the two mistakes that make the result look better or worse than it is.
What the RevenueCat dashboard already tells you
The Revenue chart can show three levels. As RevenueCat's revenue chart documentation describes them:
| Measure | What has been taken out |
|---|---|
| Revenue | Refunds and downward payment adjustments |
| Revenue (net of taxes) | Also the store's estimated taxes, such as VAT |
| Proceeds | Also the store's estimated commission or fees |
Proceeds is the closest thing to cash you will receive from the stores. RevenueCat calls the tax and commission figures estimates; it works them out from the purchase date, your Small Business Program status and the country of the sale (taxes and commissions).
So the starting point for profit is proceeds, not revenue.
What it cannot see
Everything you pay outside the stores is invisible to RevenueCat:
- Hosting, databases, storage and bandwidth
- AI model APIs, often the fastest-growing cost in a new app
- Email, analytics, crash reporting and error monitoring
- Design, development and marketing tools
- The Apple Developer Program fee, domains and anything paid yearly
Some of these belong to one app. Many are shared: one server plan, one design tool, one developer account across every app you publish.
The calculation, step by step
Work one month and one app at a time.
- Take the month's proceeds for the app. If you keep one RevenueCat project per app, that is the project's proceeds for the month.
- Subtract the app's direct costs. Costs that exist only because of this app: its API usage, its own hosting, its own subscriptions.
- Subtract its share of shared costs. Split each shared bill by a rule you can explain, such as equal shares, share of revenue, or a percentage you choose. The shared cost allocation guide covers the options.
- What is left is the app's contribution profit for that month. Divide it by revenue to compare apps of different sizes.
An example for October, assuming no sales tax:
| Line | Amount |
|---|---|
| Revenue | $1,900.00 |
| Store commission at 15% | −$285.00 |
| Proceeds (what RevenueCat shows) | $1,615.00 |
| AI API usage | −$60.00 |
| Its own database plan | −$25.00 |
| Share of the shared server and tools | −$48.00 |
| Contribution profit | $1,482.00 |
The same app looked like a $1,900 app on the revenue chart. After everything it needs to run, it contributes $1,482, or 78% of revenue.
Two mistakes that skew the result
Subtracting the store's cut twice. Proceeds already exclude commission. If you then enter "Apple 15%" as a cost, the app looks about 15% less profitable than it is. Either start from proceeds and leave commission out, or start from revenue and subtract it once. The contribution margin calculator has a fee field for exactly this: set it to 0% when you enter proceeds.
Mixing month boundaries. A renewal late on the last day of a month can fall into one month or the next depending on the time zone. Use one time zone for both revenue and costs; MarginDeck records synced months in UTC. Yearly charges need the same care; the real cost guide explains the two common ways to handle them.
Doing it every month without a spreadsheet
MarginDeck does this on your Mac. It connects to RevenueCat through read-only OAuth, which asks for Projects and Overview Metrics read access, and imports each project's monthly proceeds. Before anything is saved, you choose which product each project belongs to. From there it subtracts the costs and shared-cost splits you have recorded and shows contribution profit for each product, month by month.
Monthly history starts with your first successful sync; MarginDeck does not fetch earlier months from RevenueCat. Your records stay in a local database on your Mac.