5 ms·

iOS devices don't support downloading specific versions of apps, and you cannot sideload. Apple has made this model impossible on iOS.

scarface74 3y ago
Actually it does. If you have a device that doesn’t support the newest version of the app, you can choose to “download the last compatible version”
- ianlevesque 3y ago
  That isn’t enough to enable this business model.
  - scarface74 3y ago
    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.
    - zamadatix 3y ago
      The problem isn't the lack of possible way to do it well rather the lack of implemented way to do it well.
    - threeseed 3y ago
      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.
- Gigachad 3y ago
  It doesn't work the other way though. If you have a new device, old versions will often not work.
rtkwe 3y ago
You could approximate it with extensive feature flagging to disable/hide new features for people with old "versions" of the app.
- genmon 3y ago
  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 https://workingcopy.app/manual/purchase
  - romeoblade 3y ago
    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.
- deleted 3y ago
  [deleted]
- asddubs 3y ago
  sounds like a nightmare and a half given enough time.
  - rtkwe 3y ago
    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.
  - threeseed 3y ago
    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.
threeseed 3y ago
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.
znpy 3y ago
> 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.
- Shared404 3y ago
  just not in the US != only in the EU
oneplane 3y ago
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 (which currently leads to a plethora of tangential ads and applications you actually don't want).
- zamadatix 3y ago
  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.
  - oneplane 3y ago
    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).
bazzargh 3y ago
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.
- ezfe 3y ago
  Both have stopped doing that because of the confusion it causes
emanuelez 3y ago
Loopy Pro manages to do this: https://loopypro.com/pricing/ https://loopypro.com/pricing/

scarface74 3y ago

Actually it does. If you have a device that doesn’t support the newest version of the app, you can choose to “download the last compatible version”

ianlevesque 3y ago
That isn’t enough to enable this business model.
- scarface74 3y ago
  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.
  - zamadatix 3y ago
    The problem isn't the lack of possible way to do it well rather the lack of implemented way to do it well.
  - threeseed 3y ago
    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.
Gigachad 3y ago
It doesn't work the other way though. If you have a new device, old versions will often not work.

rtkwe 3y ago

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

genmon 3y ago
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 https://workingcopy.app/manual/purchase
- romeoblade 3y ago
  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.
deleted 3y ago
[deleted]
asddubs 3y ago
sounds like a nightmare and a half given enough time.
- rtkwe 3y ago
  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.
- threeseed 3y ago
  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.

threeseed 3y ago

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.

znpy 3y ago

> 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.

Shared404 3y ago
just not in the US != only in the EU

oneplane 3y ago

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 (which currently leads to a plethora of tangential ads and applications you actually don't want).

zamadatix 3y ago
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.
- oneplane 3y ago
  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).

bazzargh 3y ago

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.

ezfe 3y ago
Both have stopped doing that because of the confusion it causes

emanuelez 3y ago

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