RevenueCat Blog

Although the Apple Insider article notes that you have to provide an email, the full article [1] actually has quite a bit of additional info.

Some pretty interesting, and rather sobering. Gaming is such dice throw (appropriately). It has the fastest subscriber growth, yet tops out worse than almost every other category, and has horrible 14 day, 60 day, and yearly average money. Only travel, productivity, and shopping (?) are worse. Shopping must not be tracking monetization correctly. Wow, gaming is so bad in almost every category. Offer usage, trial conversions, using any long subscription... If your game fails at launch, you might as well dump it immediately, or re-release some other way.

Looking at this kind of data, its no surprise so many parts of the web have turned into one-off demo sites with signups. If it doesn't get immediate traction, move onto the next project.

The biggest surprise personally, was how much better health care was than every category at 14 and 60 day earnings. Looking at those charts, why would you make anything other than a health and fitness app in North America with Apple Search Ads. Education in South Korea seems kind of nice, until you see the refund rate of double the next worst.

On the submission title topic, even the low end is kind of bad. Not just you won't be a superstar. Most apps never make more than $50/month. Even in the upper 75% you're looking at ~$200/month.

So if I spend a month each year making an app…

I make Hazumi News for iOS, a Hacker News reader (Free download + subscriptions)

- Free to download (did try €1 but didn't work well) My goal is to get as many users into the funnel, show them a good app for free, offer subscriptions for more features.

- I have a €1 per month subscription for backend functionality (push notifications and bookmarking with iCloud syncing)

- My subscription strategy is release shiny new thing to subscribers only, after 3-6 months, move it to free tier and add shiny new thing to subscription tier. Rinse and repeat.

- My app doesn't make much money either way. Subscriptions currently don't cover server costs + apple developer account + apps I use to build Hazumi but I enjoy what I do and will continue bootstrapping using my salary from my full time job.

You might be interested in RevenueCat's State of Subscription Apps post, under heading "Revenue, one year after launch, by category"

https://www.revenuecat.com/state-of-subscription-apps-2024/

I think the TLDR; of that article is, if you want to make money from an app, expect to play the long game. Apps in the "Productivity" category, one year after launch median earnings are < $50 per month.

Not necessarily.

For starters, small companies are paying 15%, not 30%.

I'm also not sure where a small company can find a payment processor that will only charge 1%. Stripe charges 2.9% plus 30 cents per transaction.

If you have a $4.99 in-app purchase that will cost you 44 cents per transaction to use Stripe vs 75 cents to use Apple's IAP.

But Stripe does not act as a merchant of record so you are responsible for remitting sales tax yourself. Registering for and remitting sales tax in every jurisdiction where you have nexus adds huge administrative overhead to a small company.

If you want to avoid this overhead, Paddle will act as a merchant of record for you, but then you're paying 5% plus 50 cents which adds up to 75 cents on a $4.99 purchase anyway.

Linking to external payments also reduces conversion rates (https://www.revenuecat.com/blog/growth/iap-vs-web-purchases-conversion-test/) compared to using IAP.

Taken all together, depending on their pricing structure, small companies may very well be financially better off sticking with IAP rather than linking to external payments anyway.

RevenueCat | various roles | Remote | Full-time | https://www.revenuecat.com

RevenueCat is an API that makes it easy to sell subscriptions in your mobile app. We launched as part of Y Combinator's summer 2018 batch and today are handling subscriptions for more than 5 million mobile subscribers, and are the subscription infrastructure for thousands of apps. We believe that a direct, consumer relationship between developers and their users will make the world a better place. We offer market-rate pay, equity, benefits, and we’re 100% remote.

We're hiring for the following positions:

- Engineering Manager ($164k-$185k) - https://jobs.lever.co/revenuecat/c77633a8-2047-4082-9cc6-91de1c13c68e

- Reliability Engineer ($150-$170K) - https://jobs.lever.co/revenuecat/dca0930f-c5a8-4309-b339-1fc72a753996

- Solution Engineer ($113,000-$127k) - https://jobs.lever.co/revenuecat/00d1cb1b-c5a9-4168-bc03-c95251ee4fe8

This is good advice! I would like to propose a corollary:

If your main API function has multiple parameters, in the documentation example you need to use all of them, and absolutely do not shadow the parameter names! “foo foo = foo” might make your demo look slick, but the developer learns nothing. This is a lost opportunity to explain the parameters with the variable name instead of a comment.

I’ll give an example: RevenueCat’s demo for using SyncPurchases [1] returns a tuple of (value, error), and they throw away the error, not even showing the 1 line of how you have to typecast it. This results in much digging needed.

[1] https://www.revenuecat.com/docs/getting-started/quickstart#4-using-revenuecats-purchases-sdk

Having built a cross-platform app recently as a very small team, I want to put in a plug for RevenueCat (https://www.revenuecat.com/). They abstract away the differences between the Apple/Google APIs so you don't have to worry about dealing with both. You only interface with Revcat. They don't support every last Play Store/App Store API, but I haven't yet found that be an issue. Worth noting that our app uses subscriptions, though, so I don't really know how they do with regular old purchases (I would assume that's supported since it seems to be a simpler case).