
Between a rock and a hard place – our decision to abandon the Mac App Store - jespern
http://blogs.atlassian.com/2012/02/between-a-rock-and-a-hard-place-our-decision-to-abandon-the-mac-app-store/
======
zdw
Dev tools don't really have a place in managed environments IMO - they just
need too low level of access to a system to be able to do their work.

Now, say a game or web browser that runs potentially malicious content, sure,
sandbox it. But other things like code interpreters, low level Unix tools, or
inter process tools like AppleScript, they're still open to (mis)use by
anyone.

I'm going to guess that most malware for OS X will soon become non-compiled
scripts. Sure, the interpreter would be signed, but what it runs is totally
arbitrary.

~~~
gizzlon
Good point. Every interpreter - and program that loads anything - will have to
be foolproof. There was a case some time ago where an Xbox (or was it ps3?)
game did not correctly check the saved games before loading them. IIRC people
where able to exploit this and get the game to run code on their behalf.

In theory, all the games and apps have to sign/encrypt/check everything they
load. But I can't believe they will all implement this correctly or that Apple
will find all the subtle bugs when reviewing.

~~~
roc
The sandbox lessens the risk of said overflows. Instead of exploiting a flaw
in an interpreter or file handling function and getting control of the entire
machine, you'd only get control of the sandbox's context.

The only way to parlay that into control of the system would be to break the
sandbox. And then, because OS X default security is fairly sane, the only way
to do real lasting damage is to use a further exploit to escalate your
permissions.

~~~
gizzlon
True, but that would be true without signed apps as well.

Also, I guess it depends on what the app does and what you mean by "real
lasting damage".

------
tzs
Wouldn't security-scoped bookmarks solve some of the problems he describes?
From the sandbox design guide:

\--------------------------------

Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each
provide a facility for creating and using bookmark objects. A bookmark
provides a persistent reference to a file-system resource. When you resolve a
bookmark, you obtain a URL to the resource’s current location. A bookmark’s
association with a file-system resource (typically a file or folder) usually
continues to work if the user moves or renames the resource, or if the user
relaunches your app or restarts the system.

In an app that adopts App Sandbox, you must use a security-scoped bookmark to
gain persistent access to a file-system resource.

Security-scoped bookmarks, available starting in Mac OS X v10.7.3, support two
use cases:

• An app-scoped bookmark provides a specific sandboxed app with persistent
access to a user-specified file or folder.

For example, if your app employs a download or processing folder, present an
NSOpenPanel dialog to obtain the user’s intent to use a specific folder. Then,
by creating a security-scoped bookmark for that folder and storing it as part
of the app’s configuration (perhaps in a property list file or using the
NSUserDefaults class), your app acquires a means to obtain future access to
the folder.

• A document-scoped bookmark provides a specific document with persistent
access to a file.

For example, a code editor typically supports the notion of a project document
that refers to other files and needs persistent access to those files. Other
examples are an image browser or editor that maintains an image library, in
which the library file needs persistent access to the images it owns; or a
word processor that supports embedded images, multimedia, or font files in its
document format. In these cases, you configure the document format (of the
project file, library file, word processing document, and so on) to store
security-scoped bookmarks to the files a document refers to. (A document-
scoped bookmark can point only to a file, not a folder.)

A document-scoped bookmark can be resolved by any app that has access to the
bookmark data itself and to the document that owns the bookmark. The document
can be a flat file, or a document distributed as a bundle.

\--------------------------------

~~~
seanalltogether
Bookmarks are a working solution, the problem is getting the user to locate
those urls in the first place. I'm having many of the same problems that the
OP mentions and explaining to the user how to locate folders and files
correctly is a usability nightmare.

"Click the button below, locate file xyz and 'Open' it to proceed"

I would be perfectly ok with a system "Grant permission to xyz" dialog, but
the open file dialog is a terrible way of requiring access to a file or
folder.

~~~
msbarnett
> "Click the button below, locate file xyz and 'Open' it to proceed"

Rather than presenting it as some pointless mechanical chore in which you
direct a user to a specific file in a known place, wouldn't "Choose where you
would like Foo.app to save your XYZ (project/file/whatever)" make a lot more
sense?

~~~
seanalltogether
It's not about saving though, it's about reading files that already exist in
certain locations.

Imagine for instance an application that helps you clean up your downloads
folder, but wouldn't be appropriate to use on other folders on your system.
It's not the best example, but it illustrates how much of a usability mess it
is to ask the user to locate the folder for you through an open file dialog,
and then have to reject it if they select the wrong thing.

~~~
msbarnett
That's a fairly niche case, though. Personally I'm comfortable sacrificing it
in favor of not giving apps full read-write access to everything on my system
by default.

I can see how there are very specific cases in which it would be too
cumbersome, but it probably works in > 80% of cases, and it's pretty clear
that those 80% apps are who the App Store is aimed at.

Edit: Thinking about this some more: not to pick on your example, but the
Downloads folder actually does need to be located by the user, because it's
not actually in a fixed location (it _defaults_ to $HOME/Downloads, but that's
not where mine is located, for instance).

There really aren't many cases that I can dream up in which you can absolutely
be _certain_ of a file or folder's location, such that an Open Dialog is
totally superfluous.

~~~
seanalltogether
It's not really niche though, the entire Utilities and Dev Tools section of
the app store are full of these kinds of apps that provide users with
convenient management of data in predetermined locations, my own included
[http://itunes.apple.com/us/app/space-
gremlin/id414515628?mt=...](http://itunes.apple.com/us/app/space-
gremlin/id414515628?mt=12)

------
Ryanmf
Apple needs to do better than this.

For the duration of the company's existence, one of their biggest customer
segments has been the creative industry. I can't think of a single pro
audio/video/graphic/etc app that doesn't make extensive use of plug-ins,
another Mac App Store disqualifier.

Do the developers of these apps necessarily have a "right" to iCloud APIs,
delta updates, and other benefits of playing in Apple's sandbox? Of course
not.

But is Apple harming themselves and their customers by excluding the creators
of these apps from the party and potentially causing them to focus their
development efforts elsewhere? I think they may be.

~~~
smacktoward
> For the duration of the company's existence, one of their biggest customer
> segments has been the creative industry

I would have thought the Final Cut Pro X debacle
([http://pogue.blogs.nytimes.com/2011/06/23/professional-
video...](http://pogue.blogs.nytimes.com/2011/06/23/professional-video-
editors-weigh-in-on-final-cut-pro-x/)) would have served adequate notice to
those folks that Apple doesn't consider them an important market segment
anymore...

~~~
Ryanmf
Maybe. I hope not. All the filmmakers/editors I know still use a previous
version of Final Cut, many of them really like some of the features of Final
Cut X (syncing is apparently dead easy, nearly automagic), and remain hopeful
that Apple will pull it together and address their needs in future updates.

I don't know if you have used/use Final Cut 6/7, but it is a phenomenally
ugly, often poor performing, generally unintuitive piece of software. I can
see where the motivation for a full reboot would stem from.

Now, a reboot that involves consolidating formerly modular panes into a single
window when the target market typically works on two, three or more displays
is just dumb. A reboot that was, as a practical matter, 0% backwards-
compatible may have been necessary, but if it could have been avoided, it
should have been. But buried under all the mistakes, I think there was some
genuine good intent (yes, I know I'm grasping at straws).

I primarily work with music, and you don't need to be as involved as I am or
attend as many shows as I do to know that for any artist/band that uses a
laptop on stage, the MacBook Pro is the de facto standard. The same applies to
Mac Pros in studios (although those boxes may be going the way of the Dodo as
well).

None of this necessarily makes a difference to Apple; the new features in
Mountain Lion which focus on Chinese web portals and social networks serve as
a reminder that the emerging Chinese middle class is likely as important a
segment to Apple as any, and the number of potential customers in that group
already dwarfs the ranks of every DJ, producer, sound engineer, and electronic
musician on earth.

Still, it would be a great disappointment to me and many others if Apple were
to abandon such a loyal group of customers who helped them reach this point.

~~~
jesseendahl
FYI, the latest update to Final Cut Pro X was a major update, adding
impressive multicam support which uses "audio waveforms from the different
cameras to sync them together. The audio doesn't have to be the final
production track and can be used for syncing purposes only,"[1] chroma keying,
media relinking, import of photoshop layered graphics, support for XML 1.1,
and beta broadcast support. This new update has an average review score of 4.5
stars Mac App Store.[2] While Final Cut Pro X started out weak, it looks like
it's becoming very solid.

[1] [http://www.tuaw.com/2012/01/31/apple-updates-final-cut-
pro-x...](http://www.tuaw.com/2012/01/31/apple-updates-final-cut-pro-x-with-
multicam-more/) [2] [http://itunes.apple.com/us/app/final-cut-
pro/id424389933?mt=...](http://itunes.apple.com/us/app/final-cut-
pro/id424389933?mt=12)

------
LaGrange
I mostly agree, with one exception: "SSH keys and agent configuration are
automatically picked up, so access to remotes over SSH ‘just works’"

Um, no. If there's one thing that's more private than my address book, it's my
ssh keys. The fact that they aren't available to your application by default
is a feature. If you need a key, ask me for it. If I want to give you the
access, I'll do that.

~~~
zdw
Under OS X, the Mac Keychain framework hooks into ssh-agent, so you don't have
to retype your private key passphrase over and over, just once per session.

There are other tools that do similar in other OS's, for example the
"keychain" script in Debian. This isn't something weird IMO.

~~~
LaGrange
That would actually be (GUI, it doesn't work like this actually, I think, but
what I want would _look_ the same) ideal: you don't get my ssh key. You get an
ssh session arranged for by the keychain. Too bad it's probably too much work
for something not enough people use (and those who use it are generally
security-conscious enough to avoid malware on their own).

~~~
calloc
If you call `ssh` on the command line it will use Keychain to unlock your
private SSH key.

That part is done. The application shouldn't be asking for SSH keys, it is
completed already. Just use `ssh` as you would before.

~~~
jackalope
And if you type 'ssh-add' you'll only have to enter your passphrase once. I
think this all got sorted out beginning with Leopard; before that, it may not
have worked as expected (compared to other *NIX environments).

~~~
__david__
ssh-agent has shipped from the very beginning (that's part of the ssh
distribution). The only thing that was different was that it wasn't bridged to
the system keychain until recently. Or more accurately, the system keychain
now runs its own version of ssh-agent automatically.

------
hemancuso
The real question regarding the Mac App Store, IMHO, is whether or not it
forbids a broad enough class of still-popular applications that it fails to
achieve the goal of becoming the default distribution method for applications
on the Mac and instead is relegated to games and simple utilities that fit
nicely inside this model.

Very very popular apps like:

    
    
      Chrome   
      Photoshop/Adobe CS   
      Fusion/Parallels   
      Microsoft Office   
      Text Editors   
      FTP Clients   
      Dropbox
    

All need to be procured and installed outside the app store. While it's not
impossible to imagine some of these asking for the temporary exception and
getting in, they would all have to remove features or heavily modify
themselves to comply with the rules.

The Mac App Store loses a bit of its allure when you get your new MacBook Air
[even as a non developer] and can't find basics like Chrome or Dropbox or
Microsoft Office in there.

~~~
smacktoward
Pretend I'm Apple answering these questions for a moment...

> Chrome

"Safari."

> Photoshop/Adobe CS

"Creatives? Did you see what we did to Final Cut? Have you noticed how little
we talk about the Mac Pro anymore?"

> Fusion/Parallels

> Text Editors

> FTP Clients

"We're in the consumer products business, not the 'tools for nerds' business.
Ask an XServe customer if you want more information."

> Microsoft Office

"We could care less if we sell boring-ass business software into enterprises."

> Dropbox

"iCloud."

~~~
archgrove
Or, far more accurately, "You can get these all apps from the developers
directly. We don't support them on the Mac App Store at this time, and we
don't discuss future product directions".

~~~
drivebyacct2
Two and half, three years ago, people predicted this move for OS X after the
locked down nature of the iPhone really took hold. There are people that swore
up and down that signed applications would never come to OS X and that there
would never be a walled ecosystem on a non-iOS Mac product. Now we know this
to be blatantly false. Apple's biggest money comes from devices that have an
exclusively walled ecosystem. It seems pretty clear that they want users using
what they provide to them. I don't think it's incredibly inaccurate to say
that they don't care that they're not supporting major competing applications.

~~~
archgrove
Wait, what? Who claimed that signed applications won't come to OS X? Windows
has had them for _years_. People said that OS X would never be limited to App
Store purchases only and that's still the case. In fact, lots of people
expected the default to _be_ "App Store curated only, with an off switch.
Instead, we got the comparatively surprising "Signed only with no checks on
what's signed, with easy to use off switch" (i.e. app by app exemptions even
for full lockdown mode).

Apple's money comes from selling a cohesive experience. That, on iOS, that's
been helped by a "walled garden" approach does not indicate that the same
approach will make OS X better. _Some_ people have been crying wolf since iOS
1.0 about the demise of the open Mac platform. They were wrong about Snow
Leopard, they were wrong about Lion, and they're wrong about Mountain Lion.
It's beginning to sound like a certain boy and a certain wolf.

~~~
drivebyacct2
How can you say they're completely wrong? Every iteration brings in more iOS
features, often with no way to opt-out or the option is buried away or hidden
in a plist setting. Mission Control versus the old Expose? App persisting
(both in memory and) state. Not showing hidden files in Finder. More iCloud
integration at seemingly every turn in Mountain Lion.

It's clear that Apple is making OS X more and more and more like iOS. I think
you're right the loud-mouth "DOOM" scare posts are a bit silly and I hope I'm
not coming across that way. I just think that people are accepting this when
they wouldn't have imagined OS X looking like it will soon with Mountain Lion
a year or two.

Sigh, if you're going to downvote, please have the courtesy of telling me what
was so inflammatory about my post. Especially if you're going to drive by
downvote all of mine in a particular portion of the thread. I mean, good god,
this post is simply a listing of observations and then an agreement with the
parent that many people draw absurd conclusions.

~~~
batista
_Mission Control versus the old Expose?_

Yeah, isn't it much better?

 _App persisting (both in memory and) state._

Yay, a modern operating system practice finally in OS X. The OS should take
advantage of what it can do, to balance apps loading faster and using less
resources. For all I care, the ideal would be all apps to be always INSTANT
ON.

 _Not showing hidden files in Finder._

Hidden files shouldn't be an end user's concern.

 _More iCloud integration at seemingly every turn in Mountain Lion._

Yeah, finally. We don't live with ONE computer anymore, we have several, plus
several devices. We want them synced. We want them to backup online. We want a
modern Cloud service from Apple.

~~~
drivebyacct2
>We want a modern Cloud service from Apple.

I feel like you're completely and intentionally ignoring the point I'm trying
to make.

~~~
batista
Just wanting to say that what one sees as "problems", other people are
perfectly happy with, and even happier than with the old status quo.

~~~
drivebyacct2
I don't even see them as "problems"; at least not in some altruistic form for
the platform necessarily. I just think that a curated, managed platform is
something that Apple has been very, very, very successful with (and obviously
because people are down with it), and it seems obvious to me that OS X is
moving in that direction.

Like I said, I don't think it's fair to imply that they will shut out non-
AppStore apps or what not, but it's clear that OS X is becoming part of the
LARGER Apple ecosystem in a way that I really don't feel like it was in
Leopard or Snow Leopard.

I mean, they're _ALL_ doing it as the app/branding craze comes full circle.
Ubuntu is pushing the USC, Windows is pushing Live for login/user management,
Apple is integrating iCloud at a very core level in OS X. I guess part of my
surprise is from how quickly Apple has thrown iCloud together and integrated
it compared to how long Windows has been scrambling with Live and Windows.

------
abruzzi
I've been wondering/worried what Gatekeeper, sandboxing, and the rise of the
Mac App store in general are going to mean for third party plugin type apps,
say for instance Native Instruments virtual synth plugins, or photoshop
plugins. iOS can't really handle them, but will they be able to continue to
exist on future macs, or will they only work on the non-app store model?

~~~
Ryanmf
1\. By the letter of the law, Mac App Store apps are to be sandboxed, which
means no /Library access, which means no plug-ins. In practice, Logic,
Mainstage, Final Cut, and others are currently available in the Mac App Store.
To me, the only thing that would make these harsh restrictions worse would be
uneven enforcement of the rules. We'll see what happens.

2\. As of iOS 5, the platform has native Audio Unit support. I haven't seen
much use of it, more commonly devs have been porting their work to JUCE (as in
the case of the Auria iPad DAW, which features some popular third party plug-
ins as in-app purchases).

~~~
twoodfin
> By the letter of the law, Mac App Store apps are to be sandboxed, which
> means no /Library access, which means no plug-ins.

I don't understand: What prevents an app from having an "Add Plugin..." dialog
that uses the sandboxed file browser to locate a plugin library in whatever
sensible format?

~~~
calloc
I was under the impression that dynamically loading code was no longer
allowed. Not that apps have to be static, but unless it was part of the .app
and signed it won't run in the sandbox.

~~~
Ryanmf
Can anyone confirm/deny this?

------
jobu
How could Apple handle sandboxing in Xcode? It doesn't seem possible. Right
now they just distribute the installer via the app store, but I thought they
were planning to put the whole app in there.

I wonder if Apple might give some companies of just distributing the installer
via the app store as well.

~~~
bonzoesc
Apple fairly routinely lets themselves be exceptions to rules for their own
platform. Lion is distributed via the Mac App Store, and I'd put money on them
not allowing Ubuntu or Windows to be distributed via the Mac App Store in a
similar fashion[1].

1: future anti-trust cases or congressional testimonies nonwithstanding

~~~
cbr
Hypothetical rule: "Operating Systems may be distributed through the Mac App
Store only if they are capable of running the Mac App Store"

------
barryfandango
When I think of all the articles that have passed through the HN front page
about mobile developers' terrible experience with the app store, I can't
imagine why a desktop software developer would voluntarily subject themselves
to it.

Sure, iDevice developers have no choice. But for desktop software there's this
handy thing called the Internet. Why kick up revenue to apple, subject myself
to submission rules and arbitrary rejection, absurd technical limitations and
switcheroos like the one described in this article, and all the rest?

~~~
Steko
"When I think of all the articles that have passed through the HN front page
about mobile developers' terrible experience with the app store"

Right, there are no success stories.

"Why kick up revenue to apple"

People keep saying this like Apple doesn't deliver buying customers and
revenue. The app store making a profit on sales is exactly how every other
store in the world works. Why does Apple 'kick up revenue' to Amazon when they
could just sell all their iPads online through Apple.com? The answer is
because lots of people shop at Amazon and Apple will sell way more iPads with
Amazon then without them.

~~~
barryfandango
If the app store can truly compete with an open marketplace, why won't apple
let me install arbitrary software on my iDevice?

~~~
Steko
It's common courtesy to announce when one's surrendering an argument and
starting a new one.

"If the app store can truly compete with an open marketplace"

As it turns out there is an open market for iOS apps and an open alternative
to iOS and Apple's walled garden is competitive with both.

"why won't apple let me install arbitrary software on my iDevice?"

Aren't the reasons obvious? Simplicity, profit, security?

You might as well be asking why your Macy's card doesn't work at Sears or why
you can't make a copy of your building key at Sears or why.. hey just what
does Sears have against freedom anyway?

~~~
barryfandango
Since you've asked, Steko, I'll continue as if you're actually interested in
exploring this topic with me. I promise I was trying to contribute to my
argument and not change the subject. Please calm your fury.

First, what is this open market for iOS apps you mentioned? I haven't heard of
it.

Of course Apple locks down the app store on their iDevices for profit. I think
we're in agreement on that. If they didn't limit software delivery in that
way, their app store would have to compete with other software delivery
channels including the open web.

What I'm trying to express is my surprise that developers in the desktop world
would opt in to a market like this. I had assumed that iDevice developers only
used the app store because they had no choice.

~~~
Steko
"Of course Apple locks down the app store on their iDevices for profit."

I doubt that Apple is solely concerned with profit and even if they were I
guess I don't see that as the end of the world.

If Apple is solely concerned with profiting from apps why do they subsidize
free ones and credit card fees? {If dev share is actually calculated post cc
fees I'll plead ignorance and move on to the other part of the argument.}

99 cent app less 69 cents to developer less 40-70 cents to credit card company
less bandwidth fees = loss.

(I've given a range on cc fees because they are shared if you purchase
multiple apps within a few days, that mitigates the loss but ultimately
someone motivated only by profit would be taking easily avoided losses all
over the place in either scenario.)

Isn't it well known that Apple's direct profit on the App Store is a rounding
error compared to their other business?

Isn't it then more likely then that their motivation is not primarily to
directly profit from it?

While I do think Apple is interested in profit here, I very deliberately
listed it as secondary to simplicity which is really at the heart of
everything Apple does well. There's a book coming out soon about just this:

[http://kensegall.com/blog/2012/02/and-now-a-different-
kind-o...](http://kensegall.com/blog/2012/02/and-now-a-different-kind-of-
apple-book/)

The premise I'm building on is that Apple _really profits_ by making great
products that just work and make people happy. Having a super simple way to
get apps is part of that.

For 98%+ of users 1 app store >> 2 app stores >> 10 app stores. One App Store
just works. It also stops most malware without any action by the user. That's
simplicity again.

"What I'm trying to express is my surprise that developers in the desktop
world would opt in to a market like this"

I guess again I'll fall back on my Sears comparison. I don't know if Sears
still sells software but they did for decades -- Wal-Mart still does for sure
though and there's no way Wal-Mart is any more dev friendly then Apple. Way
harder to get your product on the shelves at, harder to keep your product
there, takes at least as large a cut, etc.

What Wal-Mart does have is tens of millions of customers though. Apple too. So
of course devs are going to opt into those markets.

~~~
barryfandango
Very true. I didn't try to imply in any previous post that being motivated by
profit is a bad thing. The app store definitely provides the ultra-simple
software ecosystem you mentioned, and I agree that's awesome for most users.
It also happens to guarantee that apple will be in the pipeline for all sales,
so it's really win-win.

Despite my surprise that anybody would use it, there are over a thousand apps
on the mac app store, so apple must be adding value by getting the product in
front of eyeballs and streamlining the payment process. Still, I don't think
they'll be able to get away with the draconian rule that they enjoy in the
iDevice world. After all, if they make the experience too unpleasant,
developers can still sell software through a competing app store, their
website, or by mailing you a CD-ROM if all else fails. I think this is a good
thing - the "escape hatch" means they'll actually have to put effort into
pleasing the vendors who use their channel.

You'll never see a "why we decided to abandon the iPhone app store" - the only
choice in that world is to abandon the platform altogether.

------
LinaLauneBaer
I like the idea of a sandbox. Apple promotes the sandbox as a security feature
but shouldn't Apple try to improve much more important things (security wise)
first which are much less invasive?

Example: The Keychain application from Apple (used to store certificates,
private keys and passwords) is using a encryption algorithm that is too weak
for what it is used - namely: DES. You can break it with a reasonable amount
of money.

Wouldn't it make more sense to improve these kind of things first? We would
gain so much more security with a minimal effort.

~~~
Someone
I could not believe they would use single DES (I would have expected AES), so
I googled around. Apparently
([http://stackoverflow.com/questions/6312871/what-
encryption-a...](http://stackoverflow.com/questions/6312871/what-encryption-
algorithm-does-the-ios-keychain-use-to-protect-data>); it is (or at some time
was) 3DES; the PDF linked from there states:

    
    
       "All the password data in the keychain is protected using the
        Triple Digital Encryption Standard (3DES)."
    

<http://en.wikipedia.org/wiki/Triple_DES#Security> states:

    
    
       "NIST considers keying option 1 to be appropriate through 2030."
    

I am still surprised that it is not AES, but 3DES seems good enough. Also, I
am not sure that PDF still describes the current situation.

------
ori_b
The problem is that allowing the holes he wants in sandboxing would defeat the
security benefits. And that security is the whole point of the ordeal.

I don't know what the best solution is. Possibly allowing non-sandboxed apps
in the app store, which go under extra review (possibly with a premium charge
to defray the cost of extra review), or requiring the user to select a 'do not
sandbox this' option when installing the app.

However, Apple can't give this app what it wants while keeping the integrity
of their sandbox.

------
pooriaazimi
It is clear that Apple's current sandboxing is not perfect, but what could be
done?

The goal is to create the most secure running environment that is possible.
Allowing random apps to access/modify different files on the system (without
user explicitly allowing that) kinda defeats the purpose of sandboxing (from
user's point of view - from developers POV, sandboxing makes his app more
secure and stable).

All I see is people ranting about sandboxing's limitations, without coming up
with actual plans to improve it.

~~~
wtn
They're trying to take take take everything away from the user. Soon there
will be no filesystem.

~~~
sunchild
Yes, and never mind that just about everything you take for granted about
personal computers was "given" by Apple, too. I find this notion that users
are entitled to complete device freedom really annoying.

If you find it so objectionable, go build your own hardware and OS platform.
This isn't a matter of human rights because no one is telling you that you
can't make your own.

~~~
sunchild
@cooldeal: Nope, I'm dead serious. There's no fundamental human right that
entitles you to tell Apple (or any other device maker) what it can and can't
sell you.

~~~
icebraining
Of course there is, it's called Free Speech. There's no right that entitles
you to _force_ Apple to do what you want, but then again, nobody's arguing for
it.

------
adsr
I hope Apple relaxes it's policy in regards to the sandbox. I do think it's
great to have a sandbox provided by the OS, but IMO the default rule should
be: "no access", then the developer could tick all legitimate uses for the
application, if this happens to be unrestricted access, so be it. I think this
is especially true with the new upcoming code signing feature in Mountain
Lion.

------
josephcooney
I always got the feeling that once OSX became popular enough it would become
an attractive attack target. Apple would have to start caring more about
security. And the 'it just works' aspect of a lot of things they do would be
reduced or eliminated.

------
icebraining
I got a wrong certificate warning and a 403. Does anyone have a mirror?

~~~
mike-cardwell
Disable the HTTPS-Everywhere ruleset.

~~~
icebraining
Oh, I don't even remember that I have that installed. Yeah, that was it.

------
tomelders
I'm grateful for the iTunes App Store, but I have a bad feeling about the Mac
App Store.

I think now might be the time for a rival App Store to set up shop before
Apple locks developers into only releasing through their approval process.

Maybe I'm over reacting, but an ounce of prevention is worth a pound of cure.

------
aneth
This is the first iteration of something I'm sure Apple will refine over the
coming years. It's not surprising they haven't addressed the concerns of some
applications, particularly power user and developer applications. Instituting
a sandbox with user controlled permissions seems a solid step for usability
and safety. For sure every feature will probably not ever be possible in a
sandbox - for that we have regular installations which are not going away any
time soon if ever. Apple is smartly trying to establish a trusted installation
pattern for desktop applications resembling the experience on iOS, recent
snafus notwithstanding.

So basically, it's notable that some applications are having difficulty with
the first iteration of these new restrictions, but it's not surprising and I'm
confident the issues will be resolved in time. Meanwhile, we've all survived
without the App Store for a long time. I think these applications can survive.
This is not the time for outrage.

------
funkah
Good points. I am concerned about this coming sandboxing. I don't use the Mac
app store, but the sandboxing seems to be too restrictive, and I'd hate to see
apps giving up functionality just to stay in the store. I think long-term
Apple will get this sorted out, but it would be a shame for app functionality
to regress in the meantime.

------
jcnnghm
If Apple is not going to be distributing software updates because of their
asinine policies, Apple should refund their 30% cut to their customers.

------
bconway
One thing to be wary of: abandoning the Mac App Store is going to make life
much harder for you and your users in the near future. As of OS X 10.8, by
default applications cannot be installed outside of the App Store (though a
setting exists to change this):

<http://techcrunch.com/2012/02/16/os-x-mountain-lion/> (scroll down to
Gatekeeper)

Here's hoping that 10.9 doesn't disallow such installations at all (or void
your warranty instead?).

~~~
shinratdr
Actually that's incorrect. You can't install completely unsigned applications
from the web in 10.8 without changing a setting, but the default isn't the
"Only MAS" option, it's the "MAS + identified developers" option.

So while you can abandon the App Store without penalty, you shouldn't stop
paying Apple the $99 a year you need to do so to get the app signed, even if
you aren't going to sandbox it or distribute it through the MAS. They just
want the option of pulling a cert for a dev found to be distributing malware,
not to personally review and reject every application that runs in OS X.

