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?
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.
Not that loading code is allowed on the App Store anyways, unless you're Apple, of course.
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.
2.16 Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
So I guess that you can have a plugin system as long as you don't provide an in-app way to download and install them, like Adium does?
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?
Lately all this seems to have fallen pretty far down on their list of priorities though.
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.
http://blogs.computerworld.com/19195/apple_kills_the_mac_pro...
As with all Apple rumors, take it with a bucket of salt, they might announce a new line tomorrow for all you know.
[1] http://developer.apple.com/library/mac/#documentation/MacOSX...
http://news.ycombinator.com/item?id=3193354
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...
[1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...
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.
Opening a playlist or a file with linked subtitles needs to open an extra file after the first one.
Screen grabbing is nowhere to be found, not to mention CD/DVD access, or advanced networking, hardware decoding...
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.