Hacker News Reader

Comment by deedubaya | Hacker News Reader

As a developer with Apps in the MAS, I can see where this makes sense from the developer's perspective. But I think it is a mater of laziness on the dev's part.

Let me explain:

From a users perspective, this would suck. It is an antiquated system. "I have to pay for an upgrade just so it works on the new OS?" Think of how many times you've had to do this in the past, and how you felt.

Apple will act in the best interest of Joe User, not Joe Developer.

Instead of paid upgrades, dev's should be providing In-App purchases for new features. Maintenance of the App should be provided for free. Win-win for all.

Now stop bitching about what the MAS should have, and start using the solution Apple has given you! :)

View on HN

We generally don’t charge to update our apps to a new operating system. In fact, that’s been a lot of what we’ve done to version 2 over the last couple years – it now runs on an OS TWO major versions beyond what we wrote it for. And that was a free upgrade for all users.

But if I rewrite an app and improve the art and the flow and the interaction and every little part of it, there’s no way to say, “Hey, pay and we’ll give you the better interface.”

I spend years tweaking every single part of my apps when I make a new version. I can’t just throw a switch to turn those on or off.

Finally: it’s pretty much my job to bitch about what Apple does wrong, just as it is yours: it’s the only way they will improve. They’re not gods. They need feedback.

Wil, have you looked at lowering the upfront price of new versions - You would get more customers(but probably less revenue), but you would make back the money on upgrades to a larger user base.

Actually, I'm not really asking if you have looked at it - you probably have. But I'd be interested in hearing your analysis, particularly as this seems to be the route that Apple has taken themselves - cheaper software but you pay full price for each new version.

I'd hate to pick up a piece of software, only to find that there are 50 new features that I want that I have to buy piecemeal.

It's how the gaming industry currently works (with DLC), and while it's working for them right now, there's an ugly backlash against those companies that forms with every new DLC release that requires a lot of PR to counter.

As Joe User, I depend greatly on Joe Developer to make my Mac more usable. If Joe Developer is driven away for greener pastures, and my Mac experience degrades as a result, the chance I may not stick with this platform grows.

It's all about implementation. Instead of 50 features, perhaps there is a "2012 Feature Pack" that provides all the new features for 2012 and previous. The developer has a lot of flexibility on how to manage In-App purchases.

All In-App purchases are listed in the Available In-App Purchases section in the App Store.

And how would you feel if in a few years you bought GreatApp from the MAS, and then found that to get the current functionality you had to then buy as an in-app purchase "2012 Feature Pack", "2013 Feature Pack" and "2014 Feature Pack"?

His post suggests that each "<Year> feature pack" would also contain all of the previous years' features, for new-commers.

And yet the new purchaser ends up spending more under this model than they would under a paid upgrades model. New user pays $40 for features X, Y, and Z. User of a previous version, containing X and Y, would pay $10 for the new version.

Under the in-app purchase model, both customers have to pay $50 for X, Y and Z, which provides a high barrier to entry, a poor customer experience, and poor reviews for the app.

There are ways around this scenario, but none of which are as user friendly as allowing previous owners to purchase new versions at a discounted price.

I'm not following.

Say the app is originally $10.

A year later you push out the "2013 feature pack" for $10 more.

Existing customer pays $10 ($20 total over lifetime) for upgrade. New user pays $20 at once ($10 base + 2013 pack).

A year passes, 2014 pack comes out, existing user pays $10 ($30 over lifetime), new user pays $20 ($10 base + 2014 pack (which subsumed all features of the 2013 pack)).

The existing user is always getting an at-the-moment discount.

Now, yes, the existing user pays more over the lifetime than the new user, but this is no different than conventional upgrades. If you've religiously bought every Lightroom upgrade you've paid more than the guy who jumped in at Lightroom 4 over the lifetime of the product, even with the upgrade discounts.

Hmm.. this actually looks like developer is going to start making less money the moment they release the first feature pack. To make things fair to users [1] you have to start selling base version for less money at some point to ensure that the full price of the application stays the same, but if you do that you have no guarantees that people will buy "feature packs" - actually it's guaranteed that not everyone will buy those so you will get less money than you would if you could just stop selling version 1.0 and start selling version 2.0 for the same price (and provide an upgrade path for existing users)

EDIT: clarified a bit

Except, the new user isn't paying $20 at once, they pay $10 to the app store to buy the app, then they have to pay $10 at a later point inside the app to enable new features.

Same problem. The new user has a poor experience, and essentially pays twice for features that were bundled in the app to begin with.

Of course, at the $10 price point for initial purchases and upgrades, it's simpler to just release a separate app.

As a developer with apps in the MAS, this sounds like a sales, maintenance, and support nightmare.

How would you architect your app to have separate, modular features?

How would I reliably test all combinations of all features?

How do I properly advertise app functionality without deceiving users?

How do I properly support users when they have issues? (Depending on what they've purchased, they could have a very unique set of features and UI enabled.)

You're taking a hammer and using it to tighten a screw. Instead, Apple should be offering the proper tools we need to offer reasonable app upgrade paths.

It wouldn't, necessarily, have to be excessively modular.

Say, one in-app purchase, the "2012 Feature Pack", or some such.

That said, I'm not convinced its a better idea than just creating a new FooBar2 app in the store and pushing an update to FooBar1 advertising the launch sale of the new version.

Your comment only makes sense under the argument that when a user purchases an app, the developer is indebted to the user to provide future functionality of any variety.

Maintenance should not be expected for free. New features should not be expected for free. How much those two pieces of work cost should be dependent on future expected earnings for the developer and the perceived value to the consumer, not on whether or not they are "expected" by users.

For an argument that starts out pandering to the "users perspective", I don't see how having a dedicated upgrade process is less "pro-user" then in-app purchases. Not only does it introduce more testing (altering the expected earnings vs. perceived value equation) but it also inserts delivery and design issues for the purchases which wouldn't be necessary with an upgrade system.

To me this looks lose(devs)-win(apple)-push(consumers)

Just different types of thinking I guess.

I justify charging for new features, not maintaining the ones the user already paid for.

> Maintenance should not be expected for free.

Users who purchase an app definitely expect there to be maintenance on the app. This is because we know no one tests their app to 100% perfection.

If I knew that the app I get at the time I pay is all I get with no future updates, not even bug fixes, then I'd wait several months to make sure no one else finds any bugs before I ever dare to buy the app. So developers give users the expectation of future updates and fixes to assuage user fears so that they actually buy the 1.0 release and give the developers some money to keep living on.

If I've paid for an app, then I expect it to work. If it's not working, then I expect you to fix it. I don't expect to pay for those fixes.

Features, on the other hand, I expect to pay for.

To address your point: this might seem like a good idea until you follow it to its logical conclusions. The support burden, especially on smaller developers, would be massive after even a small number of upgrades. Moreover, it's unclear how this would work in practice given that new purchasers of the app should have access to the upgraded features that old users need to acquire through IAP.

To address your side comment about laziness: the author of the original post is Wil Shipley, the guy who started both Omni Group and Delicious Monster. In other words, he's one of the longest-running and most financially successful "indie" devs in the Apple community. When he says stuff, people (including people at AAPL) pay attention, because what he says is a product of both a lot of experience and a lot more customers than most indies will ever see.

I wasn't directing the laziness comment specifically at Wil Shipley, I'm sure he isn't. It was more of an aside; a widely generalized comment. Most of us know "indie" devs aren't lazy. It was more to the point that it is easier to complain about what you want than to work with what you've got.

To address your counter point: it is all a mater of implementation, implementation, implementation.

1) I don't think it is unreasonable to say that developers should maintain the features they've already been paid for gratis.

2) It require planing from the get-go within your app, you can't tack this on after the fact. Basic features are covered by the initial purchase of the app. Additional features (AKA what one would want to charge for with a major version upgrade) or perhaps feature "packs" are provided via In-App purchases. New users always start out at the same level, requiring purchases for new features. Features already purchased to be restored via the facilites available in StoreKit.

I understand where you're coming from, but I guess I still can't agree.

1. Nobody's saying this. The original post actually asks for the ability to maintain older versions in the app store (so that, presumably, users who don't want to upgrade don't get stranded) while preventing new users from purchasing anything but the latest version.

2. So after three major upgrades, the experience for new users is: pay for app, then pay for three "upgrades" from within the app? Or even just one "roll-up upgrade" that implies all of 'em? And same for re-downloads: install the app, then restore purchases?

That sounds like a very un-Apple-like user experience; it's not something I would want my users to deal with.

Can you currently do in-app purchases on the Mac App Store? That was my first thought as well.

Yes. You can. However, I would much prefer the world Wil describes over a world with in-app purchases.

I would much rather pay the 20$ or whatever to upgrade my software, than be nickel and dimed all over the place.

I agree on the nickel and dimeing, but that is a matter of implementation.

Imagine In-app purchase options for options X, Y, an Z, $0.99 each. I only use X, so I'm only going to buy that. You use all the features though, so the developer provides an In-App option for all three features for $1.99.

Still feel nickel and dimed?

Yes. To put it bluntly, when I see features priced that way it looks like artificial price inflation to get more money. Especially in software that already has a purchase price.

Don't IAPs reset after you reinstall, and you need to "purchase" each one separately, and then the purchase is free if you already bought it but there is no prior indication of that?

If so, that is pretty crummy for your best customers.

The ability to restore previous purchases to an app is built into In-app purchases, the developer just has to implement it.

Reply on news.ycombinator.com