It goes even further than that in OS X. Applications are not the only thing grouped, shared libraries are grouped as ".frameworks". These include all the headers and binaries in one directory structure, and they're even versioned! It's possible to keep the "last stable" release of your lib while also including the "new development", all in one package.
It really frustrates me that other OSs don't adopt this approach. It's good for both developers and users alike.
The versioned share library is interesting. But another concern to "non-installation" method is that some "lazy" programmers failed to keep the library they use update. When there are security issues around the library, usually, the developer of the library will quickly come up with a hot-fix. But Other applications which use the library under their own local folder still expose the potential security backdoor to third party.
The .framework actually can handle this. The xml registry can list versions and version aliases.
Maybe you're implying that .app files tend to keep local .framework files inside their bundle. I'm not sure how common this practice is, but one thing that's true about OS X apps is that they're almost uniformly equipped with something like Sparkle (http://sparkle.andymatuschak.org/). Most of my apps self update without me even trying.
Maybe you're implying that .app files tend to keep local .framework files inside their bundle. I'm not sure how common this practice is...
If your app requires a library that is not included in OS X, you have to ship a copy of that library inside your app bundle. (Or you can use an installer .pkg, but that defeats the point of no-install.) Self-update helps, but the app developer has to actually build the update.
There's a tradeoff here between the simplicity and reliability of OS X app bundles and the other benefits of Linux package managers where an app can just express a dependency on a library and that library will be kept up to date globally.
Unfortunately, OS X can make it a bit too easy. Until I gave her instruction otherwise, my wife downloaded apps like MSN Messenger, opened the DMG and then ran the app direct from there! So she had all these installation DMGs open so she could run her apps.
My father (who tried OS X after being a Linux user for some time) did the same. It's really not obvious what you're meant to do unless the DMG has the instructions in clear sight (which some developers do). I had a similar confusion when I first switched to the Mac five years ago.
What they were doing may seem weird, but it's not really technically wrong to do. The only real downside is the resources wasted on keeping the disk mounted.
That's funny. The words "web" and "cloud" do not yet appear anywhere in these comments!
Even novice users have proven that they can remember to visit URLs for their applications and bookmark their favorites. With that in mind, we can easily overcome the "desktop loaded with .application files" problem.
Or almost works, I'd say; dragging an application to the Trash does not completely remove the application: the preferences and support files that the application has thrown into (user) global directories are still there, and in fact (besides third party apps which do this task) there is no clear interface to remove them or to know where the application put files in the first place; you have to comb manually through your ~/Library.
Fortunately those files don't take up a ton of space. I've got an Application Support directory that I've migrated with me for about 4 years now, and it's just now at 1 GB.
It is common practice in OS X to unpack a zip or DMG file and then simply double click to run the application.