4 ms·

I agree with all four points mentioned by the writer, IMO of those four reasons, the biggest problem is the absence of "paid upgrades" Not being able to charge

by credo 12y ago

I agree with all four points mentioned by the writer, IMO of those four reasons, the biggest problem is the absence of "paid upgrades" Not being able to charge for updates is a problem that affects almost every single paid app (assuming the app is supported across multiple versions and major updates) in all the app stores. This is an unsustainable proposition for most developers. At a recent Seattle Xcoders meeting in Redmond, our speaker spoke about how he had given up his indie business and had now switched to contracting (disclosure: I run this meeting and had asked the speaker to speak). At the meeting, I noted that Apple made its profits through hardware and they could therefore afford to make their software free. Similarly, Google is an ads company and so they don't need to charge for their software. However, the dominance of these companies means that most users/consumers expect all their software to be free (and the small minority that downloads paid apps wants upgrades to be free). It is going to be an uphill battle for any "software" company to survive in the future. IMO that applies primarily to indie devs (I'm one myself) who sell apps in the app stores, but the problem also extends to large companies like Microsoft.

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.
pnathan 12y ago
I've been investigating & studying the business of software market in the past 2 years, and I've come to the same conclusion. Software needs to be designed around revenue streams; renting software is essentially the future. This is particularly true for software which reaches maturity. E.g., I don't need new features on my text editors (spreadsheets, browsers, etc); they are debugged and work great for me. So a SaaS model is where software effectively has to land, modulo unicorns.
- meepmorp 12y ago
  >I don't need new features on my text editors (spreadsheets, browsers, etc); they are debugged and work great for me. I see how that's probably right from the developer's perspective but as a consumer, it'd make me avoid your products. I don't want to keep paying you to use a product in general, and particularly not if - as you say - there's no new functionality or features. I don't want to rent my text editor, and asking me to adopt that model for your benefit isn't appealing. I realize that keeping developers afloat benefits me in the long term, but that's not really my focus as a customer.
  - pnathan 12y ago
    Abso-freaking-lutely! Commodity software income trends to zero, especially as competitors enter the market and trim away the features that are unwanted, leaving a minimal (fast to develop) product behind. I don't actually believe that B2C software for "average consumers" where user pays for software is a viable market outside of certain markets (e.g., antivirus updates). The incentives are simply too aligned with gratis software doing something acceptably well for the vast majority of people, probably ad-supported. patio11 recently linked an article about selling to flies/mice/deer/elephants. It's really worth reading. I firmly believe that the only games in town over the next 5-10 years for financial revenues from software are: 1. ad-supported mass market (E.g., gmail) 2. B2C niche (e.g., Bible study software) 3. B2C SaaS (backup software, dropbox, Google apps) 4. B2B SaaS (most of web stuff) 5. B2B desktop/server - usually 1-time fee + maintenance over a few years. B2C Desktop buy-once and run is pretty extinct, afaict. For me, it's been replaced by libre software like LibreOffice, Emacs, and Firefox.

by credo 12y ago

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.

pnathan 12y ago

I've been investigating & studying the business of software market in the past 2 years, and I've come to the same conclusion. Software needs to be designed around revenue streams; renting software is essentially the future. This is particularly true for software which reaches maturity. E.g., I don't need new features on my text editors (spreadsheets, browsers, etc); they are debugged and work great for me. So a SaaS model is where software effectively has to land, modulo unicorns.

meepmorp 12y ago
>I don't need new features on my text editors (spreadsheets, browsers, etc); they are debugged and work great for me. I see how that's probably right from the developer's perspective but as a consumer, it'd make me avoid your products. I don't want to keep paying you to use a product in general, and particularly not if - as you say - there's no new functionality or features. I don't want to rent my text editor, and asking me to adopt that model for your benefit isn't appealing. I realize that keeping developers afloat benefits me in the long term, but that's not really my focus as a customer.
- pnathan 12y ago
  Abso-freaking-lutely! Commodity software income trends to zero, especially as competitors enter the market and trim away the features that are unwanted, leaving a minimal (fast to develop) product behind. I don't actually believe that B2C software for "average consumers" where user pays for software is a viable market outside of certain markets (e.g., antivirus updates). The incentives are simply too aligned with gratis software doing something acceptably well for the vast majority of people, probably ad-supported. patio11 recently linked an article about selling to flies/mice/deer/elephants. It's really worth reading. I firmly believe that the only games in town over the next 5-10 years for financial revenues from software are: 1. ad-supported mass market (E.g., gmail) 2. B2C niche (e.g., Bible study software) 3. B2C SaaS (backup software, dropbox, Google apps) 4. B2B SaaS (most of web stuff) 5. B2B desktop/server - usually 1-time fee + maintenance over a few years. B2C Desktop buy-once and run is pretty extinct, afaict. For me, it's been replaced by libre software like LibreOffice, Emacs, and Firefox.