* * *

That isn’t enough to enable this business model.

It would be simple enough (yes I know I sound like a product manager” to add another rule to allow someone to download the last version they are eligible for. Apple keeps all of the previous versions of apps. They use to be available via a simple url.

The problem isn't the lack of possible way to do it well rather the lack of implemented way to do it well.

There is a major update to iOS every single year and many older application simply wouldn't run.

Bad experience for users, developers and Apple.

It doesn't work the other way though. If you have a new device, old versions will often not work.

You could approximate it with extensive feature flagging to disable/hide new features for people with old "versions" of the app.

Working Copy on iOS does this _brilliantly._

> The features you unlock are permanently available and any other pro features added the next 12 months after purchase are also permanently available. After one year new pro features introduced will be locked until you purchase a upgrade. Even if you do not purchase a new unlock after 12 months, the app will still be updated with improvements and bug-fixes.

https://workingcopy.app/manual/purchase

Yes! I was going to comment the same, it's a very reasonable model from a developer who makes great software. I recently within the last year switched from the Blink shell to his app "Shellfish" as it's become a daily part of my workflow when using my iOS devices. I highly recommend it if you like workingcopy.

sounds like a nightmare and a half given enough time.

Oh yeah I didn't say it was a great option but it's AN option and could be managed so long as your features are relatively self contained modules.

Major websites such as Airbnb have dozens to hundreds of feature flags which they use to run A/B experiments.

And so there is plenty of software available e.g. LaunchDarkly to help simplify the process.

there's a difference between temporary feature flags which eventually go away and permanent ones. say you build a new feature that has some overlap with an existing feature flagged one, and you unify some of the UI for it. now you have to always check what the UI looks like with one feature flag, with both, with none. as time goes on this gets worse, and maybe 3 or more features start overlapping in some way. If you're just using feature flags for A/B tests, this is manageable, but over time it can get really messy.

With good reason as it's unworkable.

iOS and iPadOS are not stable systems like OSX where the fundamentals of the overall experience is clear and largely complete. There is still a lot of innovation and new concepts being introduced each year.

To have a large percentage of users with older apps that won't properly support these changes would hurt the platform.

As was mentioned feature flags are a much better option.

> and you cannot sideload

not yet, and most likely just not in the us

but due to the european union digital markets act, apple will have to allow for side loading, and somebody was speculating it will only be in the EU.

just not in the US != only in the EU

That technical method isn't the only way to implement this business method, and a number of existing apps are doing this quite successfully already. So this both already exists, and works.

As for 'side loading', it's somewhat possible, but even if it was available by default it would be messy for most customers -- they already have trouble with what's currently available. Perhaps some sort of in-app store would make that model feasible. The vendor gets to show and deploy whatever they want, and the end-user gets a very clear and very specific list of options for the app/vendor. That would even be better than the 'everyone in one store' model for some more specialised apps, especially when searching.

The other two ways I've seen are committing to lifetime bugfixes but maintaining a feature lock based on last license renewal or releasing a separate app per release. The first is actually a different model but if you're alright with it from the developer side then it's very similar from the user's perspective. The second is either different or the same depending on how it's implemented. 2a is commit to upgrading these apps for life the same as the first method, at which point it largely turns into a worse option to both sides. 2b is to not commit to lifetime updates, at which point it's not really lifetime as much as "until Apple removes it from the App Store and you need to download it on a new device".

Based on the wording comment it sounds like there may be additional ways I haven't seen but you didn't really say what they were as much as dismiss the point assuming everyone knew what apps or release models you are familiar with.

I agree an in App Store solution like the one you describe would be the preferred answer for most users. Sideloading is more useful as a catch-all for anything Apple doesn't have a good first party answer for. Once non policy related use cases for the sideloading exist it's going to be easier for most to have a first party solution for those use cases.

I think there is yet another option we both didn't state, but an option that is also in use to this day. Some apps simply have multiple entries in the current AppStore model, and the version you currently have is very much separate from a possible 'future' upgrade. I'm not sure how they handle major upgrades on the back-end (perhaps tied to an in-app purchase or transferable purchase based on some sort of online account?), but this is a more 'hard' distinction between actual versions.

I suspect that this model has some downsides considering good security practise would prevent the apps from sharing their namespace contents. And for end-users they might end with "MyCoolApp 1" at first, but then "MyCoolApp 2, MyCoolApp 3, MyCoolApp 4" unless they delete the old one. I think some app vendors even use the year as the release distinction but in true software engineering fashion those years and the actual release date tend to be out-of-sync (just like MS Office).

That's the most common way I've seen 2a/2b done, otherwise you have no way to release new versions at all.

What you've described is more complex than managing one app with feature flags.

And it's still undetermined whether Apple would be required to host your app on their App Store once you've decided to run your own store. Which means you would be losing a major distribution channel.

Not sure how widespread it is, but TapBots and 1Password both released separate apps for their major version updates. The 1Password subscription carried across to the new app, the TapBots one was a new purchase for each app, so there's 2 ways that model has been working on iOS.

Both have stopped doing that because of the confusion it causes

Loopy Pro manages to do this: https://loopypro.com/pricing/