3 ms·

Maybe I'm missing something, but couldn't you use In-app Purchases for "paid upgrades"? As in, release the update for free, but have an additional in-app purcha

by M4v3R 12y ago

Maybe I'm missing something, but couldn't you use In-app Purchases for "paid upgrades"? As in, release the update for free, but have an additional in-app purchase to unlock the new functionality? Of course that wouldn't work for all upgrades (like a whole-app rewrite or interface revamp, etc.), but for some cases I imagine that could work. This would also solve the problem of no free trial (release the app for free and then add in-app purchase to unlock the full functionality). These are of course only workarounds, and I would greatly appreciate if Apple would come up with a complete solution for these problems.

smackfu 12y ago
This is what some developers do, but as you say, it limits what you can add. A new discrete feature, yes. A replacement feature, not really. And it means you need to support the unpaid code path forever.
deleted 12y ago
[deleted]
joshstrange 12y ago
That may work in some cases but for QA reasons alone it gets unsustainable really quickly. Let's say you have your base app then "Upgrades" A, B, C. * What if the user buy's C but not A and B? * Does B/C rely on anything in A or C rely on anything in B * For every upgrade the dev needs to test all the possible combinations of upgrades bought by the user * Positioning for new UI added by A/B/C dependant on what other upgrades have been purchased You might be able to solve most of these with requiring A for B and B for C but even then you still need to test your app: Base+A, Base+A+B, Base+A+B+C......
drewcrawford 12y ago
Suppose you have a video converting app. Further suppose your headline new feature is converting 2x as fast as the old version, pretty much the holy grail of video conversion software. In the MAS you have a set of bad choices: A) Release the upgrade free to everybody. Great for them, bad for you. B) Make the new encoder an IAP. Problem is, now you are maintaining "old" code that you may not want to maintain anymore. You may need to wrestle with the old encoder to get it compile for new versions of the compiler, etc. You have to fix bugs that occur with the old encoder and new, unanticipated changes in OSX. If you're still compiling and uploading it every month you can't plausibly claim that it's no longer supported. C) ship the new encoder, but cripple it so it's slow until users upgrade. This seems capricious. Also, you can't get exactly the performance of the old encoder; you'll either overshoot or undershoot. And the nature of the MAS is that user's can't effectively downgrade, so they'll be SOL if you're wrong. D) Remove the app from sale and submit a new app. You're wiping your slate with links, app reviews, etc. You also lose customers, who don't find out about your shiny new version. OmniGroup pursues this strategy, and they lose a lot of revenue from me (an avid user) because I completely miss certain upgrades because I don't hear about them. I can't imagine how it is for marginal users. E) Don't update the app after all, because in spite of the fact that 2x video encoders obviously add value to the world, the MAS adds too much friction to make it a viable business. I would argue that the majority of iOS and Mac apps face this sad reality at some point in their lifecycle. I submit to you, that if you manage to write a video encoder that is 2x faster, that should be the hard problem. The hard problem shouldn't be to figure out how to structure your upgrade pricing. But with the MAS, it is.
- yaeger 12y ago
  >D) Remove the app from sale and submit a new app. You're wiping your slate with links, app reviews, etc. You also lose customers, who don't find out about your shiny new version Um, how about this: Since your encoder is 100% faster you obviously did some substantial engineering on it. So why would this be just an update to the existing app? Even if you could charge for it? The easy option you didn't mention is: F) Keep the old app in the store and start selling your "Encoder2" as well. "But I wrote 'customers don't find out about your shiny new version' you are now thinking" Well, you know there is the option of having users of the old app being notified about your new offerings, right? Don't tell me you have never seen such a popup in an app telling you about that companies new app. So now you have two apps in the store and it is up to you to make sure how they differ and how the new one is an improvement over the old one. Now the customer has the choice which to get. For them nothing changes.

by M4v3R 12y ago

smackfu 12y ago

This is what some developers do, but as you say, it limits what you can add. A new discrete feature, yes. A replacement feature, not really. And it means you need to support the unpaid code path forever.

deleted 12y ago

[deleted]

joshstrange 12y ago

That may work in some cases but for QA reasons alone it gets unsustainable really quickly. Let's say you have your base app then "Upgrades" A, B, C. * What if the user buy's C but not A and B? * Does B/C rely on anything in A or C rely on anything in B * For every upgrade the dev needs to test all the possible combinations of upgrades bought by the user * Positioning for new UI added by A/B/C dependant on what other upgrades have been purchased You might be able to solve most of these with requiring A for B and B for C but even then you still need to test your app: Base+A, Base+A+B, Base+A+B+C......

drewcrawford 12y ago

Suppose you have a video converting app. Further suppose your headline new feature is converting 2x as fast as the old version, pretty much the holy grail of video conversion software. In the MAS you have a set of bad choices: A) Release the upgrade free to everybody. Great for them, bad for you. B) Make the new encoder an IAP. Problem is, now you are maintaining "old" code that you may not want to maintain anymore. You may need to wrestle with the old encoder to get it compile for new versions of the compiler, etc. You have to fix bugs that occur with the old encoder and new, unanticipated changes in OSX. If you're still compiling and uploading it every month you can't plausibly claim that it's no longer supported. C) ship the new encoder, but cripple it so it's slow until users upgrade. This seems capricious. Also, you can't get exactly the performance of the old encoder; you'll either overshoot or undershoot. And the nature of the MAS is that user's can't effectively downgrade, so they'll be SOL if you're wrong. D) Remove the app from sale and submit a new app. You're wiping your slate with links, app reviews, etc. You also lose customers, who don't find out about your shiny new version. OmniGroup pursues this strategy, and they lose a lot of revenue from me (an avid user) because I completely miss certain upgrades because I don't hear about them. I can't imagine how it is for marginal users. E) Don't update the app after all, because in spite of the fact that 2x video encoders obviously add value to the world, the MAS adds too much friction to make it a viable business. I would argue that the majority of iOS and Mac apps face this sad reality at some point in their lifecycle. I submit to you, that if you manage to write a video encoder that is 2x faster, that should be the hard problem. The hard problem shouldn't be to figure out how to structure your upgrade pricing. But with the MAS, it is.

yaeger 12y ago
>D) Remove the app from sale and submit a new app. You're wiping your slate with links, app reviews, etc. You also lose customers, who don't find out about your shiny new version Um, how about this: Since your encoder is 100% faster you obviously did some substantial engineering on it. So why would this be just an update to the existing app? Even if you could charge for it? The easy option you didn't mention is: F) Keep the old app in the store and start selling your "Encoder2" as well. "But I wrote 'customers don't find out about your shiny new version' you are now thinking" Well, you know there is the option of having users of the old app being notified about your new offerings, right? Don't tell me you have never seen such a popup in an app telling you about that companies new app. So now you have two apps in the store and it is up to you to make sure how they differ and how the new one is an improvement over the old one. Now the customer has the choice which to get. For them nothing changes.