How to Price an App: Models, Billing Periods, and the Number

Open any indie dev subreddit and the same question comes up every week, in a dozen forms. Subscription or one-time? Monthly, yearly, or lifetime? Is a weekly plan clever or just scummy? How much should I actually charge? Pricing an app is not one decision, it is a stack of them, and most guides only cover pricing models and skip the ones people actually argue about.

First, one thing out of the way. This is about how to price an app for the store, what to charge the person downloading it. It is not about app development cost, what it costs you to build the thing. Those get blurred in search, and they are different questions with different answers.

I have shipped and priced apps on the App Store and Google Play since 2012. This walks through the pricing decisions in the order you actually face them: the model, the billing periods including lifetime and the weekly question, the number, and the step almost nobody does, which is making that number fit each country. By the end you will have an answer to every version of "how do I price this" that shows up in those threads.

Free, paid, freemium, or subscription: pick a model

The model is the shape of the transaction, and it is the most common pricing question in every dev sub.

Paid up front is the cleanest and now the rarest. The user pays once to download. It suits tools with obvious, immediate value, and it is a hard sell on a storefront full of free apps.

Freemium is free to download with a paid upgrade. It is the default, but the reason is scale: commonly cited benchmarks put freemium conversion at 2 to 5 percent, so it only works if you can acquire a large base cheaply or your paying users are worth a lot each.

Subscription is a recurring fee for ongoing access, and it is the dominant consumer model. If your app delivers value continuously, health, fitness, learning, content, this is usually the right spine. The mechanics of auto-renewable subscriptions are their own topic.

In-app purchases are one-time unlocks, often layered on top of one of the above.

For most consumer apps, the honest default is freemium plus a subscription. Pick the model that matches how your app delivers value, then decide the part people actually agonize over: the billing periods.

If you want to weigh those models properly, here is a deeper look at subscription vs one-time vs hybrid and what each does to your revenue over time.

Weekly, monthly, annual, or lifetime: choosing your billing periods

If you went subscription, your next decision is which billing periods to offer, and this is the question that fills paywall threads. Here is how I think about each.

Monthly and annual, offered together. This is the standard pair. You show both and anchor on the annual plan, because a yearly price next to a monthly one makes the yearly look like the deal. The convention is to price the annual plan at roughly the cost of ten months, so about two months free. That works out to around a 17 percent discount off twelve times the monthly price, and analyses of SaaS pricing put most annual discounts in the 15 to 20 percent range, with 10 to 25 percent common. Annual plans also improve your cash position and smooth out churn, which is why most subscription apps push them.

Lifetime, handled carefully. This is the most-argued option, and both camps are right. A lifetime purchase front-loads cash, stands out in a category full of subscriptions, and converts the buyers who hate recurring fees. The risk is that it cannibalizes your best subscribers, the ones who would have paid you for years. So price it for loyal fans, not bargain hunters. A common rule of thumb is 3 to 5 times your annual price; RevenueCat's data across real apps spans 2 to 12 times annual, from Calm at roughly 5x to Waking Up at over 11x, and their advice when unsure is to price higher, not lower. Before you add it, look at your lifetime value by cohort, not the average, so you know what you are giving up.

Weekly, with caution. A weekly subscription converts, because a small number looks harmless and it fits paid-acquisition math. It is also the pattern users most associate with predatory apps, and it draws one-star reviews and refund requests. I would reserve it for genuinely short-use, high-churn utilities, and think hard about your brand before defaulting to it. Converting well and being trusted are not the same thing.

Pair the plans with a trial. A free trial is how most subscription apps convert the first payment. Length is its own debate, 3 versus 7 versus 14 days, and the honest answer is it depends on how fast your app proves its value. The trial and offer mechanics are covered in introductory offers for app subscriptions.

If you want the numbers behind that debate, the 2026 free trial conversion benchmarks break the rates down by trial length.

How much should you actually charge?

Now the literal question: what is the number. There is no universal answer, but there are useful anchors. Indie subscription apps commonly sit in the low single digits to about ten dollars a month, a few tens of dollars a year, and a lifetime price that is a multiple of the annual. Start from the value you deliver and the market you sell to, not a screenshot of a competitor's paywall.

Before you agonize over the exact number, it is worth seeing how much subscription apps actually make: most never clear $1,000 a month, and what separates the ones that do is a handful of pricing decisions.

Then there is the mechanical question that trips people up, the one you see on Reddit as "does my price have to end in .99." On the App Store you pick from a fixed ladder of price points, expanded in recent years to roughly 900 of them. It no longer has to end in .99. Apple added ten-cent steps between about 0.29 and 9.99 dollars, plus endings like .00, .90, and .95, so a price point like 2.49 or 7.39 is valid now. Charm pricing, the .99 ending, still nudges conversion a little, but you are no longer forced into it. Google Play is more flexible and follows similar conventions.

The trap in this step is obsessing over 6.99 versus 7.99 in your home market. That gap is rounding error next to the one you are about to create in every other country by skipping the next decision.

The step almost nobody does: localize per country

This is the step the threads rarely mention until someone asks why so few developers bother. Whatever number you picked, you picked it in one currency for one market. When your app shows up in other countries, the stores do not localize that price. They convert it.

Apple auto-generates the other storefronts by equalizing them to your base at the current exchange rate, and Google Play does the same by auto-conversion. Both add local tax and stop there. A converted price is not a localized one. Nine dollars and ninety-nine cents of spending power in the United States is a much bigger ask in India, Brazil, or Indonesia, so a straight conversion routinely lands two to three times too high relative to local purchasing power. A fair price in India is closer to a third of the US number, not a near-full conversion of it.

Because almost nobody does this, doing it is an edge. The pre-registrants and installs you earn in high-population, lower-income markets are exactly the ones a converted price scares off before checkout. The full argument and method are in the app pricing localization guide, the execution is in the complete guide to localized pricing, and the country reference is App Store pricing by country. If you sell subscriptions, localized pricing 101 for subscription apps is the focused version.

If you want proof this is worth the effort, here is the evidence that parity pricing grows app sales, from revenue-per-install data to what companies like Spotify and Netflix do in India.

Setting it, changing it, and keeping it

The last part is operational. You apply your prices per country in the console, once for each product, in both stores. Here is how to change a price in App Store Connect, and Google Play is a separate job.

Two things come up constantly once you are live. First, raising prices: a question I see every week is whether increasing a subscription price hits existing subscribers. On the App Store you choose. You can apply the increase, which triggers a notice or, above certain thresholds, a request for the subscriber's consent, or you can keep existing subscribers on their current price and charge only new ones more. Google Play works similarly. Second, price changes are not one-and-done, because exchange rates and local economies keep moving, so treat them as versioned changes with history and a rollback path rather than blind edits.

I wrote the full playbook for that in a separate guide on how to raise your price without losing subscribers, including how grandfathering works differently on the App Store and Google Play.

That maintenance, per country, per product, across two stores, forever, is why most developers localize once and then never touch it again.

A pricing checklist

To pull it together, here is the order I would work in:

1. Pick the model that matches how your app delivers value.
2. Choose your billing periods. Offer monthly and annual, anchor the annual at about two months free, add lifetime only if you have priced it high enough not to cannibalize renewers, and use weekly only for short-use utilities.
3. Set the number from your value and market, inside the store's price points.
4. Add a trial that matches how fast your app proves itself.
5. Localize every price to each country's purchasing power, not a raw conversion.
6. Apply it in both stores, and revisit it as rates move.

Steps 5 and 6 are the ones that eat a weekend by hand, across 190-plus countries and two consoles, which is why most people skip them and ship on raw conversions. That is the job PricePush does. It calculates purchasing-power-aligned prices for 190+ countries, not raw conversions of your home price, and pushes them to both the App Store and Google Play in one step. You can try it free on one app and see your own per-country prices before you change anything, and the plans plus the founding lifetime offer are on the pricing page.

Frequently asked questions