The consensus among all the devs I've talked to is that this feature will magically appear the next time Apple does a significant update to one of it's bigger ticket apps... Final Cut, Aperture, Logic, etc.
I can't see any way they can get around this problem without adding paid updates.
Nothing in Apple's recent history suggests this is true. Think of the recent kerfuffle over Final Cut; they had no intention of continuing to sell the older version even though the new one was feature incomplete.
It is highly likely that, when it appears, Aperture4 will similarly just replace Aperture3 at approximately the same price point. You can choose to buy the new one or not, but there's no discounted upgrade path.
Based on Shipley's numbers, it would seem that developers wanting to make money long-term on the Mac App Store would be wise to get on the same "lower initial price, but all major upgrades are full price" app model as soon as they can.
We have yet to see this problem. The switch to FCPX was the first version in the app store. There hasn't been a high priced Apple app that has received a major upgrade via the Mac App Store.
You may be right that they are going to stay at low initial / full price upgrade... I see two issues with that (for Apple).
One, if the upgrade is not major enough to convince people to shell out for it. This fragments their apps ecosystem, and increases the support headache.
Two, how do you carry people forward to the new version. If it's a separate purchase, that means it's a separate bundle, and won't show up as an update when you check for updates in the mac app store. Again causing confusion and fragmentation (you now have FCPX and FCPX.1 on your machine, which one opens that project file?).
Again, I could be wrong, but Apple's current strategy look unsustainable to me.
When Aperture was added to the App Store, it cost the same as the standalone upgrade version, lots less than the full version. That could be a signal that upgrade prices are the new full prices, but we're trying to extract a lot of data from only a few tea leaves.
If the vast majority of your market is upgrading, and the customers for your new product, are by and large the same as the customers for your previous product, then you can simply offer the upgrade price to everyone, without loss of revenue. Indeed, you make it easier for new customers to come on board - so, best of both worlds.
I'm not sure what's wrong with offering major new versions of your product at the upgrade price to everyone (new and existing users alike). Sounds perfectly sustainable.
This may be the "least bad" choice, but it still isn't a good one. Besides the lost revenue from new customers, Wil mentions another important problem: If existing and new customers are charged the same price for an upgrade at least some existing customers are likely to consider it unfair (especially given past practice in the software industry) and to be angry about it.
That may or may not be a rational response. After all, if someone thinks an upgrade is worth $X, why should he or she care whether or not a new customer is getting the same price? On the other hand, a developer demonstrating that they value customer history and loyalty (with a discounted upgrade) is a strong signal that they value the long-term customer relationship. That is something a customer could rationally care about. Either way, the potential for existing customer anger is a problem developers will have to deal with.
Wil's post might also be a pre-emptive strike against potential, future customer anger. After all, if a customer complains that they're not getting a discounted upgrade, he can point them to this post.
Which honestly underscores one of my biggest complaints when working inside Apples ecosystem. I always get the feeling that they're building solutions for themselves first, and developers second, they don't take an agnostic approach to creating a platform. A good example of this is when you look at their UIKit and Appkit frameworks, all of the components were designed to the specific behavior that Apples engineers wanted at that time, with no thought on how to easily extend them. Compare this against other frameworks that were intentionally built to be easily skinnable and customizable.
They don't release paid apps on Android because it's not their business model to charge for apps; they don't even charge for Android itself. But they do release pretty serious apps, see recently Chrome for Android.
Google pretty much do the other way around: they build tools they need for their own developments (Closure Library, v8, Go...) then release it Open Source for others to use.
Your first point isn't really valid, they are an ad company, paid apps don't fit their business model. Providing a phone OS, ad service, and free apps that interact with their core services however are.
The second is more interesting though. They actually do use it quite a bit. Its the kind of thing they use internally, and the employees use for personal projects or when they need something technical for an external presentation. Also, app engine is probably built to serve a different purpose to their other services.
"The alternative is Google, who doesn't release any top-tier paid apps on Android or Chrome Web Store."
Google's business model isn't to release paid apps on their stores. They have many free apps that are downloaded by the 50's of millions and have 4.5-5 stars almost across the board so, yes, they do release top tier apps.
Compare Google Navigation on Android, to TomTom on iOS. Navigation is free, works perfectly, and even goes so far as to include a "Car Mode" for docking your phone in your car.
TomTom costs, at last check, $95NZD. I've not bothered trying it.
I think the difference would be that TomTom supplies it's own maps in the App, whereas Google Navigation probably downloads the tiles/street view as you go.
This can make a world of difference when travelling abroad when you can't be bothered getting a local data plan.
I definitely use GPS navigation more often when travelling than when in my home country.
Google Maps for Android comes to mind. I guess "top tier" on a mobile phone is still in the tens of dollars right now, but I haven't seen an alternative (free or paid) that comes close.
Mail and calendars are also better than anything I've found in the market...but that's maybe just my preference.
That's a bit disingenuous. The fact that Google's offerings are both good and free significantly reduces the likelihood of their being expensive alternatives. It's a self-fulfilling prophecy.
There are companies that sell software that competes with things like Google Docs, Navigation, and other services. And yes, you can always point to things they do differently, but that's guaranteed. No one is going to pay $50 for something that exactly duplicates a free service that has more name recognition, so you by definition have to do something to differentiate yourself.
That's a fair criticism, but the flip side of it is at least there is one real user of the frameworks they are building, which proves that in at least one situation the provided functionality is useful. Sometimes it seems like frameworks coming out of other big software companies provide what they imagine their customers will want, not what is actually useful when building real applications.
There is one very important stakeholder you are ignoring in your analysis - the end user. Apple creates stuff not for devs or themselves, but for the real customers - who are the users of their devices and comptuers.
In the case of paid upgrades, if it pains customers and leads to lower device sales, then Apple will come up with a solution to it. Developers (and Apple's internal team as well) come in at a distant second place.
The product teams absolutely should be focusing on the end user. However, the platform and framework teams should be supporting the features/tools for all devs. My criticism of the platforms that Apple pushes is that they seem to focus more on the specific needs of their internal teams than the broader needs of all the other devs that will be helping to grow the platform.
The line I occasionally hear in the apple dev community is "you can't change x/y/z on that component, you need to rebuild it from scratch", which time and again shows a very narrow focus in their tooling.
I have run into those kinds of problems, and it doesn't seem to be a huge burden to make a new component. My complaint is that Xcode is a POS but I have to use it.
It's not a downside of using your own tools. It's a downside of the Apple way where you use your own tools without a fleeting thought to how anyone else might need to use them.
Apple's development system appears to be optimized for the scenario that if you need some new method added, you can walk down the hall in your building at Apple and get someone to add it. But then they sell that API to paying customers who don't have that option.
Full price upgrades works for Angry Birds, but anything less episodic or standalone and you have problems. See Tweetie 2, for an example.
This issue is going to be rampant in the Mac App Store very very soon. It's been out for what, a year now? Time for a round of big updates... now you have two copies of all your apps.
What's the example, exactly? Genuinely curious. I upgraded to Tweetie 2 as soon as it came out. My impression was that it was very successful right up until Twitter bought Atebits.
It's hard to say how much of that was noise, and what effect it had on sales / success, but there was a lot of hype about the paid upgrade leaving people unhappy.
Example headlines (Google "tweetie 2 paid update" for more):
"Tweetie 2 Pricing Controversy: An Interview with Tweetie's Creator ..."
"Tweetie 2: 'New App' – Will Spit On Existing 'Old App' Users | iSource"
"Still won't pay for Tweetie 2 upgrade? Try these Twitter apps ..."
"Tweetie pricing fuss highlights App Store flaw | Macworld"
Fair enough. I'm not sure a mechanism for having paid upgrades under the same name as the original app would have avoided any of those headlines, though.
You don't? If people had complained about being charged a reasonable, discounted upgrade price for Tweetie 2, they'd have been laughed at. That has been a common model for software upgrades for as long as I remember (and quite probably longer than I have been alive).
People always complain about being asked to pay to upgrade. If they don't get a discount, they complain about that. If they do get a discount, they complain that the upgrade "should have" been a free minor version bump instead.
In my experience, at least, it's more or less just a pathological behaviour that you can't escape.
Angry Birds and other games are in a totally different category. If you buy “Angry Birds Space” it’s reasonable to assume (a) you’re done with the original, and (b) you’re going to get as many hours of enjoyment out of it as the original, so it’s fair to pay as much.
This isn’t the case with productivity applications, necessarily – you can keep using Delicious Library 2 and it’ll keep working great, so we need a way to reward customers who say, “Yes, I’ll pay to have some extra functionality.”
I was thinking the same thing, but I don't think that's sustainable, nor is it a good user experience. If you have X choices of IAP features available, are you going to test the 2^(X+1) configurations out there?
Probably the best you could do with IAP is offer current version as IAP, and roll your n-1 features back into the main app as a free update on a periodic basis (i.e., want the latest and greatest, buy it now, or wait X months/years and get it for free).
Nickle and diming your customers for features also leaves a bad taste in the mouth.
As a customer, I appreciate Apple's model since I know all updates are free and any major version changes usually warrant a new app entry (I find it annoying, but understandable, that the previous version is sometimes retired from the App store), which makes the demarcation clear of what I need to pay for vs. what I don't.
I think ianterrell's idea was that, if you're going from, say, version 2 to version 3, you release version 3 for free, but all the new version 3 features are a single in-app purchase. No nickel and diming.
One result of this approach is that everybody gets bugfixes for free, which users are sure to like better than a model where they have to pay for fixes.
One thing you have to decide is what to do if you then release version 4, and someone never paid for 3. Does he have to pay for 3 and 4 separately, or can he just buy 4 and get the 3 features for free? (I'm pretty sure you don't want to let him buy 4 and not have 3; that's where you start getting configuration explosion.) The latter has precedent in the packaged world, with vendors that would give you the same discount when upgrading from any earlier version.
All new features are paid for as content upgrades currently are.
If you overhaul your code you release it first as a free demo (old language; beta), then discontinue it as you release a feature-matched-update to the single paid for version you maintain.
This reduces new features to an individual cost upgrade and ensures your existing users aren't left with an unsupported version.
This is actually a very good result for the consumer. (I'm thinking premium applications such as Audio, Photoshop etc.)
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! :)
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"?
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.
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)
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)
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.
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.
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.
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 Mac software scene has always had lots of indie developers. Let's look at that scene for some facts... The indies generally charge an upgrade fee for "major" versions, and give free upgrades for "minor" updates.
Most, like Wil, do the right thing. Delicious Library hasn't had a major release in years, but it is maintained.
Others (for example, in my experience "DVD Remaster Pro" and Parallels Desktop), clearly abuse the major update system as a revenue source. They release fake major releases with lots of new skin but few features every six months or a year to rake in the dough.
Honestly, it's a mess. But the solution to me is obvious: Angry Birds from Rovio. Rovio didn't just release the thing and stop. They keep adding significant features (the game is probably 10X as large as when I bought it for the iPad). Customers feed back with great reviews. Rovio is rewarded with continuing sales and stays in the top seller lists. Meanwhile, apps like "Plants v. Zombies" are static and drop off the top lists quickly after a quick burst of popularity.
Angry Birds is one of the most popular applications for the iOS platform ever. It has sales in the millions, and this model isn't comprable for indie software that doesn't have that big of a potential market.
Rovio also just released Angry Birds in Space, which is a separate app, meaning they'll get new income from it. But because it's a $0.99, giving existing customers a discount isn't important.
A game is a different animal. If you add some new levels to a game people have finished, they’ll dive back in. That’s news.
If you’re making a productivity app, and you dribble out features, the press is going to ignore you. Can you imagine anyone running a story like, “Delicious Library 2.8 is out, and it includes a pretty new way to look at tables”? It’s just not going to happen, unless your name is Apple.
The press hit we get on a major release is part of what gives us the important spike in sales. It creates “buzz.” There’s a reason why even Apple doesn’t, like, just release iOS 5 feature-by-feature – they want to spring the whole thing on the world, so they get a ton of attention.
Perhaps the incentive is the wrong one. If the goal is to get users to upgrade, offer a launch sale that entices existing and new users to upgrade.
I don't think it's so terrible that there is multiple versions out there. Reduce the price of the older version and setup the page to let people know there's a new one out there before buying.
I feel like the solution isn't paid upgrades but instead monthly/yearly subscription for access in the Mac App Store. The 'appification' of the web is eliminating the idea of major release "versions" of software...it's just an app in consumers' minds and it will always be the same product (with gradual improvement of course). As a result, just charge users for ongoing access to your app and keep them paying by providing regular updates.
I had an idea for a subscription service that would give developers a share of the subscription based on how much their app was used compared to other apps. That may work perfectly for the Mac App Store.
So I pay 10 dollars a month to have access to the MAS and I download 3 apps. I use App A 50% of the time, App B 20% of the time and App C 30% of the time. (To keep the math simple lets pretend Apple doesn't take their share).
App A's developers would get $5 a month, App B's developers would get $2, while App C's gets $3.
Maybe to handle the Pro apps like Final Cut you could have different subscription tiers?
To users, this would be a simple netflix like subscription model. Developers would have an incentive to make their apps more useful and engaging. (I'm sure it could be abused too)
Interesting idea and somewhat akin to how music streaming pays the artists (well, the labels mostly). The challenge, as you allude to, is that software is a lot less homogenous. You only do one thing with a song--listen to it. You use software in a lot of different contexts and it's not obvious that time running is going to give equitable results. And Pro-ishness is also very context-dependent. For me, Final Cut might be a hobby thing. For you, it might be something you depend on for your livelihood.
That said, I do think we're going to see more experimentation with subscription models. Adobe's Creative Cloud is one example. I could imagine some sort of aggregator of games as well.
As with other ideas mentioned, depends on the app. In general, I think people have a limited appetite for subscriptions because every subscription is a "money leak" to be monitored and managed. There is something of a trend in that direction but I'm skeptical that it becomes the standard way to pay for software.
Saas sucks for the user but is great for the developer because people forget to stop the service. Also that protects them from copyright violation, which most users of this site believe is their natural born right.
I think this is mostly a mismatch in expectations. "pay full price, suckers" only rings true if it's not actually a major release - small features, security/compatibility updates should be free. A new version should offer enough benefits to be worth the price.
I don't know if I agree with this sentiment. Take the author's app, "Delicious Library 2". The main functionality of this app is to catalog your things in an easy and streamlined way. I'd reckon that most people are paying the ~$35 for this app to do just that.
If the developers develop a whole new set of features (while still building off the core functionality) that they could call "Delicious Library 3", but are actually fully compatible with Delicious Library 2, why should they have to ask their users to pay full price for an upgrade, when they already have the core functionality which is the draw for the new users to pay full price.
I've seen positives and negatives to this model in video gaming. I love seeing a full-feature expansion to a game I own, and don't mind paying $5 - $20 in addition to the $60 I already paid, but I wouldn't be happy paying $60 again for the "complete" edition just to get the expansions, but that "complete" edition is great for people who haven't already purchased the game.
I’d rather offer existing customers a discount, since I figure some percentage of what they’re getting is the old functionality, and they’ve been there for me in the past.
Put differently: if I’ve written an app that 50% new, don’t I deserve to get paid by existing customers for that work?
I really like how most applications in the iOS store have been about upgrades. When a new version comes out I get it automatically without paying. Camera+ is a great example.
Because the user base for the platform has been growing the potential install base for your application grows with it. The graph in Wil's post shows that the same application had a huge sales surge just because more people were exposed to it.
If a new version of Delicious Library comes out his existing customers will be very happy with the new features and bring more customers in with them. I bet Apple would even promote the new app and a huge sales spike would happen again.
In my mind the new model isn't how to get the most money from your customers, it's getting the most customers.
I find the current 'goat users into paying X/per year to keep things current' model so distasteful that I will seek any and all possible alternatives before I consider buying any app. I tend to think developers would sell a lot more if people only had to pay once... but who knows.
"I've looked at clouds from both sides now..." I've been an app developer and an app buyer. As a developer, of course I want to get more money from my installed base. They're easy to find; marketing costs are essentially zero. As a buyer, I've always looked at "upgrades" as a scam to suck more money out of my pocket for a product I've already paid for. I hate it more when I'm paying to get bugs fixed - bugs as a money-making opportunity! - and even more if I'm blackmailed into upgrading by the threat of dropping support for my existing product, which, of course, will stop working about 10 seconds later. I have some software that seems to be "upgraded" for a "discounted price" every two or three months!
How about you stop treating software like fresh fruit delivered with a worm in it and start treating it like, say, new cars? Sell it with a warranty. Allow me to extend the warranty, up to a point, for a reasonable price that covers maintenance only. If I have a reason to buy a shiny, new 2013 BozoWare, and the reason isn't that the 2012 model is already broken, I just may. Some people buy new cars every year; everybody buys a new one sometime.
I assumed that Apple would add upgrades way back when but I now think the in app purchase model is better. Consider the reason for upgrades: new features? Sell them. Compatibility or big fixes? Why aren't these free for all customers?
The one missing thing I think Apple needs is a neat mechanism for allowing existing apps to be upgrades into app store apps.
The model of selling only the new features really doesn’t work well when you’ve spent years refining every part of an app. How do you “sell” a whole new interface?
Compatibility or bug fixes aren't free for all users because just like features, the developer had to spend time building them and needs to get paid for that time.
I build a house for you for $X. You find out that the lights don't work and ask me to fix it. Would you be happy if I told you "Oh, sorry I messed up the electrical connections. It'll cost you $Y though, because I have to spend time fixing them and I need to get paid for that time."?
You build a house for me for $X. Two years later, I notice that if you hang three towels on the bathroom door on a humid day while the living room light was on, the door didn't close properly. Would you be happy if I came to you and demanded that you debug and fix this problem for free? Didn't I pay for a working house the first time?
I very much do not believe that you paid me enough for me to guarantee that my product would work in all circumstances forever. If you did, then by golly I'm yours for life buddy!
If the problem is due to my poor worksmanship and it has always been there since the very beginning (even though you may not have noticed it for 2 years), I'd gladly fix it for free. Of course, with a bathroom door you'd have to prove it's not due to wear and tear, but this doesn't apply to software - the bits in your binary don't change with time.
In perpetuity? When a major OS upgrade breaks the app completely after being in use with no problems for 5 years?
Again we find that conflating real-world examples with technology issues is a bad way of understanding them. With a house you typically have a warranty period and afterwards are required to pay for fixes yourself.
There is a lot of grey here that paid updates help deal with. The users will vote with their wallets if they feel they're being thoroughly fleeced.
But why should the users be responsible for compensating the developer when it is Apple who changed something in the OS? Perhaps the developers should ask Apple to pay for their time.
The way I see software (excluding SAAS and software that comes with an explicit service contract) is the moment you pay your money, and the software is "fit for the purpose" that you were sold it for, you might be stuck with that version forever.
If there is a massive OS upgrade on the horizon that might break it - don't spend the money on it. Don't expect anyone to pay for it but the end user.
Expecting developers to support the product until the heat death of the universe without ongoing compensation is ridiculous.
Now of course there are variations on this that developers can be nice and provide if they feel like it, but I never expect anything I buy to have any more support than was explicitly outlined to me when I laid down the money.
Can't we just hop over to a subscription model altogether, now that we pretty much have the infrastructure?
It would lower up-front costs. I bet piracy would go down too. It would give developers an incentive to keep even small apps bug-free. It would make more sense for apps like Instapaper where the server needs to keep running. Everyone would get exactly what they pay for, and nobody would have to keep using an older version for artificial (financial) reasons.
The only downside I can see is that people cannot decide to stick with an older version because they actually like it better. But that's something that Apple customers are probably used to (e.g. surprise 10.6 users, no OTA contacts & calender sync for you anymore!). And for Apple, it may decrease vendor lock-in because people have no sunk costs anymore.
Something similar that the Mac App store is killing is the competitive crossgrade. It used to be a boon to buy Logic at full price, then be able to buy its competitors like Digital Performer or Cubase for half price. Currently the App Store can't support that.
Considered charging less for the full product (say $10), and simply having multiple versions available as you post major new releases?
That way, users always have a way to downgrade to previous versions as needed, you probably get more customers due to the entry price, and everyone just understands that the latest version is available for $10 more.
That seems to be the whole app store model: lower prices, more sales -- no "upgrades" in the classic sense. And, with a low enough entry price, I think users would be accepting.
If they don't buy the latest, as a developer you're no worse off than you are today (where they get the latest for free).
I want to say something about sharecropping, but I have a hard time thinking of the appropriate analogy.
It's making me think about the service model as being a superior revenue stream, for-better-or-for-worse. From a user's perspective, the MAS already acts as a service; the subsidy is just being paid for at the developer's end of the scale.
I love the iTunes/MA stores as a marketing and distribution channel, but I hate how heavy handedly Apple behaves with enforcing business models. I think there's an argument to be made that we can avoid the Android marketplace crapware without forcing everyone to become serfs.
Calling people who willingly cede less than a third of their profits for access to the giant infrastructure and advertising Apple has at their disposal is a bit of hyperbole. It's a mutually beneficial arrangement for both parties, which both parties are free to sever at any time. Doesn't seem like serfdom to me.
But it is effectively equivalent to sharecropping (with a somewhat lower percentage, I suppose), which some people reasonably consider a form of serfdom. Developers are willingly ceding 30% of their profits for the benefits of using Apple's infrastructure the same way sharecroppers willingly ceded a portion of their crop (typically 50%, but higher in more exploitative relationships according to Wikipedia) in return for the right to use an owner's land.
In both cases, landlord is more powerful than the sharecropper and can set "take-it-or-leave-it" terms (which, if you consider game theory, suggests that the landlord will capture most of the profits of the relationship - limited only by a sharecropper's alternative ways of making a living and their willingness to make decisions that are economically irrational in the short term in order to improve their situation in the long term).
I could even go on to talk about sharecroppers buying seed, fertilizer from the landlord and compare that to developers buying laptops, paying for developer programs and so on, but this analogy has probably been pushed far enough as it is.
Well… I don't know if "willingly" is the right word.
I can very easily imagine a near future where it's not rational for small vendors to opt out of it. You're not wrong; it's just… more complicated than I am capable of articulating at present.
IMO, there are just very real reasons to be weary of the shifting power dynamics in the consumer software space.
Non sequitor. The comment thread you're on argues that developers on Apple's Mac platform are sharecroppers. Atwood may well think that (it's not totally clear to me), but Shipley clearly does not: he is making more money after adopting the App Store than he was before it, and is content with the control/promotion tradeoff. He says so explicitly in the article we're commenting on.
Maybe the use of the word sharecropper has changed recently with respect to Apple, but as far as I know, it doesn't have anything to do with whether or not you're successful and content with the Land Owner's restrictions. It's meant to signify that you don't have full control over the ecosystem you're living in and that you owe part of the profits you reap from your hard work to the land owner.
In that sense, App Store developers are very much sharecroppers whether they enjoy and accept it or not.
Have you used Pages recently? It’s got a button in the default toolbar to “Publish on iWork” which has never been out of beta and is now cancelled. It doesn’t work in HiDPI modes of Lion. It doesn’t support Lion’s keyboard macros. I wrote one letter in it last week and ended up filing three different bugs.
So, yes, software does “rot,” if it’s not kept up-to-date with the latest operating systems and, to an extent, the latest user interface metaphors.
> And here I was blissfully unaware that Pages and Keynote had rotted into uselessness simply because of the calendar year.
This is a very good point. In this consumerist society, if a "new" version is not produced at least once a year, obviously the old one is not worth having.
I'm sorry I didn't read the whole thread and I know this is late.
Why not provide two versions of Delicious Library Inf? One costs $20. It only works/installs correctly if you have the original app. The other one costs $40. It is a standalone app. Make a minor bugfix update that says "hey" to the users of Delicious Library 2, and link to the expansion. Sell both.
Eventually, nearly all your users have already paid, leaving you unable to charge them for enhancing the app. You may have a huge installed base and eventually have no incentive to improve the product.
The App Store also also needs automatic/forced free updates. It sucks releasing something with a bug, creating an update that fixes it within a month, and still having users complaining about the bug several months later.
From the customer's perspective, it would kind of suck to buy an app because of a certain feature that, from your point of view, gets broken by an upgrade, and be forced to do that upgrade, because the developer fixed a bug or feature that is of no concern to you. Remember, the user is buying a license for the current version of a piece of software, not a SaaS subscription.
Example: I was searching for a tool for file deduplication. Looking at some older screenshots and the current trial of a certain tool, I realized that this was now less geared towards power users, with UI changes that made the tool look better for inspecting a few duplicated pictures but unsuitable for using lots (thousands) of files. Imagine being the user who bought the tool for more serious use, and is forced to "upgrade".
Yes! Especially with more expensive software. My software costs £150: No-one wants to fork out this kind of cash without a free trial so I get very few sales through the Mac App Store.
I can't see any way they can get around this problem without adding paid updates.
Until then 3rd party developers are high and dry.