Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I fail to see how any of the things I suggested put them at a disadvantage to Google, other than maybe lowering the 30% (and given that that the vast majority of Apple's revenue comes from hardware, I strongly doubt that it would be significant.)


All of those things make the average price of software go up. I realize that's desirable to developers (me included), but it would also tilt the overall market towards platforms where software is cheaper.


I think that's debatable. Trials could result in more software getting purchased (and fewer instances of feeling burned, meaning more likelihood of future MAS purchases). Lowering the 30% would trickle savings down to customers, as producers could price more aggressively for the same marginal revenue and try to drive up volume.

The only change I see that could affect the price of sofware is paid upgrades, which does fundamentally alter the pricing dynamic by incentivizing an unpleasant upgrade treadmill in the worst cases. But the problem is, companies whose revenue is dependent on upgrades will still do so, only badly: either using "MyApp 3" (which is awkward, and doesn't allow upgrade pricing for existing users); or, using in-app purchases, which is a weird experience, and has a huge drag co-efficient by requiring developers to support all old functionality in the same app, forever. (Imagine if Pixelmator 4 had to encapsulate every last bit of Pixelmators 1-3, bug-free, within version 4. It's a recipe for disaster for both users and developers, making it cost-prohibitive to do under-the-hood improvements instead of just Features Features Features, meaning more technical debt.)

If there's another way in which my suggestions alter the price of software as commodity, or alter consumer pricing psychology, please point it out.


I think the 30% is a red herring. We aren't talking about 15% revenue difference being somehow transformative to the profitability of app development.

I disagree strongly that people who would use upgrades already do so, but badly. Pretty much every paid app maker would be tempted to start using paid upgrades, since it would be trivial and become a norm. The 'bad' way of doing it is a strong disincentive that stops most developers actually doing it.

Adding paid upgrades would make the whole store into a nightmarish minefield where you'd suddenly be being charged again for minimal updates to trivial apps. The examples give for paid upgrades are always solid reputable, thoughtful companies like the Omni Group, but they represent 0.000001% of the store at most.


> A nightmarish minefield where you'd suddenly be being charged again for minimal updates to trivial apps.

If this is true, we should be seeing it in non-MAS apps. Can you cite some examples of these practices in existing Mac software, outside of scams/malware/etc?


This certainly doesn't follow.

The bar to creating and distributing a paid app outside the store is far higher than creating an app for the store, so it selects for serious businesses like omni, or panic. Many of the apps in the store aren't even made by full time developers.

I'm not defending the store - as I said I agree with the identified problems. But I am asserting that the solutions are not the trivial fixes people pretend them to be.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: