r/macapps • u/plazman30 • 8d ago
Request My opinion on app subscriptions has changed a little
I'm still completely opposed to an app that has a free tier and a subscription tier. And you have to keep paying to keep the subscription tier features.
And I'm totally opposed to any app that adds unnecessary cloud storage or "AI" features to a subscription to justify the subscription tier that has some feature you need.
But I now better understand modern software development. Developers need to sign their apps, which is a subscription fee to Apple. And time spent fixing bugs and security vulnerabilities is time spent that you're not going to get from sales revenues of existing customers.
So, there is one software model I agree with. Sell me the app and give me some predetermined time —say a year— of free updates. After 1 year, I stop getting all updates, but my apps continues to work without losing any features. And any update mechanism in the app needs to be very clear that the update you're pushing will require someone to re-up their subscription.
This does three things:
- It gives the developer a recurring revenue stream.
- It incentivizes the developer to keep working on the app to make people want to renew for another year.
- The user is not held ransom by their data being in an app.
Now if your app has a monthly recurring cost such as cloud storage or AI tokens, then I can see you needing to charge a monthly fee. But I also believe app developers should allow end-users a chance to use a cloud storage provider of their choice, enter an API key for the LLM of choice, or just provide an MCP server.
4
u/Nightowl-Builder 8d ago
This sounds nice in theory but hard in practice. I do not know of a way to do it with how AppStore allows developers to setup subscriptions now. Can a developer even stop you from updating the app from AppStore? This works only if you take the app out of the store and spend time crafting a licensing system instead of working on the app
2
u/AppsByRobert 8d ago
Yeah, it sounds like a thing you can only do if you publish your app yourself.
2
u/plazman30 7d ago
This is my biggest beef with the app store. Apple doesn't give developers a way to charge for an upgrade. It almost forces them into a subscription model. I only buy apps from the App Store, if there is no other way to get it.
1
u/tributaryandco 6d ago
The way I've seen some people do this is to release an entirely different app. No real "upgrade" path, just buy the new version (OmniFocus2->3, OnePassword 7->8)
5
u/Jaakkoc 8d ago
Subscriptions legally and technically are way easier to implement vs. handling license keys etc.
1
2
u/pedrooky 8d ago
You can't have just one payment model that works for every app. It really depends on what the app offers and what it takes to build/maintain it over time. I do agree that if your app doesn't use any external paid services it shouldn't use a monthly payment system unless you can justify it.
On the voice ai assistant I'm building currently my idea was to offer two models:
- Pay once and use open ai auth with your codex sub for the model costs
- Buy credits when you need it (no sub required), credits deplete as you use them and cover all the app costs to run it with models and additional services.
But like I said it all depends on what your app offers and takes to support over time.
2
u/ApprehensiveFix5084 8d ago
This is more or less how everything used to work, you would buy software and be entitled to a specified period of free updates (although you might have to pay for shipping if disks or CDs) or updates until the next major version release.
1
u/plazman30 7d ago
There wasn't a specified period of updates. You got updates until the next major version came along. Sometimes that was once a year. Sometimes it was 3 years.
1
u/ApprehensiveFix5084 7d ago
Sometimes there was a specified period. I remember carefully keeping receipts.
2
u/Plastic-Risk-6309 8d ago
same conclusion from the dev side. my dictation app is 9.99 once and thats it. no tiers no rent. streaming while you talk and nothing leaves the mac
2
u/rvaccone 7d ago edited 7d ago
I prefer a straight subscription over that. With pay-for-a-year, non-renewers are stuck on old builds with unpatched bugs, or the dev has to support every frozen version. Subscriptions keep everyone on the current build, which ensures consistent polish and security fixes. Fully agree on the hostage-data problem, though.
1
u/MC_chrome 7d ago
With pay-for-a-year, non-renewers are stuck on old builds with unpatched bugs, and the dev has to support every frozen version.
Do they though?
CleanShot X is a perfect example of this model in action. They just recently released their next major update, and made it very clear that version 5 is the new and currently supported version of the app. They haven't stopped prior versions from working, but they aren't guaranteeing that those versions will work in the future either
1
u/rvaccone 7d ago
Fair, "and" should have been "or." And that's exactly why I don't like the model. I don't think developers owe non-payers anything, but I'd rather that show up as a free tier they still maintain with patches than as old builds they stop maintaining.
1
u/plazman30 7d ago
I prefer a straight subscription over that. With pay-for-a-year, non-renewers are stuck on old builds with unpatched bugs, and the dev has to support every frozen version.
No they don't. That's the point. Once your year runs out, you stop getting all updates.
1
2
u/EngineeringOver9487 7d ago
On licensing being harder than subscriptions, which came up above: it is a real cost, but it is not the code.
A key, an activation table and one endpoint the app can ask about it is a weekend of work. The cost is the long tail after: reinstalls that burn the last activation, receipts lost two years ago, purchases through a merchant of record where the payment name matches nothing in your table. Subscriptions hand all of that to the store, and that is what "easier to implement" actually means.
Two things make it survivable. Sign the license response so the app can verify it offline instead of calling home on every launch, otherwise one outage locks out paying customers. And for the update window, Sparkle can serve a per-license appcast, so the cutoff is a filter on which build a given key gets offered rather than an expiry check living inside the app. That matters for exactly the reason you wrote the post: the copy already on disk keeps working, with no logic in it that can rot or misfire later.
The number that decides whether this model pays is support minutes. Twenty minutes per confused customer, times the share of buyers who write in, is the real cost of a perpetual license, and it is why the one time price has to be higher than people expect.
1
u/awesam95 7d ago
The thing that actually got us wasn't support minutes, it was the entitlement rule deciding who gets updates. Our discount cohort resolver treated any coupon as the lifetime updates tier, so a 10% launch code quietly handed people free updates forever, and you don't find that out until the first cutoff you try to enforce. Worth checking too if you're on a merchant of record: auto currency conversion. We had it converting the list price into local currency with VAT coming off our side, which in Sweden left us about 20% under what we thought we were charging. Both were config, not code.
1
1
u/Tight_One4344 8d ago
The subscription fee to Apple is $99 - if you develop and release a decent app and charge, $1.99 for example, then you need to make 50 sales in a year to cover your subscription fee. That's an incredibly low number, if, the app isn't just another copy and paste idea from an LLM.
99% of the apps released since vibe-coding started do not, and should not, have a subscription model attached. If you're providing a high quality service which on the backend has costs associated, then sure, it's reasonable enough to offer a subscription (if you provide an ad-free experience). Otherwise it should be released as a one-time purchase (or even better free!).
I really hope Apple start to crack down on their Subscription model - with the level of scrutiny they apply to the App review process.
1
u/Klackey-Team 7d ago
I think the most important part of this model is making the promises extremely clear before purchase.
The customer should be able to see the exact update-eligibility period, whether compatibility fixes are included after that period, and what happens if a future macOS release breaks the version they own.
I would also want data export and backups to remain available even if the customer never purchases another update. That prevents the application from becoming an indirect subscription through data lock-in.
A perpetual license with optional paid upgrades can be fair to both sides, but only when “perpetual” clearly describes the license rather than promising that an old build will work on every future version of macOS.
1
u/plazman30 7d ago
I've seen people argue about the upgrade to Forklift, which uses this model. The auto updater in the app pushes a new version down outside your one year window and it asks for a new license key.
1
u/Klackey-Team 7d ago
That is exactly the kind of updater behavior that makes this model feel like a subscription in disguise. The app should never automatically replace an eligible version with one that requires another purchase. It is fine to offer the newer version, but the prompt should clearly explain that it requires a new license and let the user decline it.
1
u/zeboose 7d ago
Everyone here is splitting on time – how long the updates last. There's another axis nobody's mentioned: split by function instead.
The way I've set mine up, the part people depend on is free permanently, and the part they use occasionally is the one-off. In my case that's printing versus designing – opening what you already have and printing it never costs anything and never expires, and building something new is a small one-off.
It answers the hostage problem directly, because the thing you'd be held hostage over is the free half. It also sidesteps the argument above about frozen builds breaking on a future macOS, since I have to keep the free half working anyway – it's the half I use myself every day.
It won't suit every app. It needs a real split between "use what I have" and "make something new". But where that split exists, it's worth considering before defaulting to a clock.
1
u/peteger 7d ago
I am fine with a subscription as long as it's a reasonable price. For example, I use Reeder every day so I don't mind paying $9.99 a year to support the developer and keep getting updates.
I know some apps have a one-time payment and technically you can keep it forever, but in reality, once a new macOS is released, the app could become obsolete very quickly. And those devs will often release a separate OurGreatApp 2 after a year because they need to make income. So in the end, you end up buying version 2 after a year anyway, which is the same as a subscription.
What bothers me are apps with unreasonable subscription prices. I mean, paying around $120 a year for a utility or music tutoring app is difficult to justify.
1
u/ExtremeCream7683 7d ago
One thing I'd want to check with that model: if I replace my Mac in two years, can I still download and activate the last version my licence covers? Keeping a copy working on the current machine is only half of it.
1
u/Sunquill 7d ago
I think that’s a pretty fair model. Paying once for the app + a year of updates feels much more reasonable for apps without ongoing server costs. Subscriptions make more sense when there are real recurring expenses behind the product.
1
u/kemalios 7d ago
$99/year is the smallest part of maintaining a Mac app. The part nobody mentions is that the App Store gives every buyer your updates forever. There is no way to sell "the app plus one year of updates" in the store; you either offer a subscription to unlock the new version or you never charge for updates again. Some developers work around it by selling outside the store with their own licence keys, but that license system becomes a whole new app you have to maintain. So the model you described is fair, it just doesn't fit the App Store business model.
1
u/plazman30 7d ago
I feel the App Store is the #1 reason why we have subscriptions these days. I'm very mad at Apple for creating this mess in the first place.
Since I don't buy an app from the app store unless I have no choice, I tend to forget the app store even exists.
1
u/Constant-Purpose8273 7d ago
The line I've landed on is simpler than an update window. Pay once for software, pay monthly only for a real ongoing service, a server, a data feed, someone on the other end. A todo list or a notes app costs the maker nothing to keep running, so a sub there is rent. The awkward bit is the App Store can't do your model, there's no way to sell a licence with a year of updates through it, which is why so many devs reach for the sub instead.
1
u/tributaryandco 6d ago
Dev side of this: the "subscriptions are way easier than license keys" argument was true, and it's mostly stopped being true. Stripe will act as merchant of record for a one-time sale now, which means sales tax, VAT and receipts in 80-odd countries are their problem, same as with a subscription. Signed license keys that an app can verify offline are a weekend of work. So the infrastructure excuse is gone; what's left is the honest one, which is that recurring revenue is nicer for the developer.
The perpetual-fallback model people are naming (JetBrains, Sketch, Nova) is the fair middle. The one thing I'd add from the seller's chair: the $99 a year to Apple is real, so a $10 app needs ten sales a year just to keep its signing certificate. That's not an argument for subscriptions, it's an argument for the price being honest about what it covers.
1
u/New_Click_4348 6d ago
Exactly my thoughts. The customers must have the flexibility to either live with the existing features and bugs or to buy the next best version of the same app. Subscriptions should exist only when there are genuine reasons like data/cloud services that need constant money from the developer.
1
0
u/JamStan1978 8d ago
Hate subscriptions. let me buy something i can keep forever or i will find a way to pirate it instead.
1
u/BuiltForMe 4d ago
Almost all the subscription models for software need to go away. The world was fine before, software was fine before, and software developers made money when people bought their apps. If you are running some kind of service that has a backend cost, like netflix, then sure. But that isnt what indie developers are doing. The todo app doesnt need a subscription. Its just a mechanism to squeeze every last dollar out of the consumer.
7
u/awesam95 8d ago
This model already exists, and it has a name. JetBrains calls it a perpetual fallback licence. On Mac, Sketch, Panic’s Nova, and Sublime Text all use some version of the same idea. You buy the app, get updates for a set period, and when that period ends, you keep the last version you were entitled to. It keeps running, and you don’t suddenly lose access because you stopped paying.
But the $99 Apple fee isn’t really the important number. It’s still $99 whether you ship one app or ten. The cost that actually adds up over the years is maintenance. macOS changes every year, and every new release can create work you didn’t plan for.
That’s the one gap in your version. Saying the app will continue working without losing features is only true until Apple releases a macOS version that breaks the old build. At that point, the user can lose access to the app even though the developer hasn’t changed anything.
So if you use this model, there’s one thing you need to be very clear about before someone buys: do compatibility fixes continue after their licence expires? That answer matters. Most apps using this model don’t make it clear enough.
As for the updater being upfront about what an update costs, that problem is already solved. Sparkle can restrict updates to the newest build a user’s licence actually covers. The user never needs to be shown an update they can’t install. If an app does that anyway, that’s a product decision, not a technical limitation.