How Should You Price Your App for Maximum Downloads?
TikTok launched in most markets as a completely free app with no upfront cost, no subscription, and initially very few ads. Within two years it had been downloaded over a billion times and became one of the most valuable apps in the world. Meanwhile, plenty of paid apps with arguably better features sit at the bottom of the app store charts with a few hundred downloads total. The difference? Pricing strategy, and honestly, its more complicated than just slapping a price tag on your app and hoping for the best.
I've watched countless clients struggle with this exact question—should they charge upfront, go free with ads, or try something in between? And here's what I've learned after working on apps across healthcare, fintech, and e-commerce; there's no universal answer, but there are definitely patterns that work. The apps that succeed understand something basic about human behaviour; people hate paying for things they havent tried yet. They just do. You could have the most brilliant meditation app ever built, but asking someone to pay £4.99 upfront means you're competing with thousands of free alternatives, and most users won't even bother reading your description.
The price you choose isn't just about revenue—it directly impacts how many people will even consider downloading your app in the first place
But going free isn't automatically the right choice either. I've seen apps go from healthy paid downloads to free overnight, expecting a massive surge in users, only to find that their revenue completely collapsed without enough people converting to premium features. The truth is that pricing affects everything from your app store visibility to the quality of users you attract to how quickly you can sustain engagement after launch. Getting it wrong can kill an otherwise brilliant app before it has a chance to prove itself. Getting it right? That's when things get interesting.
Understanding App Store Economics
Here's something most people don't realise when they first think about app pricing—the app stores themselves take a significant chunk of every transaction. Apple and Google both take 30% of any app sale or in-app purchase for the first year, dropping to 15% after a user's been subscribed for over 12 months. That means if you price your app at £2.99, you're only seeing around £2.09 hit your account. And that's before taxes, payment processing fees, and any other costs. Its a bit mad really, but this is the ecosystem we're working in.
I've watched the economics shift dramatically over the years; what used to work back when the App Store was younger just doesn't apply anymore. The average paid app now gets fewer than 1,000 downloads in its lifetime, which means if you're charging £2.99 and manage to hit that average, you're looking at roughly £2,090 in revenue before any development costs. This is why the paid-upfront model has basically died for most categories—the numbers simply don't work unless you've got a massive marketing budget or an existing audience.
The Reality of User Acquisition Costs
User acquisition is where things get properly expensive. I've seen clients spend anywhere from £1.50 for a casual game user to £15+ for a fintech app user, depending on the target market. If you're charging £0.99 for your app upfront, you can see the problem straight away. You're losing money on every single download through paid advertising. This is exactly why most successful apps I've built over the years have moved to free downloads with monetisation strategies that demonstrate clear business value—through subscriptions, in-app purchases, or other methods we'll explore in the next chapters.
Platform Differences Matter
One thing that constantly surprises new clients is how different iOS and Android users behave when it comes to spending. iOS users, on average, spend about 2.5 times more on apps than Android users do. I saw this clearly when working on a meditation app where we launched on both platforms simultaneously—same features, same pricing model. The iOS version generated 68% of our revenue despite accounting for only 45% of downloads. This doesn't mean you should ignore Android (definitely don't!), but it does mean your pricing strategy might need to differ between platforms.
The economics also change based on your app category. Entertainment and gaming apps can get away with impulse purchases at lower price points because users are already in a spending mindset. But productivity apps? Business tools? Those need to justify their value proposition much more clearly, which often means either going completely free with a premium tier or offering a generous trial period. I've built apps in both categories and the purchasing psychology is completely different.
| App Category | Average Price Point | Typical Conversion Rate |
|---|---|---|
| Games | Free + IAP | 2-5% |
| Productivity | £2.99-£9.99 | 0.5-2% |
| Health & Fitness | Free + Subscription | 3-8% |
| Business Tools | £4.99-£19.99 | 1-3% |
Understanding these economics upfront changes how you think about your entire pricing strategy. You need to know your numbers before you even start thinking about what to charge, because the app store economics will fundamentally shape what's actually viable for your specific situation.
Free vs Paid: Which Actually Works Better?
Look, I'll give it to you straight—paid apps are basically dead for most use cases. In all my years building apps, I've watched the paid app model shrink to represent less than 5% of total downloads across the major app stores. It's a bit mad really, because back when I started, charging £2.99 upfront was completely normal. These days? People expect apps to be free, and they'll abandon your download page faster than you can say "value proposition" if they see a price tag.
But here's the thing—there are still specific scenarios where paid apps work brilliantly. I've built apps for professional tools, specialist B2B software, and niche productivity apps where users actually prefer paying upfront. Why? Because it signals quality and commitment. When a physiotherapy practice wanted an app for their practitioners to use during consultations, we priced it at £49.99. Sounds crazy, right? But it worked because the target users weren't consumers—they were professionals who needed a reliable tool and were happy to expense it. The conversion rate was lower, sure, but the revenue per download was significantly higher and we didn't need to worry about complex in-app purchase flows or subscription management.
When Free Makes Sense
Free apps dominate for consumer-facing products, social platforms, content apps, and anything where network effects matter. If you need millions of users to make your business model work, charging upfront is basically suicide. I worked on a fitness app where we debated charging £4.99 upfront versus going free with premium features—we ran the numbers and realised that even with a 10% conversion rate on the paid version, we'd need the free version to convert just 0.5% of users to premium subscriptions to break even. The free model won by a landslide.
The Hybrid Approach
Some apps use what I call the "trial-then-paid" model, which isn't quite the same as freemium. You offer the full app free for 7-14 days, then require payment to continue. This works well for apps with immediate, obvious value—things like meditation apps, advanced photo editors, or business tools. The challenge is that Apple and Google have made this harder to implement cleanly; you basically need to use their subscription systems even for what's essentially a one-time purchase.
The decision between free and paid should be made before you write a single line of code, not after. Your entire user experience, feature set, and technical architecture will differ based on this choice. I've seen too many teams try to retrofit a monetisation model after launch, and it never goes well.
| Model | Best For | Typical Conversion | Development Complexity |
|---|---|---|---|
| Paid Upfront | Professional tools, B2B apps, niche utilities | 0.1-2% of visitors | Low |
| Free (ad-supported) | Content apps, games, casual utilities | N/A | Medium |
| Free (with IAP) | Consumer apps, productivity tools | 2-5% to paying | High |
| Freemium | SaaS, subscription services | 1-3% to premium | Very High |
The data from projects I've worked on shows something interesting—paid apps actually have better retention rates than free apps, but obviously far fewer total users. A healthcare app we built had a 78% 30-day retention rate because users had paid £6.99 and felt invested in using it. Compare that to a free meditation app where we struggled to keep retention above 15% even with push notifications and email campaigns. People value what they pay for, its just basic psychology.
One mistake I see constantly is developers thinking they can "test" pricing by launching paid and then switching to free if it doesn't work. That's backwards. Going from paid to free looks desperate and trains users to wait for apps to go free. I worked with a client who did exactly this—launched at £3.99, panicked after two weeks of poor downloads, then switched to free. The reviews were full of angry users who'd paid asking for refunds. Not a good look.
The Freemium Model Explained
Freemium is basically when you give away your app for free but charge for extra features, and I've built dozens of these over the years. Its the most common monetisation strategy I see clients choosing, and for good reason—it removes the barrier to entry completely. But here's the thing, understanding which features will generate revenue is harder than most people think.
The key question you need to answer is this: what do you give away for free, and what do you charge for? I worked on a fitness app where we got this balance totally wrong at first. We gave away all the workout plans for free and tried to charge for progress tracking. Downloads were great, conversions were terrible. Turns out people wanted the basic tracking for free and would happily pay for premium workouts. We flipped it around and revenue jumped by 340%. The free version needs to be genuinely useful—not just a glorified advertisement for the paid version—but it also needs to leave users wanting more.
Most successful freemium apps follow one of these patterns: they limit usage (like Duolingo's heart system), restrict features (Spotify's no-skip limit), add premium content (meditation apps with extra courses), or remove friction points (productivity apps that sync across devices). The percentage of free users who convert to paid typically sits between 2-5%, which means you need serious download numbers to make this work financially.
Common Freemium Structures That Actually Work
- Feature limitations—core functionality free, advanced tools paid (calendar apps with basic scheduling free, team features paid)
- Content libraries—some content free, premium content behind paywall (recipe apps with 50 free recipes, 500 paid)
- Usage caps—limited free uses per day or month (photo editing with 5 exports monthly for free)
- Time-based trials—full access for limited period, then downgrade to basic (project management tools with 30-day premium trials)
- Ads vs ad-free—free version shows ads, paid removes them (this works better as a secondary benefit rather than the main value proposition)
The timing of when you ask users to upgrade matters more than you'd think. Push too early and you'll annoy them before they've seen the value; wait too long and they've already solved their problem with the free version. I usually recommend waiting until users have experienced at least three successful sessions with your app before showing upgrade prompts—they need to understand what they're paying for first.
In-App Purchases and Subscription Pricing
I've worked with dozens of apps that shifted from one-time purchases to subscription models, and the results vary wildly depending on how you structure things. A fitness app I built a few years back started with a £4.99 one-time purchase—decent downloads but the revenue flatlined after six months. We switched to a subscription model at £7.99 monthly or £49.99 annually, and within three months the revenue had tripled. But here's what really mattered: we had to give people a compelling reason to subscribe every single month, not just unlock features once.
The biggest mistake I see with in-app purchases is offering too many options too soon. People get overwhelmed and buy nothing. I worked on an education app where we initially had 12 different purchase tiers ranging from 99p to £29.99. Conversion rate was terrible, like 2.1%. We simplified it down to three clear options—a small purchase at £2.99, a popular mid-tier at £7.99, and a premium bundle at £14.99—and conversions jumped to 8.3%. Sometimes less really is more, you know?
The sweet spot for consumer subscriptions tends to sit between £6.99 and £9.99 monthly, though B2B apps can charge significantly more if the value proposition is clear
Annual vs Monthly Subscriptions
Always offer both if you're going the subscription route. I mean, some users want the commitment discount whilst others prefer flexibility. The trick is pricing your annual plan at roughly 10 months worth of monthly fees—it creates a clear saving without devaluing your monthly option. A healthcare app I worked on used £8.99 monthly and £89.99 annually; about 40% of subscribers chose annual, which meant better cash flow and lower churn.
Consumable vs Non-Consumable Purchases
Non-consumable purchases (unlock features forever) work well for utility apps where users need functionality once and done. Consumable purchases (coins, credits, extra lives) suit gaming and content apps where repeat purchases make sense. I built a language learning app that mixed both—£9.99 to unlock all courses permanently, plus optional consumable "tutor sessions" at £2.99 each. The consumables actually generated 60% more revenue over time because engaged users kept coming back for more sessions.
Regional Pricing Strategies
Here's something most developers get completely wrong—they set one price in their home market and just let Apple and Google convert it automatically for other regions. I mean, technically it works, but you're leaving serious money on the table. When we launched a fitness app for a client a few years back, we initially set it at £2.99 in the UK and let the stores do their thing. Downloads in India were dismal. We're talking maybe 20-30 per week. Once we adjusted pricing to match local purchasing power (dropping to about 80 rupees, which was roughly £0.75 at the time), downloads jumped to over 400 weekly. Same app, same marketing—just smarter pricing.
The thing is, purchasing power varies wildly across regions and you need to account for that if you want global success. An app priced at £4.99 might seem reasonable to someone in London or New York, but thats nearly a day's wages in parts of Southeast Asia or Eastern Europe. Apple and Google both let you set custom prices for different storefronts, and honestly? You should be using this feature from day one.
What Actually Works in Different Markets
From what I've seen, Western markets (UK, US, Australia, Canada) can support higher price points—especially for productivity or professional apps. People there are used to paying for software. But in markets like Brazil, India, Indonesia and much of Africa, you need to price more aggressively. We typically price apps 40-60% lower in these regions compared to UK pricing. Its not just about conversion rates either; the lifetime value calculations change completely when you factor in different subscription renewal rates across regions.
The Technical Side Nobody Mentions
Setting up regional pricing isn't difficult but it does require some planning. Both App Store Connect and Google Play Console let you set price tiers for every country they operate in. The mistake I see constantly is developers who change their base price and forget to update all their regional variations—suddenly your app costs more in India than it does in the UK, which makes absolutely no sense. Set calendar reminders to review your pricing quarterly because exchange rates shift and what made sense six months ago might not work today.
One more thing—watch out for psychological price points in different cultures. In the US, prices ending in .99 work well because people have been conditioned to see them as deals. But in some European markets, round numbers are actually preferred because they seem more honest and straightforward. We tested this with an e-commerce app across German and French markets; round pricing (€5 instead of €4.99) actually performed about 8% better in conversions. Its a small detail but when you're operating at scale, these things add up.
Testing Your Price Point
Here's something most app developers get wrong—they pick a price and stick with it forever, hoping for the best. I've watched apps struggle for months simply because the founder was convinced their app was worth £4.99 when the market was telling them otherwise. The smart approach? Test your pricing like you'd test any other feature of your app, because pricing isn't a decision you make once and forget about.
When we built a fitness tracking app a few years back, we launched at £2.99 thinking it was reasonable. Downloads were ok but not great. We dropped it to 99p for two weeks as an experiment and downloads increased by 340%. Not a typo. The interesting bit though was what happened next—we raised it back to £1.99 (a middle ground) and downloads actually stayed strong because we'd built up momentum in the rankings. That initial price test gave us data we could never have guessed at.
Most app stores dont make A/B testing prices easy, which is bloody annoying if I'm honest. You cant show one user £1.99 and another £2.99 for the same app. So you need to test sequentially; try one price for a set period (I usually recommend minimum two weeks to account for weekly fluctuations), track your metrics carefully, then adjust. The key metrics you want to watch are total revenue (not just downloads), conversion rate from page views to downloads, and how many people actually use the app after purchasing.
What to Track During Price Tests
- Daily download numbers and conversion rates from impressions
- Total revenue per day (downloads multiplied by price obviously)
- User engagement metrics after purchase to spot quality issues
- Refund rates which can spike if people feel they've overpaid
- App store ranking changes in your category
Regional pricing tests are worth doing too. I've worked on apps where UK users were happy paying £3.99 but users in other European markets needed a lower entry point. You can set different prices for different territories, and its worth testing whether a premium price in wealthy markets subsidises lower prices elsewhere. One education app we developed charged £4.99 in the UK and US but only £1.99 in emerging markets, and that strategy more than doubled our global user base without cannibalising our revenue.
Never test prices during major holidays or App Store feature periods—you'll get skewed data that doesn't represent normal user behaviour. Wait for a stable period when you can isolate the pricing variable from other factors.
The mistake I see constantly is developers testing for too short a period or not tracking the right metrics. Sure, dropping your price to 99p might triple your downloads, but if those users never open the app again its worthless growth. I'd rather have 100 engaged users who paid £2.99 than 500 users who paid 99p and churned immediately. Context matters here though; if you're trying to climb the charts quickly to get featured, volume might matter more than engagement in the short term.
Common Pricing Mistakes to Avoid
I've watched so many brilliant apps fail because of pricing errors that could have been avoided. It's frustrating because the app itself was solid—the design was spot on, the functionality worked perfectly, but the pricing strategy killed it before it had a chance. The biggest mistake? Underpricing because you're scared nobody will download it. I get it, really, but setting your app at 99p when it should be £4.99 doesn't make you more appealing; it makes people wonder whats wrong with it. We launched a productivity app once where the client insisted on pricing it at £1.99 instead of the £6.99 we recommended—downloads were higher initially but revenue was terrible and the low price attracted users who didn't value the app enough to actually use it regularly.
Another massive error is changing your price too frequently. You might think experimenting is smart but it confuses your audience and destroys trust. I worked on a fitness app where the founder changed prices every fortnight trying to find the "perfect" number—existing users felt cheated when they saw it cheaper later and potential customers waited for sales instead of buying. Pick a price, commit to it for at least three months, then analyse the data properly before making changes.
The third mistake that drives me mad is ignoring regional pricing altogether. Setting your app at £4.99 in the UK and letting Apple automatically convert that to other currencies without considering local purchasing power is lazy frankly. An app priced at $4.99 in the US might need to be $2.99 in Brazil or $1.99 in India to get any traction. I've seen download rates increase by 300% in emerging markets just by adjusting regional pricing to match what people can actually afford in those countries. And here's something most developers miss—you need to factor in refund rates too because if your pricing doesn't match perceived value, people will request refunds and that damages your App Store reputation more than a bad review.
How Pricing Affects Your App Store Ranking
Here's something most people dont realise—your pricing model has a massive impact on how the App Store and Google Play algorithms treat your app. I learned this the hard way working with a fitness client who insisted on launching at £7.99 because they'd seen competitors at that price point. Downloads tanked, engagement was low, and within three weeks their search ranking had dropped significantly. Not just because of the price itself, but because the algorithm saw poor conversion rates from impressions to downloads.
Both major app stores use machine learning to predict which apps users are likely to download and engage with; pricing plays directly into this. When someone searches for "budget tracker" and your app costs £4.99 whilst three others are free, the algorithm learns that fewer people click through to your listing. Lower click-through rates signal to the store that your app isn't relevant, which pushes you down in search results. Its a vicious cycle really.
The app stores don't just rank based on what users download—they rank based on what they predict users will download based on historical behaviour patterns.
Free apps naturally get more downloads, which generates more reviews (good and bad), more engagement data, and more signals for the algorithm to work with. I've seen healthcare apps switch from £2.99 to free with in-app purchases and jump 40-50 positions in category rankings within weeks. The increased download velocity alone gives you algorithmic momentum. But here's the thing—you need to convert those free downloads into engaged users quickly or the algorithm sees high uninstall rates and abandonment, which can actually hurt you more than having fewer downloads at a premium price. The sweet spot? Free to download with a clear value proposition that encourages in-app purchases or subscriptions within the first session or two.
Conclusion
Pricing your app isn't something you do once and forget about—its an ongoing process that needs attention, testing, and honestly, a bit of courage to change things when they're not working. I've seen too many developers (including myself early on) launch with a price, watch it fail, and then stubbornly stick with it because changing feels like admitting defeat. But here's the thing; the best apps I've worked on have all tested multiple pricing strategies before finding what actually works for their specific audience.
The real secret? There isn't one perfect answer that works for everyone. A productivity app for freelancers needs a completely different approach than a mobile game or a healthcare tracking app. What works in the UK might bomb in India or Brazil because purchasing power varies so much between regions. And subscription models that seem logical on paper often fall apart when you realise users don't perceive enough ongoing value to justify monthly payments.
Start with free if you can afford to build an audience first—paid upfront is bloody difficult unless you've got serious marketing budget or an established brand already. Test your pricing every few months, watch your conversion rates like a hawk, and don't be afraid to pivot when the data tells you something isn't working. I've had apps that started free, moved to freemium, then eventually to subscription... and each transition taught us more about what our users actually valued.
The apps that succeed long-term are the ones where pricing reflects genuine value, not just what the developer hopes they can charge. Keep testing, stay flexible, and remember that getting downloads is only half the battle; keeping users engaged enough to pay is where the real work begins.
Frequently Asked Questions
From building apps across multiple industries, I'd recommend free for almost all consumer-facing apps—paid upfront typically gets fewer than 1,000 downloads lifetime and can't compete with user acquisition costs. The exception is professional B2B tools where I've successfully charged £49.99+ because businesses expense quality software and aren't price-shopping against free alternatives.
In my experience across dozens of freemium apps, expect 2-5% conversion rates from free to paid users, though this varies massively by category. I've seen fitness apps hit 8% conversion with good engagement flows, whilst casual utility apps struggle to reach 1%—you need serious download numbers to make freemium financially viable.
Track your conversion rate from app store page views to downloads—if it's below 15% for a paid app, you're likely overpriced for your market. I always test prices for minimum two-week periods and watch total revenue, not just downloads, since tripling downloads at half the price doesn't help if engagement drops.
Absolutely—I've seen apps increase downloads by 300% in emerging markets just by adjusting for local purchasing power. What works as £4.99 in the UK typically needs to be 40-60% lower in markets like India or Brazil, and you can set these regional prices directly in both app stores.
Wait until users have experienced at least three successful sessions with your app before showing upgrade prompts—they need to understand the value first. I've found that pushing too early annoys users whilst waiting too long means they've already solved their problem with the free version.
Test pricing every 3-4 months maximum, not more frequently—I've worked with founders who changed prices fortnightly and destroyed user trust whilst confusing the app store algorithms. Pick a price, commit for at least three months, then analyse proper data before making changes based on revenue trends, not daily fluctuations.
For most apps, yes—I've seen fitness apps triple revenue switching from £4.99 one-time to £7.99 monthly subscriptions, but only if you provide ongoing value each month. One-time purchases work better for utility apps where users need functionality once, whilst subscriptions suit content apps, productivity tools, and anything requiring regular updates.
Pricing directly impacts conversion rates from searches to downloads, which feeds into the ranking algorithms—if fewer people download your £4.99 app versus free competitors, the algorithm learns your app is "less relevant" and drops your search ranking. I've seen apps jump 40-50 positions in category rankings within weeks of switching from paid to free with in-app purchases.
Share this
Subscribe To Our Learning Centre
You May Also Like
These Related Guides

How Do Apps Make Money?

How Do I Find Out What Price Users Will Pay for My App?



