I can only assume that this was used to find other applications. Still a fragile dependency; for example, sometimes I put things in "/Applications/Utilities" but sometimes I put them in "/Applications", which means there is no single parent directory that is guaranteed to hold everything. And even if that weren’t the case, the OS has always let you run applications from anywhere you want.
Therefore, it has always been possible for apps to break when doing this, and they were just lucky if they ran on a system where it worked. It sounds like in Sierra it will just be much more likely to break.
Regex system versions, string compare versions in Ruby (great for "10.9" -> "10.10"), check that their installer package (an OS X binary) is running on... OS X. Sometime developers do this out of ignorance, sometimes its done out of laziness (don't want to do anything platform specific), or business decisions (don't want to do anything platform specific!) or because there was no better way to do it (no supported API).
How about applications that have an installer, lay themselves down in /Applications/ then have a folder inside called "Plugins", from which they load relative arbitrary code? More common than you might think!
This is extremely hyperbolic. I'd say it could break functionality in a small number of apps (that don't support running from read-only media, which is definitely a problem with the app and not a problem with the system). I doubt it's a lot, and it's sure as hell not "most".
I remember a time when "just move the app into the Applications folder" seemed really simple. Like Apple, I thought it was a fine idea.
We were wrong. Having to move the application in Applications turns out to be absolutely baffling to most users. (Including many people I am fond of, e.g. my dad.)
A lot of apps now offer to move themselves when first launched from the Dowloads or Desktop folder; the OS should handle this.
GPR itself still seems janky, but this would help (since apps in Applications don't get GPR'd).
Apple wants developers to use dmgs (and signed ones particularly) but updaters don't have an easy time with apps being launched from those either, and people don't think dmgs provide a good user experience as well.
Some developers that distribute their app in dmg's try to nudge the user to move the application for them into /Applications, but that's kind of hostile, and developers shouldn't have to go out of their way to do that.
Before 10.12 at least, developers were generally okay with the updater not running on read-only media - this is more intended behavior rather than being 'broken'.
Anyway, just pointing out the real concern from the article.
The author's concern is that they (and many other developers) ship apps in zips, have many users download them, and run them from ~/Downloads/ or wherever their browser downloaded the app to. Only in 10.12, this practice will prevent most 3rd party apps from being able to update themselves.
The author wants an info.plist key (plus perhaps app signing) to opt-out of translocation and say that they are competent enough. Before thinking that this "defeats" the point, people may miss that Apple is fine with opting out provided you code sign and package a dmg.
The author and many others also don't like dmgs, however, and find that they confuse many users. What the author is concerned about does indeed affect a lot of apps.
(I really don't know if that many apps do this btw, I think most apps I download today are packaged in zip..)
Other users are just baffled and run apps from disk images or Downloads just because.
The authors point is that at least before 10.12 zip was a decent approach.
Too bad they aren't offering signed zip or something similar that takes same advantages that a signed dmg does..
The Info.plist approach (where the app declares that it has no such relative path dependencies and so should skip gatekeeper path randomization) seems like the best approach for fixing this "issue".
> However, many users run applications from the Downloads folder, never moving them.
Basically, unsigned apps might not work when run from the Downloads folder without changing the Gatekeeper setting in Security & Privacy settings.
I don't view this as an issue because I already have to go there to launch an unsigned app for the first time to hit "Allow."
Almost every App has a custom background image on the disk image and shortcut instructing people to copy the application to Applications. I've also seen various apps check and pop up a dialog asking if they should move themselves to Applications for you.
Much like the first-run warning dialog, I'm surprised Apple doesn't have a similar dialog offering to "Leave App and Launch", "Move App to Applications and Launch", or "Move App, Create a Shortcut Here, and Launch". With a preference or flag to suppress the dialog.
I think the whole .app folder idea was a great idea that I'm surprised others (Windows/Linux) haven't copied. The /intention/ is that anything that would need to get installed/fixed happen when the app is first launched. This both removes the need for an installer and helps repair things (if the App was moved or preferences were deleted). Thankfully installers are pretty rare in my experience. Usually it's for pretty involved things (network monitor, VM environment) or lazy multi-platform devs (Microsoft Word, or Adobe).
I think the App Store is the most straightforward for the average user--I just wish they'd improve it so it was used more.
Detect and offer, dialogue exhaustion and you end up just automatically doing it anyway.