What’s happening to Growl now is exactly what I feared when I heard the term Mac App Store.
My fear is not so much that the S.S. App Store will be the only way that Mac software will be offered overnight, but that the App Store, by its existence, will force people into confining to new, artificially restrained definitions of what Mac software is. This new definition coerces everything into the shape and weight of Apps with Menus, Dock Icons and a Stage Presence. It is when software start confining to these rules that the conditions are created that lets the Mac App Store take over.
Under those definitions, Growl probably can’t be installed for all users; can it even run from startup and install command-line utilities? If these definitions are there for a purpose, in which way does dropping working features win anyone anything?
By making everything an app and shoehorning everything into App Store compatibility out of fear, no one wins and nothing improves.
App Store apps get installed in /Applications, so they are installed for all users. I don’t think we’ve discussed what the multiple-users-on-one-system story is going to be.
By Peter Hosey · 2011.07.06 18:28
To a degree. Background apps are still supported and the introduction of SMLoginItemSetEnabled alongside the store shows that Apple put some thought into supporting these and letting them start at login. LSUIElement apps like Fantastical are also still supported.
What we’ve lost is the ability to use a system preference pane for the UI. Having distributed an app this way I think the move to a config app + background helper is actually a good idea. To some users it’s not obvious how you uninstall a prefpane, and it’s possible to accidentally install multiple copies of the same prefpane which really screws things up.
It’s true that apps won’t be able to install command line executables outside of their bundle but I don’t see any reason you couldn’t offer these as a separate download for power users.
By Matt Stevens · 2011.07.06 22:32
Matt: That’s comforting.
By Jesper · 2011.07.06 22:53
with the sandboxing coming down the pipe, its going to be far better for Growl to be a single app rather than multiple binaries. being a single binary will also enable us to more easily adapt to the sandboxed security model and make use of xpc under 10.7 for the network parts of Growl. which will ultimately make it easier to have our entitlements approved.
By rudy · 2011.07.06 23:10
Growl only does one thing, so it’s not really like they can take anything out to get it on the App Store. And the thing it does isn’t going to be all that relevant if Apple adds a system-level notifications API.
By Tobias Cohen · 2011.07.07 02:31
Maybe this is not a popular opinion, but I am of the mind that this is precisely what needs to happen. That is, for third-party software to get structured either into a discrete, visible (both when running, and as an icon in the installed app list at all times), self-contained, sandboxable, mostly non-interfering, mostly-safe application, or into something else (either a hack, or a command-line tool, or infrastructure-altering stuff like most of the stuff Mike Ash listed as “iPhone Apps [He] Can’t Have” http://www.mikeash.com/pyblog/iphone-apps-i-cant-have.html#comments ). The murky continuum is over. That may seem artificially restrictive to us developers, but the truth is that this is the kind of restriction that has allowed users to experiment with software like never before on the iOS App Store (and I assume, the Mac App Store), and it’s hard to argue with that.
Now does that mean that the only software able to be provided by third parties should have the form of an app? Of course not, third parties should be able to provide solutions and enhancements for things (like for instance system infrastructure such as pasteboard, sound, text input…) that do not readily take the form of an app; but those should be provided as part of a category entirely segregated from apps. And the only way I can think of for users (who, if you remember, should not be assumed to read anything, to take warnings seriously, to instinctively understand potential software dangers, or to pause to wonder whether it is really worth it for them to watch the dancing bunnies*) to take the distinction seriously is to only allow apps, let users experiment with them, keep doing so for some time (say a few years) to set up strong expectations of what an app should and should not be, and then only allow other kind of software as an entirely different category (and then let users get burned on such software while they have the understanding that the things which burn are different from apps and that apps don’t burn them).
*many (and maybe most) users actually do these things, but the penalty for failing to do so even once should not be the risk of disruption, interference between two conflicting pieces of software, or outright malware as they risk today on desktop operating systems.
By Pierre Lebeaupin · 2011.07.07 12:01
Pierre: I am not opposed to software getting better or more organized or easier to install and uninstall, nor am I uninterested in educating people by providing plenty of good precedent. But none of those are dependent on the App Store approach and there is evidence that parts of the App Store restrictions are actively harmful to that end.
Let’s take Dropbox integration into the Finder. Right now, from all I can tell, it’s a hack. It’s the only way it’ll work! The methodology of hacks on their lonesome is that they should be avoided unless you really need them and know what they’re doing.
A platform where hacks are forbidden means less opportunity for strange crashes and misbehavior, but it also means less awesome altogether. How many people would at all be interested in Dropbox if they couldn’t get the functionality that’s there today? You could patch some things together with services, but you wouldn’t have the same experience at all, or you would have it in a separate window alongside the Finder.
I am all for providing stricter behaving, code signed, sandboxed applications to set an example and to show respect for your audience, but it should be a choice, you should be able to tear down those fences when it is necessary and you should explain that you’ve done that to those who are interested.
By Jesper · 2011.07.07 18:56
Pierre: And for what it’s worth, there are two more sides to this.
The fundamental side is that you should be allowed to use hacks when you choose to. No matter what, it should be possible as a case of fundamental freedom to do what you want on the computer of your choice. We know from history that good things will come of this, even if it also unlocks the door for you to possibly do stupid things. Anyone can buy a monkey wrench.
Another side is that many of the hacks are hacks because it is necessary for them to be hacks. If Apple would just offer the kind of hooks into the Finder that Microsoft offers into the Windows Explorer, Dropbox could provide a far better user experience. If Mail and Safari had better scripting integration, the Growl integrators for them could be written without resorting to those kinds of tricks.
By Jesper · 2011.07.07 19:02
“The fundamental side is that you should be allowed to use hacks when you choose to. No matter what, it should be possible as a case of fundamental freedom to do what you want on the computer of your choice.”
Who you gonna believe? Mark Pilgrim or Pierre’s Brave New World?
Computers are so passe. Appliances are fashionable.
Current fashion must be the only possible future.
I, for one, welcome our new Cupertino overlords, at least until I can learn enough Windows to feel comfortable making the switch.
And you developers have a good partner, just as long as your omnipotent partner doesn’t arbitrarily decide to stop doing business with you.
And as far as existing usable platforms go, hell the users just die off. Who cares?
By Chucky · 2011.07.07 23:22
That’s interesting, because I precisely think that those improvements are dependent on the App Store approach. Here’s why I think so: because without the App Store (Mac or iOS) there would be NO incentive for apps to be hack-free or even remain there.
Let us take a hypothetical universe without a Mac App Store and two hypothetical competing apps. One of them uses a hack; oh, a small one, it may even be kosher under our universe’s Mac App Store, but it is a hack, and it allows the first app a slight competitive advantage, either through better performance, better integration, or any other way that improves the user experience. The makers of the second app realize this and are wondering what to do, especially since they hear some customers (and former customers) mention this difference. They end up improving their product with a more or less similar hack, but not to be outdone, they push it deeper than the first app since they have hindsight of the drawbacks of the first app’s hack and they are not tied to it. Meanwhile, the makers of the first app are improving their product too, and among the various improvements of the next version is a second hack. And so forth. Fast forward a few years, and in the process of updating the operating system, the platform holder discovers that these two apps do quite a few hacky things. Through one-upmanship and competitive pressure, what used to be considered hacks became part of the state of the art. And that’s normal, after all some of today’s accepted software techniques were considered hacks back in their day; the only difference is that in the case of the hack we’re talking about today, the hacks interact with the operating system in some way. And on the opposing side there isn’t really any incentive to discourage hacks: for most software stakeholders (and not just crummy big company ones, but also the stakeholders of indie software, or the stakeholders (the developers themselves) of open source projects), the vague risk of the product no longer working on a future OS release (“It’s not working on Lion beta? Big deal, Lion is not set to ship for one year at least. Besides, it’s a beta, they’ll have it fixed by the Lion release in all likelihood.”) pales when contrasted with a tangible, immediate, marketable competitive advantage.
This kind of thing is happening, more or less known, every day, for many apps, all the time. It can take the form of the transparency hack of Audion faces, which eventually got appropriated by SoundJam ( http://www.panic.com/extras/audionstory/ ; scroll down to rivalry, no anchor unfortunately), to which Panic answered by improving their own feature; and as they mention this is but one thread in their “rivalry files”, and some other threads must have involved hacks, especially since you don’t do a music player on classic Mac OS without breaking a few eggs (such as, I don’t know, making extensive use of interrupt time). That hack was pretty harmless, as far as I can tell, but it was a hack. It can take the form of what’s obviously happening between Dropbox and its competitors. It can take many other forms.
The Mac App Store is providing a real incentive to forego any and all hacks, and in a way that neutralizes the competitive one-upmanship since everyone on the Mac App Store is subject to it. I consider this a grand experiment: what can be done without hacks? Turns out, quite a lot. Not everything, of course, and there indeed needs to be some space (for now, Mac software distributed outside the Mac App Store) where experimentation is possible so that solutions that start out as quite hackish can appear, before official support is added in Mac OS X (that is why I hope more kinds of software will be allowed on iOS eventually). But there is a place for this, and I do not think it is (for now) in the software marketplace for the rest of us.
I consider it fantastic that Growl will (probably) be able to be provided as a Mac App Store app and adopted by millions of Mac users. I am not familiar with the dropped features, but maybe they can be provided as hacks by the traditional channels, while everyone else can get to enjoy “vanilla” Growl.
(of course, I do have quarrels with other aspects of the Mac App Store; you won’t hear me defending, among other things, the fact it has exclusive access to easier-than-dmg install, or the review system, or the lack of support for upgrade pricing, or most damningly of all, the lack of real support for demos/try before you buy).
By Pierre Lebeaupin · 2011.07.08 00:02
Yes, burning down the house is an effective way to remove the cobwebs. It may also have some other consequences.
As much as I am reacting to this, I am for this general approach as long as it’s sufficiently dialed-down to strike with precision and as long as choice is maintained. I liked what they were doing with code signing before the App Store thing happened. It was clearly opt-in, it was clearly good and useful and on top of that offered a real, tangible benefit for almost all apps (automatic keychain ownership on upgrades).
Right now, choice is well maintained, but since the App Store is sending all the wrong signals, it causes people to abandon choice because “it’s gonna happen anyway, might as well prepare”. No one is implementing a sandbox because sandboxing makes your app better, they do it because that’s what the App Store will like.
I don’t have any problems with the world you argue could exist, I have a problem with the world that does exist.
By Jesper · 2011.07.08 00:30
Sandbox is not reliant on app store. We’d implement sandboxing even if we weren’t going app store Jesper.
By Chris Forsythe · 2011.07.08 03:49
Chris: Of course it’s not reliant on the App Store. You know exactly what I mean. Not everything in my comments apply to Growl (that was the other post).
Code signing was introduced before the App Store and people adopted it because it was right and true. There was one motive to get code signing right. Sandboxing is introduced after — actually, it was partially introduced before, but not to the extent that Lion has — the App Store and people are adopting it because O NO APP STORE HALP. There are now two motives to get sandboxing right.
By Jesper · 2011.07.08 09:22
“As much as I am reacting to this, I am for this general approach as long as it’s sufficiently dialed-down to strike with precision and as long as choice is maintained. I liked what they were doing with code signing before the App Store thing happened.”
But when we get down to the nub of the thing, that’s the problem, no?
Before the App Store thing happened, Apple was improving OS X. Yay! Improved OS X! Now, OS X is a mere pawn in a larger game, and the agenda has shifted.
The AppStoreMonster is hungry. Must eat. Still hungry. Must eat more. Still hungry. You get the idea.
It’s the exact bag of incentives that prevent precision strikes and dialing down for the improvement of the platform. It’s the exact bag of incentives that create their own logic for shock and awe.
By Chucky · 2011.07.08 13:51
So, if I understand correctly, your (Jesper) worry is that apps are constraining themselves in ways that may not make sense to them in order to fit on the Mac App Store, simply out of a vague, ominous “if you’re not on the Mac App Store, you’re dooooomed…” perceived message. (I read your original post as though you were talking about user perceptions, rather than about developers)
Well, that’s entirely possible, though I’m not sure it happens as much as you seem to think it does. Most software developers seem to be rather pragmatic and the type to wait and see, rather than overreact before it’s time. So the same way, I say wait and see wether apps actually change for the worst. So far, these changes in Growl seem to me to be a reasonable tradeoff (and not all related to the Mac App Store anyway); your mileage may vary, of course.
By Pierre Lebeaupin · 2011.07.08 23:59
Pierre: My original understanding of many of the Growl changes was that there were projects picked off not (only?) because they were tiresome to keep updated but because they would be inconvenient if Growl was to participate in a store environment.
So far, it seems to have come down to an issue of maintenance fatigue, and could simply, although not easily, be solved by someone else maintaining the same tools. It seems that they have chosen this route out of necessity and not because of inconvenience, which is better than what I feared, because it is at least rectifiable. (As is anything with a BSD license, of course.)
My fears are twofold: partly Chucky’s brand of App-Store-eating-everything fear, partly the self-fulfilling what-if self-censorship that will smooth the way for a steamroll transition to the App Store. Talking about the second case is dangerous unless you really see actual concerns, which is why I am loathe to do so. Growl is important because it is a popular mainstay that I two weeks ago would have regarded as one of the last things to hit the App Store ever because it’s so much about enriching your apps en masse in a way that does not provide another app.
I am starting to come around to the idea that the way Growl will now work (notifications in embedded apps anyway, control over them if you install Growl) may be a way of solving the difficult equation of describing Growl to people, because it hinges on saying “if you install this, then capabilities sprout up elsewhere”. Many people aren’t used to installing capabilities as such, and App Stores aren’t weaning them into that line of thinking.
Aside from all of that, I know slightly more than I’m telling you due to some information that I am withholding that could make my case clearer. We’ll see in a few weeks whether some other fears come to pass. (This is not a get-out-of-jail-free card; anyone who’s truly interested in this can get in touch with me by the middle of August, at which point I should probably be able to discuss this, if they don’t think they’ve seen anything more about this on waffle.)
By Jesper · 2011.07.10 23:47
OK, that’s fine; you almost certainly get more signals about this than I do. We’ll see what happens in the end. I should note, though, that due to network effects every successful tech introduction or transition is to an extent a self-fulfilling prophecy, since it succeeded in part thanks to people who believed in it; but the other parts means that even Apple needs the wind to blow to an extent in direction of such a move to make it happen, even them cannot drive such a change by their sheer will alone.
By Pierre Lebeaupin · 2011.07.11 11:05