I can think of only two GUI apps I semi-regularly use that can't fit within those restrictions: VMware Fusion, and Steam.
Plugins are a red herring. Some poorly-designed plugin infrastructures will not be workable, boo-hoo. Valid use cases can be accommodated with proper message passing. Maybe we'll finally get applications that don't crash horribly because of buggy plug-ins?
What kind of plugin architecture do you propose that doesn't use dynamic loading or standard IPC mechanisms? Your "message passing" is much too vague.
Remember, this needs to be fast enough to accomodate FCP video processing plugins - hundreds of megabytes of data may need to be passed between the host and plugin each second.
AudioUnit plugins have strict realtime requirements that won't work with message passing too. If Apple disallows plugins that will be the end of the Mac as a pro audio platform. Not that a lot of plugin developers would mind so much after the insane platform churn at Cupertino in this last decade, but it's hard for me to imagine Apple would go that far.
Exactly... AudioUnits and VST plugins literally must be loaded in-process of the host to be useful at all. As long as vendors aren't forced to use the App store for distribution I don't think anyone in that scene will care much about Apple's changes. In the digital music / VST / DAW scene I think the app store's initial launch amounted to a single "oh well, guess not" blog post on CDM and then everyone moved on. (I'm exaggerating a bit of course).
Apple can't get out of Pro market fast enough. They already killed XServe, they "deprecated" Java, which means no chance in hell anyone will try to host their app server on Mac, and now even develop on Mac, they haven't updated their Pro audio software in almost 5 years, the fiasco with FCP X (complete rejection from actual pro users), and most recent rumor they will kill off Mac Pro as well.
Apple wants to be handheld "post-PC" maker and not a computer company. They don't want anything to do with the pro market, people who actually need to do work with their computers.
They killed XServe because it belonged in a market where Apple was insignificant, they weren't selling any. Java now has to be installed separately like on all other platforms. Logic was last updated in August.
"strict realtime requirements" and Mac OS X (and most other off-the-shelf operating systems) do not mix and never have. Either these applications don't belong on the platform in the first place, or you are misunderstanding their requirements.
It doesn't matter anyway. What is it Apple has done recently to give you the impression that they place great importance on niche markets?
Realtime in this sense means an interrupt-driven thread that must respond in fixed time to prevent audio dropouts which are death in pro audio. Previously Apple has assiduously courted this market with their implementations of CoreAudio and AudioUnits and the purchase of Logic. OS X provides by far the best native support for pro audio apps of any operating system.
Lately all this seems to have fallen pretty far down on their list of priorities though.
Plugins can exist anywhere. They can be placed into the app's bundle without necessarily breaking its signing seal, they can exist within the app's container if the app has a way of copying them in (e.g. it advertises a file type, like Aperture's ".ApertureExport" bundle, so the user can double click to load the plugin, or it provides an "Install Plugin" feature somewhere), and they can exist anywhere in the user's home dir or system volume (if the app requests an exception to read files from those known locations).
No code loading restrictions are placed on signed and sandboxed apps. Any signed and sandboxed process is free to map in any code, though that code is bound by the parent process's sandbox restrictions.
Signed and sandboxed applications have no code loading restrictions. They're free to map anything into their memory space, though that code will of course be bound by the same entitlement restrictions as the loading process.
XPC services must be located within the host app's bundle [1]. They must be appropriately code-signed. How do you propose to use this mechanism for 3rd party plugins?
As I've pointed out elsewhere in these comments, XPC isn't required for supporting plugins in a sandboxed application, and it's possible for plugins to exist within a signed and sandboxed app's bundle:
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.
Plugins are a red herring. Some poorly-designed plugin infrastructures will not be workable, boo-hoo. Valid use cases can be accommodated with proper message passing. Maybe we'll finally get applications that don't crash horribly because of buggy plug-ins?