[AlexandrB]

Apple has quietly been one of the biggest culprits in the proliferation of subscription software. They still don't support upgrades/upgrade pricing. Subscriptions are also the easiest way to implement a software demo or trial in the App Store. Finally they use their control of the App Store to coerce anyone doing something different than monthly/yearly subscriptions into that model (as we see here).

It sucks big time.

[baby]

I really hate how the current pattern is

1. Download seemingly cool app on iOS (free with potential payments)

2. Go through a 30min quizz

3. Required to subscribe for $150/year to start using the app

It’s not free, it’s false advertising

[TheKarateKid]

Funny how UX only matters to Apple when it doesn't cost them $$

[harry8]

In the days of the ipod every single user of it I encountered had apple's UX wipe their music collection.

But maybe that was by design as they decided to call their music shop by the same name as their ipod management software. That is the essence of Apple's UX. Shiny destruction of your property. It remains so.

The UX everyone wanted was copying files onto and off the device presented as storage on any computer it was plugged in to.

[johnnyanmac]

Maybe that awful ad of Apple destroying perfectly functional instruments was more accurate than I expected.

[nomel]

They added "in app purchases" indicators in the store for this. I use it all the time. "In app purchases" on something that claims it's free is not free.

[05]

Yeah but you can’t filter on it, dark patterns at work.

[TheKarateKid]

Apple's longstanding App Store guidelines always forced a certain level of "quality" and good customer experience, yet they're now allowing apps that are the exact opposite.

Most of these apps use dark UX patterns to trick new users into scammy free trials which convert to $100+/yr subscriptions after 1-3 days. These apps also make it difficult to close out of the subscription window, or make it seem like you have to subscribe when you don't.

It's entirely contradictory to everything Apple once stood for in justifying their gatekeeper App Store experience.

Apple could easily ban these types of scammy UX patterns, but they won't because it benefits them. That's my point.

[Aeolun]

> scammy free trials which convert to $100+/yr subscriptions after 1-3 days

I’m fairly certain this is because it’s the only way of offering a trial that Apple allows?

[zombiwoof]

Yeah I hate how to get Logic Pro on my iPad I have to subscribe not purchase

[daniel_reetz]

Don't forget censorship/banning of nude images. The tumblr fiasco (among others) was their doing.

[nomel]

That's not totally true. Twitter/X is fine, in this regard. The toggle is web based, but there's no censorship once it's toggled. The large amount of age restricted content on YouTube, with nudity, is another example.

[nomel]

It appears that people aren't aware that twitters is a porn app, for many users.

Porn is allowed: https://apnews.com/article/x-twitter-musk-porn-adult-content...

And interest in porn is growing: https://www.independent.co.uk/tech/twitter-crypto-pornograph...

[api]

They've certainly encouraged subscriptions but the big driver is the drive for recurring revenue, which can be valued up to 20X what one-time revenue is valued. In some cases companies with investors are instructed to not even care about non-recurring revenue since it doesn't matter. Revenue is recurring or it doesn't exist.

Recurring revenue has always been highly valued. What changed is that the Internet and modern automated payment networks have made it so much easier to implement recurring revenue models. Now everything can be a subscription and now companies that don't have subscriptions are at a massive valuation and fund raising disadvantage. The more companies figure out how to add recurring revenue, the more companies have to figure out how to add recurring revenue.

This is why your car company, appliance company, etc. is trying to get you to subscribe to something.

[johnnyanmac]

Can you imagine the hellscape Steam would be if they adopted this phlosophy? It may have fundamentally ended PC gaming as we know it. Literally throwing free money away.

>Now everything can be a subscription and now companies that don't have subscriptions are at a massive valuation and fund raising disadvantage

It won't alter this course, but given recent news I sure hope Biden can do one last kick to this stupid model. The biggest reason subscriptions do this is because so many forget to unsubscribe. An issue as old as fiat currency. discouraging recurring subscriptions could be the US's version of GDPR in terms of how utterly devastating it will be to companies.

[derefr]

> They still don't support upgrades/upgrade pricing.

What would this mean, exactly?

You can sell people a demo→full-version permanent unlock as a one-time purchase, same as you can sell DLC in a game.

And you can also have subscription tiers, where you get more features out of the higher tiers of subscriptions.

And you can, in theory, freely mix these — e.g. charging someone a subscription for the base version, and then charging them a one-time fee to unlock a specific feature.

If you want, you could even charge for app features as consumables (just like F2P games do) — where you pay to have a block of credits that you use up, or you pay for one month and then have to buy it again when it runs out.

What's the missing revenue model here?

[saratogacx]

The model is the "old school" model for software sales.

The first version you sell to a user at full price and offer a discount for upgrading (something like 40% off). It lets the customer pick when they feel the value prop is worth the cost and lets you offer a loyalty incentive to the user.

Right now the choice is "keep paying for it to keep working" or "fully price for every upgrade".

[nomad41]

I don’t exactly remember how it went but ~5 years ago Goodnotes 5 came out and they offered a “bundle” of Goodnotes 4 and 5 together at the same price of Goodnotes 5. Maybe owners of version 4 had some kind of discount on the bundle because they already owned half of it?

[zchrykng]

That isn't officially supported and is super error prone. People can end up getting charged more if things don't work perfectly.

[rdsnsca]

Bundles can be used for upgrade pricing, you put the new version up for full price (ie. $20) and and a bundle with the new and old version (ie $30, for a 50% discount on it) for those who own the old version. When you buy a bundle you don't pay for the one you own.

[gcr]

Are there any examples of apps that do that? As a consumer, I haven't ever heard of an app that offers this (e.g. goodnotes, LiquidText, MarginNote, Audulus and Things have new major releases and don't seem to do this)

[refulgentis]

Couple of the old school macOS dev houses tried this once this hack became visible and little birdies said the hack WAI. (ex. OmniGroup)

Since then, people have backed off.

If you're going to this much work to help users workaround Apple nonsense, you really care about helping them save money, and the support + refund costs of people accidentally buying the bundle with the old version they don't need is > just building out your own server-side system, versus a combinatorial explosion of bundles in the App Store that creates a confusing minefield for users.

[refulgentis]

By jumping through hoops, tying unrelated tools together, confusing users, and reaping an extra $10 you didn't want to take + support costs thereof, yes, it is possible. It is not what we expected or asked for when we started asking for this in 2007 (we = iOS devs).

[dwaite]

There are several vendors who do this, for instance 1Password and the Omni Group both do. You have an in-app purchase option that is unlocked by a previous receipt. The challenge is that Apple does not provide tools to help or guidance. They do indeed think e.g. requiring users to buy an upgrade to keep the app working on a new annual iOS version or macOS version is a bad model for users.

Panic even had an upgrade for MAS users when they released their new version of the now defunct Coda outside the MAS (for sandboxing reasons).

[pwdiscflatmajor]

FL Studio (fka FruityLoops) is an outstanding exponent of this old method (but once, free upgrades for life)

[mcguire]

Free upgrades are problematic themselves: once you've saturated your market (a good place to be, right?) you no longer have income to provide upgrades.

[lomase]

FL Studio has had free updates for +23 years and is a company with profit.

It does not look like a problem for them.

Do you have an example of a company that saturated the market with free upgrades and went down because of it?

[mcguire]

Given that I'd never heard of them (and I've played around with a few DAWs), I don't think they've saturated their market.

[raybb]

What's missing is you pay for Adobe Photoshop CS2 and it's yours forever. Then when CS3 comes out you can upgrade with a nice discount.

[derefr]

Ah, alright.

There's nothing actually stopping you from doing this — it requires two things:

1. either a third-party licensing server (and thus some SSO auth system — but just require Apple's own SSO for it and it'll still be a clean-ish workflow) to share/sync the transaction status from one app to the other; or a local Group Container plus logic in each app to write the transaction statuses fetched for the given app into the group container for the other app to read

2. never charging for the app as a whole, but instead breaking your app's pricing down into a set of IAP-purchased feature entitlements (whether charged for individually, or as a bundle, the important part is that each entitlement has its own price.) Then, making the new version just a superset of the features of the old version — and so, when you're buying the old version, you're buying features A+B+C; and then when you're buying the new version (with the app being able to see whether or not you've bought the old version), new customers are buying A+B+C+D+E, while existing customers are buying D+E.

---

Note that there's an even easier way to do this (and I think this is the way Apple would prefer you do this): don't release V2 as a separate app from V1.

Instead, have V1 auto-update to a v2.0.0 release — which converts the V1 app into a launcher with an "edition" (major version) selector. Either compile in both the V1 and V2 codebase into this app, or better yet (for download/on-disk size), package separate V1 and V2 "engines" as executable DLC packages, submitted to Apple for review along with the app, downloaded on-demand when the app needs to run them.

With this approach, the app would either start up the first time still within V1, and allow/offer people the option of "seamlessly upgrading" the app to V2; or the app would start up with an "edition launcher" UI that allows people a choice. (And either way, you could offer the ability at any time to freely switch between V2 and V1, re-launching the app with the other engine enabled. Like dual-booting Operating Systems, but at the app level.)

Here, you could charge for the V2 "upgrade" ahead-of-time, before allowing the user to switch over to the V2 engine; or you could allow the user to switch between V1-fully-licensed and V2-demo modes (or even between V1-demo and V2-demo modes), where purchasing for each edition is separately available within that edition's UX.

The expectation here is that all the user's existing feature entitlements would keep working as long as they continue to use the V1 engine — as you said, the V1 engine was a one-time purchase, and so even with this edition-launcher abstraction introduced in v2.0.0 of the app, V1 itself should still keep working for them forever.

The benefit of doing this multi-editioned-shared-app approach, together with IAP feature entitlements, is that V2 can inherit some of the V1 entitlements, and then simply charge for the V2-novel entitlements. So V2 gets discounted for V1 purchasers inherently, by the fact that by buying V1, they've already bought half of the components of the V2 purchase-bundle.

[CodeWriter23]

So whereas authors used to ship a new version, and let people upgrade to that version at a discount, the author now assumes the burden with each new release of maintaining and testing V1 (that’s with all the feature flags turned off) as well as every feature flag between V1 and Vcurrent turned on. One at a time. Sounds like insanity to me.

[nomel]

> One at a time.

That would be a choice, not a requirement. It's literally a flag. You can do whatever tf you want with it. It would be trivial to have "V1 full app unlock" feature be the same as "V2 full app unlock" feature.

[CodeWriter23]

@jayd16 - it’s been a few years since I read the Apple Developer Agreement but at that time downloading code and executing it within your app was forbidden by the agreement. A sensible security safeguard IMO.

[derefr]

iSH does it. Not sure how they get away with it, but the dev is around on here so maybe they can explain.

[kmeisthax]

AFAIK, even the iSH developers were never given a proper explanation. iSH was actually removed a few years back[0] and then reinstated with an apology but no policy changes or clarifications.

This was before the change to allow Delta on the App Store, too.

[0] https://ish.app/blog/app-store-removal

[johnnyanmac]

Lot of stuff can skirt by until it doesn't. That's how stuff like Beeper suddenly explodes into a kerfluffle in a matter of days over some dang blue bubbles.

[jayd16]

Have you actually done this? Is there a common example on the app store?

When did it become possible to download additional executable bundles on iOS?

[derefr]

Re: feature entitlements shared through a shared SSO auth backend and/or Group Container — yes, apps do this. Mostly this is in app "suites" where you can IAP a feature entitlement in one app in the suite, and the entitlement should then become available to the other apps in the suite. (I think the Omni Group apps do it? Correct me if I'm wrong.)

Re: multi-edition shared apps — I'm not sure if this has been done with the App Store in particular, but it's just a combination of things App Store apps can do (basically, moving code out into dylibs, and then marking those dylibs as On-Demand Resources.) I know that this is a common approach to supporting netplay (and especially replay of historical netplay) in competitive-eSport multiplayer game titles on Steam et al, where players need to be on the same exact version of the game engine + netcode to sync (and so those engine libs are downloaded on-demand before the match begins); and where you need an exact ABI version of the game engine to replay a netplay recording (and so that engine lib is downloaded on-demand when you go to replay the recording.)

ETA: looking more into this, I'm finding conflicting reports on whether executable-code On-Demand Resources are currently allowed on the iOS App Store: it looks like the Apple docs say no, and yet some apps (from not-bigcorp devs!) are doing it anyway and getting away with it (and have for many review cycles.) Very confusing. Maybe those devs are part of an alpha-test rollout for executable-ODR?

[jonny_eh]

Apple also takes a smaller share via subscriptions after a year (30% -> 15%).

[AmVess]

It has basically made their app store completely unusable. I am not going to manage a bunch of subs for what amounts to zero effort crapware.

[david_allison]

Not being able to set custom price points for subscriptions is also painful