As much as I support Apple and have been since 1979, including being an early Mac developer in 1985 and even working there in the horrible mid-90's, the major problem is that Tim and Jony don't care (and Steve didn't either for that matter) about developers enough to do anything more than what works for Apple. Whether the people in charge have no budget or don't care or are hamstrung by politics, nothing will change until and if the top people start to care. Apple makes so much money even with all the crap we have to put up with as developers they clearly have no reason to change and sadly I don't expect them to. You don't tell the world's most valuable company how to run their business. It didn't work for people telling Microsoft in the 90's or Apple today.
Its just as bad if not worse from a customer perspective. The Mac App Store is basically the antithesis of what Apple is theoretically about ("the details") while at the same time highlighting everything Apple is bad at (ahem hem >services<). Some simple examples:
1. I go to buy an app, oh, I already own it. I know since it says "Installed". So helpful, now I can go search for it again on my computer. Compare this to the iPhone where it isn't completely idiotic and instead of "installed" says "open" which you can click on.
2. Type "Diasy Disk" into the Mac App Store search. You'll get 5 results that AREN'T "Daisy Disk". That's because Apple couldn't search their way out of a paper bag.
3. Let me send a link to this app to my friend. Of course its buried in an unlabeled drop down since sharing content is a decade ahead of any thinking going on at Apple. Let's not try to get any network affects for these apps, that would be silly.
4. The top 10 is full of apps I already own. Super useful. Really makes me want to open this thing up periodically if I'm feeling spendy. Heaven forbid the tailor that page to at the very least show the top 10 apps I don't own. But we live in a world where selling me toilet paper online is more sophisticated than applications.
4.1. My favorite is that #2 on top free is OS X Mavericks. How about just putting up a banner telling me reasons to upgrade to Mavericks instead of eternally taking up a slot in the top 10 free essentially making it a top 9? Especially when most your customer base is already on Mavericks and thus making that slot the most useless slot ever.
5. Hey what was that app I was looking at yesterday? Welp, since we chose to make it a super-fast amazing native experience, I don't get simple features like browsing history that I'd get from this being in a browser. But hey, at least all these 3d graphics in the Mac App Store are crazy performant right? Now if only I could view two apps at once, you know, like maybe two competitors I'd like to compare, in tabs...
It's funny because they ended up having to mirror the content on the web anyways, so the Mac App Store is now the worse of the two options you get (the other being google -> mac app store pages)
At least (1) has been finally fixed as of late. An "Open" button at last.
I see MAS as a good entry point for novice Mac users. But Apple could do a better job at curation here. Unlike on iOS, MAS apps have a bigger responsibility with user data, since even with sandboxing you can lose files or have your data sent across the wire. Check out the reviews for countless "disk cleaner"-type apps.
Seeing apps like [1] repeatedly in top 10 makes me lose faith in the review process. Macs don't need users to manually manage "free" memory. By "freeing" memory you're purging the cache and forcing the system to reload things. Hey, at least it's free.
Another: seemingly dozens of poor clones of built-in apps like Preview, complete with one-star reviews. For example, [2] by a developer who published 60+ (!) apps of similar quality. Or, [3], same situation but with a $6.99 in-app-purchase.
The lack of tabs drives me crazy. A few other letdowns on the user side:
6. No wishlist and no way to gift apps to friends (textbook example of leaving money on the table).
7. No way to rollback to old versions (particularly relevant when crashing bugs are introduced).
8. No way to transition from a non-MAS customer to an MAS customer. If I have equity in an existing program I purchased, possibly at great expense, I have no way to get the features of the App Store (updates, iCloud, etc) without paying again. And the developer can't do anything about this, even if they want to.
6 exists for the iOS App Store. It's a shame it doesn't (yet?) for the Mac App Store.
7 is meant to be handled by the developer or possibly by Apple, not by the consumer. If you have to manage versions manually, Apple has failed you.
8 can be accomplished by publishing the app as one of those "free + unlock" apps, but allowing the user to enter their predated proof-of-purchase to trigger the same effects purchasing the IAP unlock would. Apple disallows selling "things that are also IAPs" outside of the store—but as long as you stop selling the app through the non-MAS mechanism when you start selling it through the MAS, you're not violating the rules, because you're only validating previously-existing codes in the app, not issuing new ones. (So there's no way to purchase anything now equivalent to an IAP from you.)
The problem with 7 is it puts the developer in control, not the user. What if the developer releases a new version with a drastically reduced feature set (ahem..iMovie). I should be able to choose which version I want to run.
iMovie is an exception that proves Apple's usual rule: in most of Apple's own apps (Quicktime, Aperture, Xcode, OSX itself) each major version is its own separate app.
This fixes both the "paid upgrades" and "choosing what version you want to run" requirements, very simply, as long as you do it correctly.
Most importantly, you'll need to make MyApp N+1 discoverable from MyApp N (likely by an update with text such as "click to see MyApp N+1 on the app store.") For example, look at how "Transmit 3" (one app) talks about "Transmit 4" (a separate app).
You'll also probably want to sync IAPs to some more canonical source of truth than Apple's own servers, such that your app can ask "has the user purchased IAP X in [any of our apps that provide IAP X]" rather than "has the user purchased IAP X in this particular app." Then IAPs purchased in MyApp N apply to MyApp N+1, and vice-versa.
Aside from all the little quirks of MyApp N+1 (multiple versions of the same app installed, new users accidentally buying old versions), there is one major flaw in this practice: upgrade pricing. I'm usually happy to pay $20-40 for a solid upgrade on a $100 productivity app; if I had to pay $100 all over again, I probably wouldn't bother.
If you charged $20 for both MyApp N and MyApp N+1, and made up the $80 difference in version-portable IAPs, then you'd get the pricing model you're suggesting.
A good candidate for this would be something like Photoshop, where $20 would get you the "engine" of Photoshop N, and then you pay $5 each for various brushes and filters. When you upgrade to Photoshop N+1, you're upgrading to a new engine—but keeping your brushes and filters.
Games could also work like this, though in that industry, the more common strategy is the "expansion"—effectively, keeping an entirely new version of the app logic/assets commingled with the old version but disabled using feature flags, and then unlocking it through an upgrade-priced IAP. (Now there's a thought. Could you ship two entirely separate binaries within one application bundle, and put a switch in your app's prefpane to toggle between execv()ing N or N+1?)
As an independent Android developer, I have the same feelings towards Google Play.
There have been many things about Play that devs have repeatedly brought up, but Google does not take action. For example, iOS has "Promo Codes" but not Play.
Another is not being able to migrate a paid app to IAP (In App Purchase) without pissing everyone off (the linkage is lost between what the customer already paid for and the new IAPs).
Not to mention the algorithmic jail you wind up in if you ever inadvertently get caught tripping some automated alarm in the googleplex.
I wish there was some strong alternative by now, whether Ubuntu Touch or Windows Phone. We need more options.
Well you wouldn't need a promo code for a free app, so that doesn't really solve the problem. Also, you can give out promo codes over the internet, but I wouldn't just install any .apk someone sent me.
The problem with the App Store isn't that Apple is making too much money from developers (they're not making more money than anyone else who retails products for you). The problem is that the App Store doesn't support stuff developers need, like upgrades, migration from previous licensing schemes, free trials (vs. in-app purchases of functionality). This was very much a Steve-ism (let's keep things simple for customers) but they need to treat developers as customers too.
I guess I never understood why a 'free trial' was not 'simple' but 'in-app purchases' is 'simple'. Many of the apps I look at get bad reviews because the app only provides a trial aspect anyway - 'full' functionality is unlocked as 'in app purchase'. And people down vote for that (feeling they're being misled).
The key moment was when they allowed in-app purchases for free apps in October 2009, after introducing IAP in March 2009. If they had held that line, the app store would be a much different place.
I wonder if a simple fix would be to add a button next to the existing "free"-labeled download button. The new button is labeled with a price and would purchase the in-app "pro features" in addition to starting the download.
They already have something like this. They list the top 5 in-app purchases for an app right on its page. For example, for “Mini Motor Racing” (never played it, but it’s highlighted today), it shows that you can buy “30,000 career cash” for $0.99, or “Unlock all purchasable cars” for $2.99. Sounds like problem solved to me!
Right, the money isn't a problem, it's just something of a cause -- because they're doing so well at the moment, they don't have incentives to change and it's very easy to take the money they are making as a signal that they're doing things right.
I like the idea of making it easy on customers. I'd rather go through additional pain as a business/developer and make more money (better product) than have an ecosystem that is unfriendly for paying customer but nice for geeks like me. What I love as a consumer in my iPhone (compared to Android, etc.) is no upgrades -- annoying like hell. No messages about license changes (thanks God!).
Why you guys insist on making sure that your software is annoying to people who use it?! I don't get it. Where is Steve?!
Is it easier for customers to go to a website to download a demo version? This is happening now with MAS.
Or to use in-app purchases to unlock features? (I can get apps with subscriptions ffs, but not get upgrade pricing or free demos with a single activation fee that is diffrentiated from in-app purchases.)
Is it easier for customers to pay full price for a new version instead of getting upgrade pricing? Similarly is it better to force long-term customers to pay full price if you migrate to the app store?
Is it easier for customers to have to install betas from the developer in order to deploy a hot-fix that's stuck in the approval pipeline?
Now, I realize that in a perfect world developers would maintain their software for existing customers and sell new features as in-app purchases, but this is the real world, and sometimes you want to do major changes and not worry about how to shoehorn it into the MAS policy. And, of course, Apple doesn't have to eat its own dogfood here.
Everything you mention is either A: still part of the MAS or B: needed by both developers and consumers.
> What I love as a consumer in my iPhone (compared to Android, etc.) is no upgrades -- annoying like hell.
WTF? iPhone and Android have almost exactly the same upgrade policy. Both automatically update apps, and have done for ages. The only app store in the discussion that does ask you about updates by default is the MAS.
> No messages about license changes
Nobody mentioned this. Someone did mention "migration from previous licensing schemes", but that's about not making people pay twice for the same app, not bugging people about license changes. Besides, you do get something similar on iOS - it bugs you, as it should, whenever an app wants new permissions.
The MAS may be simpler for consumers than what we want, but it's not easier. It's a huge PITA for everyone who has to use it in any way outside of the single most obvious manner. These aren't even edge cases, these are just cases outside of the default.
The whole point is that nothing will change, as far as the consumer experience is concerned. You won't get bothered about upgrades or anything like this. All that would happen is you might see an "Upgrade" button in your list of apps you purchased. That's it.
Note that while the notion of paying once and getting infinite updates forever is quite nice, it's not rooted in reality. Either the app you're using will get abandoned or you will have to pay up at some point in the future, somehow - ads, IAP, etc.
Kind of makes me want to look more seriously into making apps for Microsoft platforms.
That said, Mac owners are generally far more likely to go out and look for new apps to buy. Whereas Windows users will find an app that does the job, and keep using that app forever (and recommend it to friends/family).
So even though there are way more Windows users, it seems more likely to make a living as an indie Mac dev than an indie Windows dev.
They're both not great, so you would just be trading one set of problems for another. You might want to look at building web applications, which also has problems. There is no perfect platform. You just have to figure out which set of problems hurts your business the least.
Disagree. Been building "apps" since when they were called programs for windows, Unix and Mac. Windows is the great constant, has the greatest overall power and flexibility. Unix is a mess of portability and build problems, mac has incredibly high framework churn and low longevity but as I've said already, stuff I wrote for NT4 in 1996 works today absolutely fine and I reckon it will in another 20 years.
Not only that, the market for well paying customers is huge if you ignore the volatile and unprofitable "store" model and sell bespoke and specialised stuff.
Don't solve popular problems, solve well paying ones :)
As for the web it's getting there but a lot of bigger clients won't touch it yet.
I'm primarily a Mac developer. From my outside perspective, the Windows framework churn looks enormous. The "best way" to write a Windows app went from Win32/MFC, to WinForms, to Silverlight and WPF, to WinRT, and still seems to be evolving. The preferred language has gone from C++ to C# to C++/C#/JavaScript(?), and now MS is pushing a UI framework that seems terribly ill-suited to what traditional desktop apps have done.
On the Mac side, the story has been constant since OS X first shipped: the best way to write a Mac app is to use the Cocoa frameworks, with Objective-C. There was some churn around garbage collection, and now Swift, but overall the developer story has been much more stable than with Windows.
Err we still use win32 and MFC. Plus some winforms which is a wrapper around win32 via the CLR. Not much has changed. Hell even WinRT is just a win32 wrapper. Office is a ball of win32 and MFC too.
Absolutely no one is touching WinRT or WPF apart from a few trading dashboard outfits and for win phone which is fine. It'll hang around but will still sit on top of the win32 subsystem.
Bear in mind there is very little difference between windows 1.0 code (1985) windows 8.1 code now. There's some 16 bit scum on the API but that's it.
I don't think Carbon was ever a recommended way to build OS X apps. It was basically a compatibility layer for vendors who couldn't easily rebuild their apps on Cocoa.
> Bear in mind there is very little difference between windows 1.0 code (1985) windows 8.1 code now. There's some 16 bit scum on the API but that's it.
That's like saying there's no difference between Mac OS from 1984 and Mac OS X. You're ignoring the shift from DOS-based Windows to the NT (New Technology) version which is more like VAX VMS (and had the same lead author). There were also some major changes with the introduction of .Net and the CLR.
You can take a program from the "MSDOS Encyclopaedia" which contains a windows 2.0 programming section, type it out in notepad on a windows 8.1 box, compile it and it will run now like it did in 1988. I tried it. It works.
That's what I'm talking about.
The kernel and CLR are irrelevant. Proof: the same program works on Wine on Linux after it is compiled.
I'm doing iOS now, but for Win I would choose Delphi if the price was not absurdly high. WinForms, WPF, Silverlight does not produce a self sufficent app. Qt is a great choice for Win, but about $4k per developer/year (for self sufficent app).
Cannot use Lazarus for DevExpress does not support it. Their amazing UI components and native nature of Delphi lets you build visually attractive and very fast and robust applications.
That's not a fair comparison at all. You listed pre-year-2000 tech for Microsoft, but not for Apple.
A fair comparison would include Apple's complete 180 from Mac OS 9 to OS X.
Furthermore, Microsoft has never once said that any of those are the "best way" to write a Windows app. They may give you more choices than Apple would ever give you, but they don't say "this is the best way" to write a Windows app.
Win32 is the core API of Windows and that fact hasn't changed since Windows 95. Winforms is simply a .NET wrapper around that API. You can even run pre-Windows 95 apps on Modern windows without an extremely heavy-handed emulation layer like Carbon.
I agree with your point about the time scale, but OS 9 and OS X are entirely different OSes with basically nothing in common but the name "Mac OS". It's more like releasing an entirely new OS, not shifting an OS by 180 degrees. Maybe the difference between DOS and NT is a similar comparison.
At any rate, if having a program run unchanged for the longest period of time is our gold standard, then I think MS wins. They have harmed their platform significantly by their total dedication to backward compatibility. By comparison, Apple has emphasized the quality of the platform at the expense of convenience to developers. I think Apple made the better choice for consumers (and even for developers in the long run), but it's certainly arguable.
I'd agree with millstone Every few years MS pushes a new UI framework (MFC, WTL, WinForms,WPF, WinRT, SilverLight) and abandons it after a few years. Other than Win32 which is not easy to use there really is no obvious choice which framework to use.
If I had to start a new desktop app for Windows I would probably go with Qt. I would not trust MS.
I'll concede that there was definitely more churn around the change from OS 9 to OS X. But the result was definite forward progress: the entire OS moved off of its legacy core. This was clearly a transition period, with both the legacy APIs and modern replacements clearly identified.
I don't think Microsoft's churn is like that at all. Instead it seems to reflect churn in their internal strategy. They attempt transitions, but abandon them before they are complete. There's no overall trajectory.
The latest is WinRT. Take a look at https://dev.windows.com/ . It's all about Windows 8, Windows Runtime apps, etc. Other technologies are buried. Wouldn't you agree that MS is positioning WinRT as the new preferred way to write for Windows? (If not, their messaging is terrible.)
This isn't 1998 and I'm not looking for some Mac vs PC flamewar. These are serious problems. They're making existing developers sweat, and new developers are taking a wait-and-see approach. It's hard to watch, but I'm optimistic about Nadella turning it around.
Oh, and Carbon is not an emulation layer at all, nor is it "heavy handed." Perhaps you have it confused with the Classic environment?
Have you ever actually worked professionally with Microsoft tech for any length of time? Have you followed Microsoft closely for 3 decades because your paycheck rides on knowing what's going on with them? If not, I'll forgive you for being an outsider...and yes, I meant Classic.
Microsoft has historically employed over 30,000 developers. That's a lot of people working on new software products. The "churn" you're talking about is, in fact, just more choices for you. It's crazy though you know - you don't have to use the latest thing from Microsoft! (We don't worship them like a lot of Apple-centric devs seem to do with Apple.) Sure, they're trying new things like WinRT and they'd like devs to use them. If things don't take off, they scrap them.
Who cares? You can still use a kit from 1998 (VB6) to make apps on Windows today without too much difficulty. Could you even use XCode from 2005 to make an app for OS X Mavericks? I doubt it.
According to your logic - web developers would never get anywhere because there's so much new tech/frameworks/etc being thrown at them and no corporation to tell them exactly what to choose.
I've been working professionally with Microsoft platforms since the early 2000s.
Not sure why you celebrate that Microsoft is treating everything but the latest as legacy.
His point is that after massive rework for OS X, more than 10 years ago, expertise in Cocoa has been remarkably stable and portable across their ecosystem.
Microsoft in the same time, has been through how many data access layers? How many networking/HTTP APIs? Web frameworks? GUI toolkits? All of it legacy abandonware now.
It's not free to have to continually retool to work with APIs that will still get bugs fixed.
Yes, using the 1998 API will still work. But that API will never be worked on again. Good luck if it has a bug that means something is impossible to do.
Microsoft errs on the side of throwing something out there before it's fully baked, and fixing it by introducing replacement APIs with the learnings from the first couple.
Apple's approach is to keep APIs private up until such time as they're ready to make them public, after which they commit to them and they'll be The Way To Do Things for a much longer time.
Which you prefer I guess depends on the type of developer you are.
That's a Win32 API call added for Windows 8.1 to their 1988 API!!!
As for bugs, you've never read "The Old New Thing" blog or played with the compatibility options for running executables in windows? http://blogs.msdn.com/b/oldnewthing/
They actually go as far as fixing all the bugs and backporting the actual bugs to older compatibility layers so software that relies on the bugs still functions properly when you set the compatibility OS version.
Regarding impossibility, there is literally nothing that I can't do with their APIs. Find something and I will show you.
Win32 is the only API that can be used in the long run and is maintained and improved by MS.
All the other APIs like WinForms, WPF, MFC, Silverlight, WinRT get abandoned after a few years. Yes, they still run but you end up with a codebase that uses outdated tools without a good migration path to a never API.
It would be really nice if they would actually stick to something.
> stuff I wrote for NT4 in 1996 works today absolutely fine and I reckon it will in another 20 years
What about:
- Plays For Sure?
- Silverlight?
- ActiveX?
- 16-bit apps?
- DOS apps?
- etc...
I'm sure any of the stuff that you wrote for Windows For Workgroups doesn't still work. I think that your 20 years prediction is entirely too optimistic.
Plays for sure was no different to iTunes DRM and m4p files. It died because no one wanted it.
Silverlight was a dead end I agree but it is still officially supported.
ActiveX is still supported. It's just COM.
16-bit apps and DOS apps worked until everything went 64-bit. Win7 32-bit could run DOS apps. This is a processor limitation. NT had a VDM subsystem for this.
Win32 abstracts away WFWG stuff so I'm not sure what your point is.
I'm writing this on a windows NT machine with 512Mb of RAM running win32 and WPF for ref (win phone).
> Silverlight was a dead end I agree but it is still officially supported.
For how long though? The parent post was talking about everything working 20 years into the future.
> ActiveX is still supported. It's just COM.
Are you disputing that there are companies still out there that have internal apps reliant on IE6? I'm not saying it's smart, but at this point keeping IE6 going has to be work. If they could upgrade, why wouldn't they?
> This is a processor limitation.
When you are predicting that your 18 year old app will continue to function out-of-the-box for another 20 years, how is hardware not a factor?
Yes 20 years no problems for windows API. Look how old the Unix API is. Not Silverlight although most of that is portable straight to c#+WPF deployed via ClickOnce with a few hours' work.
We have a company that has IE6 and XP deployed to over 1000 workstations. IE11 does ActiveX still. We use it via WebTwain to scan documents from a web app via a drum scanner. It works very well.
Hardware is not a factor. Don't forget that x86 is well over 30 years old already, isn't even CISC under ISA any more and there is virtualization and emulation as well. I saw windows 95 booting on a wrist watch in the tech press the other day.
> Don't forget that x86 is well over 30 years old already
Don't say that too loudly. I've seen some 'passionate' Internet argument over how all of the terms AMD64, x86-64 and x86_64 are all wrong because it's really the x64 arch that we're all running on now. :P
"high framework churn" - an excellent description of the relentless API changes in Apple land, if I may say so. It is comforting to be able to run ancient applications on Windows compared to the inability to run apps built for Leopard on Mavericks (or even Snow Leopard), let alone anything from the Rosetta days (Homeworld 2 is now a useless game to me on Mac OSX).
What Microsoft has built around Visual Studio, on all stacks (desktop, mobile, cloud), is the result of a lot of developer love. Also - Web Essentials, MVC, JavaScript IntelliSense and debugging - all godsend to the modern web developer.
Believe it or not Ballmer wasn't just exhausting wind when he would scream about "Developers! Developers! Developers!"
Xcode has the same problems described by coldcode - that Apple cares very little. Swift was a step in the right direction but just the first step, let's see where it leads us.
(Disclaimer: that last part was told to me as advice by a lone indie dev who makes about $189,000 per year off his lone Mac app and puts nearly all of the revenue in savings. So I have a bit of trust in that advice.)
That seems anecdotally accurate to me. It's not hard to find "spiritual sequel" Mac and iOS apps that do quite well as people switch to them from older apps that are lacking in development or aren't as "cool" anymore, such as Cyberduck -> Transmit, iSSH -> vSSH, BBEdit -> TextMate -> Sublime Text -> Atom, and so on.
You don't have any knowledge at all about Tim or Jony's feelings towards developers that the rest of us don't have.
Some counterpoints:
Why does apple keep investing in APIs for developers who they don't care about
Why did Tim make a speech on stage at WWDC about how much they care about Developers. You seem to be directly accusing him of being a liar.
Now, I actually agree with almost all of the linked post, and I am an iOS and Mac developer myself.
Software has been devalued by the advertising supported models of the Internet changing people's expectations. That's the root problem, and it wasn't Apple's doing
Could Apple do more to combat this? Yes, I think they could, and should, and I hope they will. But as long as you have their largest competitors doing everything they can to devalue software, you can't complain that Apple should be making sure their customers have to pay more.
Let's also face another hard truth. There is a lot of software that just isn't that valuable. People are willing to pay money for things that a) make their life feel better, b) save them money, or c) help them make money. The vast majority of apps just don't do any of these things well enough to be worthwhile.
If anything, consumers are spending too much money on worthless software.
Talk is cheap. What actions has Apple taken to demonstrate that they care about facilitating the businesses of developers using the App Stores? They've added APIs, tools, even a new language, but the only improvement I can think of for the App Stores is video preview.
While it's not Apple's job to enable every possible business model under the sun, they ultimately hurt both themselves and users by trying to force everything into the "game vending machine" model, not to mention the app types which are forever excluded due to sandbox restrictions (see Panic's experience with the MAS, for example [1]).
It's not just about revenue, but about process. For instance, the delay on bug fix releases could still use a lot of improvement. (Disclaimer: I work in web-land, where a deploy time of more than 10 seconds is laughable.)
But even just on the revenue metric, as mentioned in the article:
- Trial periods (especially relevant for softare over 5-10 bucks).
- Paid upgrades (many producers of high-end software can't be sustained with new purchases alone, and faking it with in-app purchases or "MyApp 2" is a terrible experience for everybody).
- Permanent sandbox exceptions for apps that genuinely need them.
- Lower the ridiculous, quasi-usurious 30% tax. I don't expect Apple to do this, but in the Mac realm where developers have other distribution options, the buying convenience and visibility may not be worth the revenue hit. If Apple has the cash to make iCloud a loss-leader for selling shiny gadgets (and they do), they can afford to make App Stores revenue-neutral or even a cost center.
Note that every one of these deficiencies is a loss for developers and users alike.
The Apple cut might be "officially" 30%, but less well known is that developers who are doing their own marketing can recover an additional 7% through the Apple sanctioned affiliate program, bringing that closer to 23%.
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?
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.
Well one thing they’ve done is ensure that all apps are sandboxed so that I can be sure when my mother downloads an app, it’s not going to be a vector to infest her computer.
Sandboxing is an excellent default, but the lack of permanent, specific exceptions when they're genuinely needed is what blocks whole categories of apps needlessly. (Your mother is probably not likely to download a pro FTP client.)
Sorry for the brutal truth but it is what it is.