Mac App Store: The Subtle Exodus
blog.helftone.com
blog.helftone.com
Sorry for the brutal truth but it is what it is.
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.
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.
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.
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.
Mac... You forgot carbon...
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.
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.
If I had to start a new desktop app for Windows I would probably go with Qt. I would not trust MS.
MFC+Win32+WinForms are equivalent with different wrappers. So is WPF/WinRT/Silverlight so that's actually only two tech platforms.
As far as WPF/WinRT/Silverlight go, they are different enough that it's hard to exchange any code between them or port from to another.
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.)
Characterizing these development options as MS giving developers "choices" is crap. WPF developers aren't excited about having WinRT as another choice, they're worried that WPF is abandoned and their investment is obsolete. They saw it happen to Silverlight. See http://pragmateek.com/is-wpf-dead-the-present-and-future-of-... for example. See http://channel9.msdn.com/Events/Build/2014/2-563 too.
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?
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.
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.
Whats this then?
http://msdn.microsoft.com/en-us/library/windows/desktop/dn30...
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.
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.
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.
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.
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).
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?
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 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
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.
Every business on the planet runs Windows and they all need new software all the time.
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?!
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.
> 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.
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.
Then add that to a pretty magisterial culture...
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.
They are unnecessary on Android. If you want to give your app to someone, you send them an email with a link to an APK and they install it directly.
It's hardly the same thing.
I run betas of the BeyondPod app, and it does exactly this perfectly well.
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.
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]).
[1]: http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/
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 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 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.
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.
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)
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.
[1] https://itunes.apple.com/us/app/memory-clean/id451444120?mt=...
[2] https://itunes.apple.com/us/app/jpg-to-pdf-converter-lite/id...
[3] https://itunes.apple.com/us/app/jpg-to-pdf-lite/id862295940?...
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.
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.)
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.
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.
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?)
The convenience factor is real, but it could be addressed by a better app installation and upgrade model. Apple is already way ahead there by encouraging all components of most apps to live in their .app "folder-file." What if the OS had baked-in support for update feeds from the app's developer?
The security factor though is a bit of a tragedy. Open desktop OSes have serious security issues around the installation of software. Instead of solving those issues in a way that does not degrade capability or restrict freedom, OS vendors have decided that it's easier and cheaper to sidestep them by just using the app store model and forcing all code to be signed. Your OS is no more secure... they're just limiting what can run on it. It's part security theater and part just punting on the problem.
Maybe if the app store model fails on the high end we'll get real solutions to these problems.
I've found that such conflicting feelings come up when I'm dealing with a poor solution to a nevertheless real set of problems. I think app stores in general are that -- they are a freedom-restricting, tax-extracting, capability-limiting solution to a set of problems around security, software package management, and quality control that could be solved much more intelligently.
What's worse, as you say, is that there's absolutely no indication that some of those apps have been abandoned (apart from the very old Last Update date). The vast majority of consumers will just buy the software and not go researching whether the app they're acquiring has been left collecting dust.
And at the end, both consumers and developers lose out.
You're quite right that the convenience is part of the big pull of the MAS. But as you say, this can be implemented separately. If you can get the critical mass with some major players behind it, it can become a standard in no time.
The security issues related to sandboxing are not insurmountable, either. We can have both sandboxed apps that have wider accesses so that we don't restrict the freedom of users.
I'd actually love if they could get the Flash plug-in into the app store, especially if it was a crippled version that could only play video or games, just to get rid of Adobe's updater.
What I want as a user:
I want to be able to see -- for each app -- exactly what permissions it requests and what permissions I have given it. I want them to be in plain language, presented in a way that is comprehensible to non-technical people but also to developers / power users. I want to be able to toggle permissions that are not required. (Obviously if an app requires a permission I don't want to give it, I have to just uninstall it.)
I also want to be able to see exactly what each app is doing. What it's talking to on the network would be high on that list, along with what files it's accessing or trying to access, etc. Obviously any privacy-invasive feature like location information is very high on such a list of things I want visibility into.
There could be "permission motifs" or "templates" to make things easier to understand. For example, a "productivity app" template might only give file access to Documents and network access to a limited set of endpoints and iCloud. A "peer to peer networking app" though might require promiscuous network access. A "hardware interface" might require kernel module permission (which would have a warning to the effect that this confers full administrative rights, because it does). A "VPN" might require the ability to open virtual network (tun) ports. And so on...
The app should be required to include descriptive text explaining why it needs each requested permission.
Finally, as a user I want some kind of summary display that shows the cumulative "exposed surface area" of my machine. What permissions have I granted where?
I also want convenient installs and uninstalls. By default I want automatic (secure, signature checked) updates, but I want the ability to turn that off if I desire. I want to be able to manage which certificates or CAs are trusted to install apps -- which would include self-signed apps. (Self-signed is superior to unsigned in every way, since it allows secure updates once I approve the self-signature.)
What I want as a developer:
I want to be able to request permissions that are as deep as are necessary to provide the functionality my users want. In a few cases (network stuff, virtualization, certain kinds of hardware support) this may even require a kernel module, but most of the time nothing that far-reaching is needed.
The thing is -- desktops/laptops are "power" machines. You do need to be able to do powerful and OS-extending things on them. But I want a security model where I can say precisely which apps I trust with those kinds of permissions. I don't want grant-by-default and I don't want total prohibition.
Microsoft actually tried to deliver something like that a few times, but failed. IMHO their failure is completely in execution. They offered a terrible UI and user experience where you kept getting pestered with security-related popups that didn't actually explain what was going on. If this was done well it could be quite revolutionary.
Essentially, the app store dynamics add stress to the process of shipping mac software for most developers and they add this stress at the end of the release cycle when a developer is already at their most tense moment.
Having deployed many products on Apple's stores, I can say that I completely relate to this and so did the crowd at Cingleton. I expect many other apps to follow suit...
The lack of trial versions aside (which is still a huge problem), one of the primary issues with the MAS is the flat-out exclusion of certain categories of application. For example, system utilities are almost totally banned from the MAS, and the system tools/ utilities that are currently available in the Mac App Store tend to just be slimmed down versions of their non-MAS counterparts with lots of functionality removed.
I speak to hundreds of OS X developers every week, and the sentiment around the MAS is gradually changing. Typically we're hearing developers just referring to the MAS as a marketing channel these days, due to the restrictions enforced on them.
We see a lot of data around MAS vs. Non-MAS sales, and reasons for developers switching, so if anyone has any questions about this space, I'd be happy to answer.
I have two questions for you:
1) Who is the vendor of record? This is relevant to handling VAT and it means either you have to do it or the business selling the software.
2) I couldn't find any information on what countries are supported, payment methods for receiving royalties, etc.
Thanks.
1). Paddle is the vendor/merchant of record. We handle all of the VAT/ sales tax liability on your behalf. Payouts you receive from us are a royalty payment, exactly as they are from Apple/ the MAS. (This is particularly relevant as of Jan 1st 2015 when the EU VAT regulations change, and become super complicated for indie devs).
2). We support most countries (all countries, with the exception of North Korea, Cuba etc.), allow payments from customers via Credit/Debit Card (Visa, Mastercard, Amex) and PayPal. Support payouts to merchants via PayPal, Local Wire (32 countries - List: http://padl.to/1qoAWNN) or International Wire (everywhere else).
Once integrated with our SDK, developers are free to distribute their apps wherever, be it their own website/ to their own audience, or via download portals like MacUpdate.
A couple of examples of apps using Paddle: * http://www.tunabellysoftware.com/tgpro/ * http://marked2app.com/
In most cases (from talking to developers) the distribution/ audience aspect isn't the #1 reason developers go down the MAS route. Lots of developers have their own audiences, or use sites like MacUpdate (or traditional marketing methods).
That said, we are working on functionality to help users discover applications. We currently have around 400k users (customers on the buy side) who have active accounts with us, and we're testing ways of recommending content to those users, in order to provide developers with that extra exposure/ sales volume on our platform. — Currently we're testing this via email receipts (for opted-in merchants) and via our web-based "locker" (where users who have purchased content can access their downloads/ license codes).
We've got a lot of work to do on the discovery side of things, and there are a lot of interesting things that we can do at scale, but discovery isn't our primary focus at the moment (building a great platform/ SDK for developers, and providing the foundation is our current focus).
Just tried going through the checkout. Clicked on Buy Now. Entered an email, clicked Continue, got to the country/zip screen, entered ZIP, clicked Continue and got back to the "Checkout as a guest" screen. It looped. Just FYI.
(edit) Tried with marked2app.com - same thing. The checkout form gets stuck in a loop.
Paddle initially started as a marketplace for all types of digital content, and we've slowly transitioned into this toolkit for developers, offering payments, trials etc...
What you see at Paddle.com is reminiscent of our consumer-facing marketplace days, and we're close to pushing out a new homepage (this week).
One thing we're not trying to be, is a marketplace in a similar fashion to the MAS, we're trying to be the technology layer that empowers developers to not need a marketplace, own their customer, and take back some of the control that they typically give up by relying so heavily on a marketplace.
I do completely agree with you that the current homepage being what it is, and what we actually do being located at https://www.paddle.com/sell is confusing for potential customers who might want to work with us.
This is changing this week. :)
Paddle itself looks awesome though :)
But I agree. Non-retina bugs me too. Not for much longer!
(And thanks for the kind words.) :)
I wonder if this is Apple's entire point in taking this stance. The cheaper, more numerous, and better the apps, the more attractive the platform, and Apple may be betting that developers will just put up with it, at least on iOS, due to their massive market share. The MAS system might be the way it is simply to keep in ideological step with the iOS App Store. That's the only explanation I can come up with for their bizarre behavior WRT the MAS.
Note that there are some very large difference between the software on iOS and Mac. On mobile system, the vast majority of apps are more akin to small consumables - like having a can of coke or a cup of coffee.
On the Mac, you have much more complex software, that can take years (and even decades) to develop. This software requires serious investment of resources and time. If the ecosystem cannot support it, it won't exist.
You're right that the iOS store is designed to encourage a lot of choice at low prices - that's what sells iPhones. This might be okay for consumables but a non-starter for professional software that exists on the Mac.
I.e., nonwithstanding the piracy, Photoshop makes Adobe a lot of money, and all that money comes from sales, and none of it comes from support or integration.
I don't think Apple really cares if developers are happy, nor do I believe this is by accident that prices are being driven down in the Apple App Store or the Play Store.
I believe both Apple and Google are happy to see the number of apps go up and prices go down since this results in a large number of cheap complimentary products to the phones and tablets in the case of Play Store and App Store, as well as to Macs in the App Store.
It seems like they are taking this straight out of micro economics 101.
Price of complementary product A (apps in this case) go down leads to increased demand for product B (iPhone, Mac, Android Phone, etc... here).
This is totally unsustainable for developers and leads to the majority of developers in the App Store failing, and hence the opt-outs we see from developers on the Mac app store returning to the old way of selling from their website directly and other channels.
From the Mac perspective this seems to mean low quality apps and sell once no upgrade apps (games for example) stay in the App store and enterprise or high quality applications continue using the old model of sales.
I don't think that is ideal, but at least there is a way for developers to continue to sell their products and so high quality products will continue to be produced.
I'm much more concerned with the long term viability of the App & Play stores in regards to phones & tablets. As developers we have no real alternatives to sell our apps outside of the Google/Apple designated marketplace. So I have serious concerns about high quality applications continuing to be realized unless something changes as over time the up front cost and risk to create new software just continues to get worse.
In fact, I'm such a fan of the Mac App Store that I wish every app could conform to it's rules so I wouldn't have to dig out a lame license key, or heaven help me, email the vendor for some time sensitive generated key thing.
Not that Apple would want Spotify in the store anyway, with it being an iTunes competitor.
With OSX it's a little different, as there are alternative channels for installing Spotify, which prevents OSX from becoming "a platform without Spotify", and also allows Apple to ignore them entirely, and push their own product in the store.
There are hundreds of apps that allow you to use subscriptions made outside of the App Store. The rules for digital goods and digital subscriptions are:
* If you want the actual payment/checkout to happen ON the phone THROUGH the app, it MUST be an In-App Purchase (subject to 30% cut). * Appendix: redirecting to a website for the payment is forbidden, because it would be a too easy workaround to the previous rule. * If you want the app to just connect and use an existing subscription made elsewhere, go ahead, nothing is owed to Apple.
Dropbox for instance happily works with the subscription made on the website. A couple of years ago, they ALSO added a way to subscribe to their paid plan through the app, in which case the 30% cut is paid to Apple. I can see they doing it because probably they don't want to lose customers that feel like upgrading with a single tap is much easier than going to the website and inserting credit card details. As everybody in marketing knows, when you're potentially one tap away from buying something, the sole idea of having to go to the computer and taking the wallet is enough for a turndown for most people; impulsive buying is a strong force.
I didn't think Apple allowed this, but they are doing it.
Not having that feature has easily stopped me from giving at least 50% of apps I've found a shot simply because I don't want to make a blind purchase based on 5 screenshots.
I'd personally give priority to upgrade pricing and trials, but I'd still like to see Google Play's approach implemented by Apple here.
For example, there might be 4-5 apps in the $30-50 range that I want to try. I'm not going to spend $150 and then having to request a refund for the rest - it simply won't happen.
I think that will be a big boost for Windows Store Apps when Windows 10 comes out.
Not being able to charge for updates is a problem that affects almost every single paid app (assuming the app is supported across multiple versions and major updates) in all the app stores. This is an unsustainable proposition for most developers.
At a recent Seattle Xcoders meeting in Redmond, our speaker spoke about how he had given up his indie business and had now switched to contracting (disclosure: I run this meeting and had asked the speaker to speak).
At the meeting, I noted that Apple made its profits through hardware and they could therefore afford to make their software free. Similarly, Google is an ads company and so they don't need to charge for their software. However, the dominance of these companies means that most users/consumers expect all their software to be free (and the small minority that downloads paid apps wants upgrades to be free).
It is going to be an uphill battle for any "software" company to survive in the future. IMO that applies primarily to indie devs (I'm one myself) who sell apps in the app stores, but the problem also extends to large companies like Microsoft.
Of course that wouldn't work for all upgrades (like a whole-app rewrite or interface revamp, etc.), but for some cases I imagine that could work.
This would also solve the problem of no free trial (release the app for free and then add in-app purchase to unlock the full functionality).
These are of course only workarounds, and I would greatly appreciate if Apple would come up with a complete solution for these problems.
* What if the user buy's C but not A and B?
* Does B/C rely on anything in A or C rely on anything in B
* For every upgrade the dev needs to test all the possible combinations of upgrades bought by the user
* Positioning for new UI added by A/B/C dependant on what other upgrades have been purchased
You might be able to solve most of these with requiring A for B and B for C but even then you still need to test your app: Base+A, Base+A+B, Base+A+B+C......
In the MAS you have a set of bad choices:
A) Release the upgrade free to everybody. Great for them, bad for you.
B) Make the new encoder an IAP. Problem is, now you are maintaining "old" code that you may not want to maintain anymore. You may need to wrestle with the old encoder to get it compile for new versions of the compiler, etc. You have to fix bugs that occur with the old encoder and new, unanticipated changes in OSX. If you're still compiling and uploading it every month you can't plausibly claim that it's no longer supported.
C) ship the new encoder, but cripple it so it's slow until users upgrade. This seems capricious. Also, you can't get exactly the performance of the old encoder; you'll either overshoot or undershoot. And the nature of the MAS is that user's can't effectively downgrade, so they'll be SOL if you're wrong.
D) Remove the app from sale and submit a new app. You're wiping your slate with links, app reviews, etc. You also lose customers, who don't find out about your shiny new version. OmniGroup pursues this strategy, and they lose a lot of revenue from me (an avid user) because I completely miss certain upgrades because I don't hear about them. I can't imagine how it is for marginal users.
E) Don't update the app after all, because in spite of the fact that 2x video encoders obviously add value to the world, the MAS adds too much friction to make it a viable business. I would argue that the majority of iOS and Mac apps face this sad reality at some point in their lifecycle.
I submit to you, that if you manage to write a video encoder that is 2x faster, that should be the hard problem. The hard problem shouldn't be to figure out how to structure your upgrade pricing. But with the MAS, it is.
Um, how about this: Since your encoder is 100% faster you obviously did some substantial engineering on it. So why would this be just an update to the existing app? Even if you could charge for it?
The easy option you didn't mention is: F) Keep the old app in the store and start selling your "Encoder2" as well. "But I wrote 'customers don't find out about your shiny new version' you are now thinking" Well, you know there is the option of having users of the old app being notified about your new offerings, right? Don't tell me you have never seen such a popup in an app telling you about that companies new app.
So now you have two apps in the store and it is up to you to make sure how they differ and how the new one is an improvement over the old one. Now the customer has the choice which to get. For them nothing changes.
So a SaaS model is where software effectively has to land, modulo unicorns.
I see how that's probably right from the developer's perspective but as a consumer, it'd make me avoid your products. I don't want to keep paying you to use a product in general, and particularly not if - as you say - there's no new functionality or features. I don't want to rent my text editor, and asking me to adopt that model for your benefit isn't appealing.
I realize that keeping developers afloat benefits me in the long term, but that's not really my focus as a customer.
Commodity software income trends to zero, especially as competitors enter the market and trim away the features that are unwanted, leaving a minimal (fast to develop) product behind.
I don't actually believe that B2C software for "average consumers" where user pays for software is a viable market outside of certain markets (e.g., antivirus updates). The incentives are simply too aligned with gratis software doing something acceptably well for the vast majority of people, probably ad-supported. patio11 recently linked an article about selling to flies/mice/deer/elephants. It's really worth reading.
I firmly believe that the only games in town over the next 5-10 years for financial revenues from software are:
1. ad-supported mass market (E.g., gmail) 2. B2C niche (e.g., Bible study software) 3. B2C SaaS (backup software, dropbox, Google apps) 4. B2B SaaS (most of web stuff) 5. B2B desktop/server - usually 1-time fee + maintenance over a few years.
B2C Desktop buy-once and run is pretty extinct, afaict. For me, it's been replaced by libre software like LibreOffice, Emacs, and Firefox.
I'm imagining a cross-platform(Well, for desktops) store that would make it easy for developers to release applications, distribute updates, distribute trials and manage payments using a number of different models(single purchase, upgrade discounts, weekly/monthly/yearly subscriptions, all kinds of things).
It's upsetting that good software doesn't have a good way to be distributed and searched for in 2014. I feel like we, as developers, should be taking the initiative here, not sitting on our haunches hoping Apple and Microsoft give us something that works.
FD: I work at Paddle, and would be happy to answer any questions. It's exactly these types of headaches we're trying to solve for developers.
A few weeks before the pre-order ended the Macaw guys decided, that users having an account with Macaw would be a better way for users to license the application (to be fair to them, they've made the product registration/ activation process really nice).
Unfortunately, we weren't given much notice of the switch away from Paddle, and the process of giving access to pre-order customers wasn't handled in the best way. Which resulted in some pre-order customers not getting their copies of the application until a few days after the launch. -- We weren't actually powering the app, or their licensing at this point, but given more notice of the switch/ their launch, we could have assisted in getting the pre-order customers copies to them more seamlessly.
That said, and although Macaw aren't a customer of ours anymore (and haven't been since the pre-order), they seem to be killing it, have made a truly stellar product, and we wish them all the best! :)
I google apps first, before I go to Appstore. Why? Appstore is full of crap. I can't find what I need. If I type in "text editor" in the Appstore, I can't easily find the best text editor for OS X. However, if I google "best text editor for os X" I get meaningful results.
Steam has the advantage over the Appstore in that most apps in Steam are "worthy". They are large, complicated applications worthy of your time and money. The Appstore is suffering from the weight of a thousand little "Hello World" applications, with little or no value to anyone.
The Appstore has potential but the filtering and presenting is not where it needs to be. As a user, the Appstore model of "appear free but charge me in-app purchases later" sucks. It only serves to annoy me. It's not that I mind paying $50 for software. I just want free software to be free. If you want $50 from me, stay in the non-free section.
All in all, I've spent 5 times the $$$ on Steam and web downloads than on the Appstore, during my first 2 weeks as a Mac owner.
And Google first page hits gets the $$$
On the contrary, I (who happily use brew and brew cask) have re-purchased anything that is available in the app store, even if I'd already purchased it elsewhere, just for the app store conveniences.
It's really amazing to dump an old Mac for a new one and just click from your purchased inventory, no serials, no nonsense. Not to mention having that work on both your laptop and your desktop.
The old days of having to take a day off just to move to a new or additional machine are long gone, thanks to the app store.
1. Just one account for a wide range of software.
2. Automatic background updates for all purchases without having to deal with lots of sparkle updater dialogs.
3. Easy access to all your apps on any of your macs.
4. Easy reinstallation when you move to a new machine - no hunting around for license keys etc.
5. Confidence that the software is sandboxes and not malware.
Your claim that the MAS offers 'absolutely nothing' is false.
This developer is upset about the difficulty of securing a continuing revenue stream. This is exactly the problem addressed by streaming software to users instead of just giving it to them. What this developer really wants to do is _rent_ their program: when users stop paying, they stop having the software as well.
I make software because I enjoy it, and the type of software that I enjoy making either takes the form of one-off entertainment (games), or tools that expand your range of abilities (apps, mainly non-networked). If I couldn't hope to make money off these anymore, I'd probably lose my creative drive. (I am also a one-man developer. A corporation would obviously have different priorities.)
This is basically the Chromebook version of the future, and it's why I support Apple's native-first model over the alternatives. If I buy a hammer, I want to own it, not have it streamed to me over crappy H264.
However, many of the reasons I avoided Apple in the past are now irrelevant, as all but Linux now attempt the same fascist business model (The rings/rules of Apple QA for software, and One store with which to rule them all). My go-to argument against Apple in the past was:
"In order to get an application or piece of software into the Apple ecosystem, you have to go through Apple. Apple has a strict QA process, every app that gets into the store has to vetted by one of Apples legions of QA staff. This sounds good; we want quality apps. However, a great deal of Apple’s QA rules for acceptance aren’t just about app quality, but also nebulous ideas of morality and ethics. The problem with that is, when only one agency is in control of what is proper and what isn’t, we are left with a situation where one agency gets to control what you see, use, and by environmental influence—think. Now, imagine everyone exclusively owns an Apple product…”
Ironically, this notion is very 1984, and my stance on it was a bit extremish to be sure, but hey, I’m a PC. Anyway, ever since Windows 8 and Windows Phone, it seems Microsoft has seen how completely Apple controls its own ecosystem, and wants a piece (complete with its own app ecosystem). Suddenly Babylon had arrived on my desktop. My initial thought was, “are we going to reach a situation where there are no more open platforms to develop for? Are we going to get to a point where software can only be deployed through stores run by the same folks who run my OS? Do I have to learn Linux?!”
So, long ramble short, I’m thinking of joining the cult. A few years back I was given an iPad as a present. I initially resented it, labeling it a glorified TV-ala-Netflix device. I have since spent hundreds on app purchases. Is now a good time to put on my robes and worship at the altar of Jobs?
I decided to go ubuntu 14.whatever on a laptop that had XP on it (Acer One) and keep it as-is, as a new user.
I was pleasantly surprised. install was smooth, all hardware works, and I just installed firefox, and it all works (99% of flash works).
I use it for gmail, facebook, twitter, ello, surfing, etc. The machine is underpowered for full-motion video, but oh well, it was $349 6 years ago.
I use terminal to ssh into remote servers, and I've done no configuration at all on the machine. it works fine.
(Of course, I may be subject to downvotes for this, but it is just an observation and not meant as a "flame"; from a developer perspective, aren't we just subject to the same bunch of rules but from different overlords?)
And BTW, I was a happy Linux app developer until last week when I retired my crusty old VM, and have been using Linux since RedHat Apollo, so it's not a whimsical motion. I love Linux for my servers, just not desktop anymore.
For the major projects that 80% of Linux users actually use though, there are strict guidelines. A regular viewing of planet.gnome.org shows the sweeping interface changes taking shape. And that's not to mention the underlying Linux dependencies that GNOME seems to be embracing due to Lennart Poettering's time at the helm. Arguments against sweeping changes appear to be trampled on, from what I can see? Unless I am misunderstanding it a bit?
Of course, WindowMaker probably doesn't have the same problem!
I share a similar story and one key thing I wanted to comment on was that there were never really any "open platforms" to begin with, not even on Linux. The fundamentals of that codebase might be available free for use, but the companies checking in code and building out distros are not doing it solely for the love of the game, their doing it to cut a profit as well. They would nail you to their garden if they could, and some already have! The classic example of a company that did this and ran with it is Apple.
The fact of the matter is if you want people to use your technology at a mass scale you need to abide by the same fundamental business and market rules that the big boys do.
So friend, free your mind from the chains of platform loyalty and go ahead and experience all the technologies available on all platforms, because at the end of the day that is what people like you and I truly want to do.
The Mac App Store provides convenience and security. It's not required, though. You can install whatever you want on your Mac, or load whatever website or web app you want.
Conversely, PC users tend to treat all software as guilty until proven innocent, and as a result many of us have developed our own workflow to determine quality and safety.
I guess I've always associated using a PC with a more "trust-yourself" attitude, and Macs with "trust-the-system" attitude. Obviously a lot of this is irrational bias based on a life time of having lived on the other side.
Entirely psychological I know.
ios is still locked down, and it's great for 99.99999% of users. Think about it this way: if there's one platform you could recommend to a non-technical user, a user that wants to run apps, and still have a safe computing experience, what would it be? ios. There's nothing even close. My brother runs three restaurants and does all the bookkeeping. After having his computer hacked and almost losing $x00,000, he purchased a separate computer just for bookkeeping. That's a little ridiculous. My gf's parents had a similar situation while they where building a house and had a ton of cash in their bank accounts. They've been hacked before, but for them, ios is a safe platform to log in and do their banking. No other operating system today provides safety and ease of use.
EDIT: Also, from what I've seen, Apple is pretty committed to keeping Mac development open. Microsoft seems to be going in the opposite direction these days.
You want iCloud sync? Take out the ability for users to access their own home directories and files. Take out the ability to have plugins of any sort. Take out any functionality you wouldn't expect in an iPhone time-wasting app.
But yeah, I hope the App Store gets better. Pretty much any cool application idea I've had has required going outside the sandbox.
You don't have to use Metro, of course. However, if you do, there are constraints that are required for a secure, always-connected, battery-powered device that are not required for a traditional desktop or laptop.
> I don't see Microsoft permitting open development
I don't understand this. There are several ways to develop Metro apps, including C# or C++ with XAML, C++ with DirectX, and JavaScript with HTML/CSS. Seems to me that Apple is more restrictive on both the iOS and Mac OS X sides. Even if you really mean "open deployment", it's not completely closed....
Yeah, I meant "open deployment", sorry. I don't think there's an official way to develop for Metro outside the MS app store, right?
Haha such a genius thing to say.
I think most OS vendors are moving to this "app store" model as they see how they can easily distribute software and also railroad users and developers (for good or for bad). I'm not sure it's great (race to the bottom pricing + quality; see the Android Market for an example), but from a consumer perspective it is convenient.
But for the runaway success of the iPhone App Store model software-sold-like-shirts would probably be in even wider retreat than it already is. (The competitive models include "$X upfront plus 20% yearly for maintenance", "$X upfront plus an upgrade cycle which strongly encourages you buy a new version for 50% of X every 18 ~ 24 months", and, of course, SaaS. The popularization of the SaaS billing model is one of the biggest things that happened for software in decades, because it lets you sell $4,000 software to someone with $200 of willingness/capability to spend.)
When the path to profitability is to improve the software so users choose to upgrade, the interests of the users and the developers are aligned; better software is good for everyone.
With subscriptions, users keep paying whether the company improves the software or not - so the less the company spends on development, the more is left over to take as profit.
As a developer, I think the traditional sale option sounds much healthier for the industry, and hence much better for me.
Edit: I interpreted the comment I was responding to as lump sum vs ongoing subscription, rather than paid vs free upgrades. In that light, perhaps the parent poster and I actually agree!
1. I know a lot of Mac users that use the MAS as the only (!) source for their software (even Scrivener and other software has come to the MAS that before was only sold through the developer website). These are "normal" users that are not developers or hardcore nerds. And they never see any problems with sandboxing (they don't even know what this is). But - and that is the beauty of the MAS for normal users: Apple has their payment info on file, allows easy browsing the catalog, easy installation, easy payment and easy canceling of the order just in case. In addition: iTunes gift cards that are sold with a discount.
2. With the new VAT laws in the EU starting 2015, it will be a pain it the ass for small developers to sell software and services through their website on their own - at least for developers in the EU.
Of course, developers of business-related software for developers might see advantages selling on their own. But an exodus?
1. I totally agree with you on this point - the MAS is a fine store for something that costs $1-10 and maybe took only a few months to develop, maybe a hobby project. But building a serious business for apps that cost $30-50+ is much harder - it's possible but it won't be ideal (talk to the developers behind the apps in those categories). The point behind the article is that it doesn't have to be that way, the tools can be easily made available.
2. Only if you're the selling directly to customers (and even then it's not a massive deal as you can just signup for the VAT MOSS, which means you only deal with a single VAT entity, which you have to do if your sales exceed the VAT threshold). Furthermore, if you sell via a reseller, your sales lie outside the scope of VAT (as the sale is technically made by the reseller). For example, that's the case with FastSpring, as they're a US company and you will be receiving proceeds from them (assuming you're in the EU). FastSpring themselves handle all VAT related issues (they comply with all EU laws and will pay it out) - you don't have to lift a finger.
Years ago I experienced great traction with the free download site Apple provided.
Prior to that - much more significant traction from the hundreds of PC download sites.
It's amazing to see how much the world has changed in 13 years for software developers. It's probably better not to look back. :/
I've had a real tough time dealing with sandboxing especially. In my app HD Cleaner (https://itunes.apple.com/us/app/hd-cleaner/id836769549?mt=12), users need to "open" their user folder in order for the application to get the proper access to files. Unfortunately this is a large hurdle for some users because they have no idea WHY they have to choose their user folder. This has lead to confusion as well as some bad reviews. The app could be a lot more efficient and convenient if these rules weren't in place. Despite this I think it's great Apple is taking security seriously. I just wish there was a better way.
These remarks sound suspiciously like those software development clients who think their nephew could do the work for free in his spare time while cleaning the garage and playing Halo.
It's not about relabeling a button. Apple has enough talent to solve these, but these problems are not trivial.
I've been creating software for many years, I'm well aware that feature requests that look quite simple on the surface can require significant development efforts.
Having said that, implementing trials / upgrades is no a technical problem per se, it's more a question of spending the development resources required (yes, obviously there will be assumptions in the whole infrastructure that would require a bit of work but nothing that should have taken years to implement). In-App-Purchases were introduced a few years into App Store's existence, so it's certainly possible for them to implement major features when the willpower exists (and I'd wager implementing trials / upgrades would be easier than IAPs, although that's my guess, I have no internal information).
In any case, I very much doubt the reason for not having those features implemented is because they don't have the available development resources - it's more likely a decision was made that those feature do not align with Apple's vision of how the MAS should work.
Of course what worked for iPhone would not have worked for Mac and hence there was no incentive for Apple to make Mac Store popular. Apple cares little about developers, it cares about itself.
Don't buy games on the MAS when you could be buying them on Steam instead.
Buy other software directly from the developer's website so you can be confident you're getting the software they intended you to have, and won't get burned by the MAS no upgrades policy.
I really don't understand your logic of avoiding Apple's App Store but supporting Steams version. They both have problems, odd restrictions, and the like. I do not care for Steam installing all the games I get from them into a subfolder unlike how other Mac apps are bundled. It makes it very difficult to find all of the games content
For casual gamers, the Mac App Store is more than vibrant and has the same update management that Steam has, and its decoupled from a parent application.
Games rarely have upgrade pricing, almost never need extensive permissions, and while quick updates can be necessary, the necessity of upgrades aren't as crucial as a productivity/professional application where one's livelihood may be tied to the updates.
I wouldn't like the practices that run rampant in their iOS platform to take over Mac, which I still use on the side.
Apple wants to provide a good out-of-the-box experience. That means their devices come with what customers really need. Apple now views aftermarket apps the way Detroit views aftermarket car accessories.
Mac App Store developers, you are in the same business as the company that makes the little tree-shaped air fresheners for cars. Deal with it.
Working with an app store like a physical store is a business partnership. We can and should advocate for terms and capabilities with partners that will help our businesses and our customers. This idea that devs should take it or leave it and not say why publicly doesn't make sense to me.
Besides, this article is constructive - offering suggestions to improving the App Store. It's not simply a bitch fest.
In case of survival, change your business model as well as monetization approaches.
I suspect the down votes were because you added little to the discussion, educated no one (with that particular post) and people thought it deserved to be pushed down the page.
to quote the great Alfredo Kojima, Gustavo Niemeyer and Michael Vogt, "lol"
I'm on a mac but basically never use the app store anymore, because it's such a pain.
The problem with Steam is that it has been somewhat typecast as a store for games only, and that Valve doesn't seem to make a lot of effort to get other types of apps in there.
Mac App Store is really helpful especially when updating installed applications. Just a click away rather than launch every one to find out whether they need update or not.