5 ms·

The lack of tabs drives me crazy. A few other letdowns on the user side: 6. No wishlist and no way to gift apps to friends (textbook example of leaving money o

by lukifer 12y ago

The lack of tabs drives me crazy. A few other letdowns on the user side: 6. No wishlist and no way to gift apps to friends (textbook example of leaving money on the table). 7. No way to rollback to old versions (particularly relevant when crashing bugs are introduced). 8. No way to transition from a non-MAS customer to an MAS customer. If I have equity in an existing program I purchased, possibly at great expense, I have no way to get the features of the App Store (updates, iCloud, etc) without paying again. And the developer can't do anything about this, even if they want to.

derefr 12y ago
6 exists for the iOS App Store. It's a shame it doesn't (yet?) for the Mac App Store. 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. 8 can be accomplished by publishing the app as one of those "free + unlock" apps, but allowing the user to enter their predated proof-of-purchase to trigger the same effects purchasing the IAP unlock would. Apple disallows selling "things that are also IAPs" outside of the store—but as long as you stop selling the app through the non-MAS mechanism when you start selling it through the MAS, you're not violating the rules, because you're only validating previously-existing codes in the app, not issuing new ones. (So there's no way to purchase anything now equivalent to an IAP from you.)
- 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 lukifer 12y ago

derefr 12y ago

6 exists for the iOS App Store. It's a shame it doesn't (yet?) for the Mac App Store. 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. 8 can be accomplished by publishing the app as one of those "free + unlock" apps, but allowing the user to enter their predated proof-of-purchase to trigger the same effects purchasing the IAP unlock would. Apple disallows selling "things that are also IAPs" outside of the store—but as long as you stop selling the app through the non-MAS mechanism when you start selling it through the MAS, you're not violating the rules, because you're only validating previously-existing codes in the app, not issuing new ones. (So there's no way to purchase anything now equivalent to an IAP from you.)

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?)