Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.
The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using their Open… features would still work).
User interaction must happen at some point, otherwise the apps have no clue what files to open.
Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1]
Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear...
I listed the editors due of their project handling and "search in folder" features. I listed the browsers, of course, due to their abilities to browse local files, more specifically, be able to open other referenced local files (images, scripts, links); this is very important for web designers. Archives split into volumes (e.g a sequence of .rar, .r01, .r02 etc. files) are still common in some areas, tipically the user only had to open the first file in the sequence and then the archived opened the rest. Not to mention the obvious case of unextracting all files from an archive.
> The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players.
You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.
Xcode and Safari will get special exemptions, of course.
But putting aside short-run user backlash, do you really think Apple gives a damn whether Firefox, Chrome or VLC run on OS X? Judging by iOS, they might actually prefer it if they didn't.
After that you're left with archiving, text editors and Dropbox (which Apple might well want to replace with iCloud in the long run), which doesn't sound like that much to me.
