4 ms·

7 is meant to be handled by the developer or possibly by Apple, not by the consumer. If you have to manage versions manually, Apple has failed you. So I get to

by wtracy 12y ago

7 is meant to be handled by the developer or possibly by Apple, not by the consumer. If you have to manage versions manually, Apple has failed you. So I get to wait two weeks for Apple to approve the developer's bugfix instead of letting me roll back now to the version that worked last week. Yay!

abruzzi 12y ago
The problem with 7 is it puts the developer in control, not the user. What if the developer releases a new version with a drastically reduced feature set (ahem..iMovie). I should be able to choose which version I want to run.
- derefr 12y ago
  iMovie is an exception that proves Apple's usual rule: in most of Apple's own apps (Quicktime, Aperture, Xcode, OSX itself) each major version is its own separate app. This fixes both the "paid upgrades" and "choosing what version you want to run" requirements, very simply, as long as you do it correctly. Most importantly, you'll need to make MyApp N+1 discoverable from MyApp N (likely by an update with text such as "click to see MyApp N+1 on the app store.") For example, look at how "Transmit 3" (one app) talks about "Transmit 4" (a separate app). You'll also probably want to sync IAPs to some more canonical source of truth than Apple's own servers, such that your app can ask "has the user purchased IAP X in [any of our apps that provide IAP X]" rather than "has the user purchased IAP X in this particular app." Then IAPs purchased in MyApp N apply to MyApp N+1, and vice-versa.
  - lukifer 12y ago
    Aside from all the little quirks of MyApp N+1 (multiple versions of the same app installed, new users accidentally buying old versions), there is one major flaw in this practice: upgrade pricing. I'm usually happy to pay $20-40 for a solid upgrade on a $100 productivity app; if I had to pay $100 all over again, I probably wouldn't bother.
    - derefr 12y ago
      If you charged $20 for both MyApp N and MyApp N+1, and made up the $80 difference in version-portable IAPs, then you'd get the pricing model you're suggesting. A good candidate for this would be something like Photoshop, where $20 would get you the "engine" of Photoshop N, and then you pay $5 each for various brushes and filters. When you upgrade to Photoshop N+1, you're upgrading to a new engine—but keeping your brushes and filters. Games could also work like this, though in that industry, the more common strategy is the "expansion"—effectively, keeping an entirely new version of the app logic/assets commingled with the old version but disabled using feature flags, and then unlocking it through an upgrade-priced IAP. (Now there's a thought. Could you ship two entirely separate binaries within one application bundle, and put a switch in your app's prefpane to toggle between execv()ing N or N+1?)

by wtracy 12y ago

abruzzi 12y ago

The problem with 7 is it puts the developer in control, not the user. What if the developer releases a new version with a drastically reduced feature set (ahem..iMovie). I should be able to choose which version I want to run.

derefr 12y ago
iMovie is an exception that proves Apple's usual rule: in most of Apple's own apps (Quicktime, Aperture, Xcode, OSX itself) each major version is its own separate app. This fixes both the "paid upgrades" and "choosing what version you want to run" requirements, very simply, as long as you do it correctly. Most importantly, you'll need to make MyApp N+1 discoverable from MyApp N (likely by an update with text such as "click to see MyApp N+1 on the app store.") For example, look at how "Transmit 3" (one app) talks about "Transmit 4" (a separate app). You'll also probably want to sync IAPs to some more canonical source of truth than Apple's own servers, such that your app can ask "has the user purchased IAP X in [any of our apps that provide IAP X]" rather than "has the user purchased IAP X in this particular app." Then IAPs purchased in MyApp N apply to MyApp N+1, and vice-versa.
- lukifer 12y ago
  Aside from all the little quirks of MyApp N+1 (multiple versions of the same app installed, new users accidentally buying old versions), there is one major flaw in this practice: upgrade pricing. I'm usually happy to pay $20-40 for a solid upgrade on a $100 productivity app; if I had to pay $100 all over again, I probably wouldn't bother.
  - derefr 12y ago
    If you charged $20 for both MyApp N and MyApp N+1, and made up the $80 difference in version-portable IAPs, then you'd get the pricing model you're suggesting. A good candidate for this would be something like Photoshop, where $20 would get you the "engine" of Photoshop N, and then you pay $5 each for various brushes and filters. When you upgrade to Photoshop N+1, you're upgrading to a new engine—but keeping your brushes and filters. Games could also work like this, though in that industry, the more common strategy is the "expansion"—effectively, keeping an entirely new version of the app logic/assets commingled with the old version but disabled using feature flags, and then unlocking it through an upgrade-priced IAP. (Now there's a thought. Could you ship two entirely separate binaries within one application bundle, and put a switch in your app's prefpane to toggle between execv()ing N or N+1?)