[abruzzi]

I've been wondering/worried what Gatekeeper, sandboxing, and the rise of the Mac App store in general are going to mean for third party plugin type apps, say for instance Native Instruments virtual synth plugins, or photoshop plugins. iOS can't really handle them, but will they be able to continue to exist on future macs, or will they only work on the non-app store model?

[Ryanmf]

1. By the letter of the law, Mac App Store apps are to be sandboxed, which means no /Library access, which means no plug-ins. In practice, Logic, Mainstage, Final Cut, and others are currently available in the Mac App Store. To me, the only thing that would make these harsh restrictions worse would be uneven enforcement of the rules. We'll see what happens.

2. As of iOS 5, the platform has native Audio Unit support. I haven't seen much use of it, more commonly devs have been porting their work to JUCE (as in the case of the Auria iPad DAW, which features some popular third party plug-ins as in-app purchases).

[twoodfin]

> By the letter of the law, Mac App Store apps are to be sandboxed, which means no /Library access, which means no plug-ins.

I don't understand: What prevents an app from having an "Add Plugin..." dialog that uses the sandboxed file browser to locate a plugin library in whatever sensible format?

[Ryanmf]

No technical limitation that I can think of prevents the scenario you've described.

As a practical matter, it would require anything up to and including a full rewrite of every pro media creation app on the market. The standard to date has been that there is a specified folder for plug-ins, and the host scans the folder for installed plug-ins on startup.

One benefit of this arrangement is that the user must install the plug-in only once to have access to it in any application that supports its plug-in format. Let's use pro audio apps as an example. I use Ableton Live and Native Instruments Maschine as my primary compositional tools, but I prefer to mix/master in Reaper. Given your alternative method, when I purchased Madrona Labs' Aalto, one of my favorite virtual instruments released in recent memory, I would have needed to endure three separate installation processes to have access to the plug-in in each app where I might want to use it.

Additionally, Maschine happens to have the ability to run both as a standalone application and as a VST plug-in. Let's say I sketched out a beat in Maschine standalone, using Aalto to produce some cool Buchla bongo sounds. Later, in Live, I insert an instance of the Maschine VST and open my project file for further processing. Do I now have nested sandboxes? Will it work at all?

Things get even more complicated when one considers the plug-in developers who require iLoks (license verification USB dongles). These seem even less likely to be compatible with Apple's new processes. Don't get me wrong, I hate and refuse to use iLoks, and by extension any software which requires them. But many Pro Tools/Waves/Soundtoys/etc users are just used to the inconvenience of a hardware dongle at this point, and the companies I mentioned have many satisfied customers.

It seems to me more likely that rather than rewriting their apps or fundamentally adjusting their license verification practices, many of these developers will simply avoid the App Store altogether. As a consequence, users suffer.

[feralchimp]

Nothing, and IIRC this is what I've seen recommended on Dev Forum. Browse to plugin, copy plugin to app sandbox (or with 10.7.3 maybe get new security managed context handle to FS object), load. I don't have an app that does this so I can't comment on any possible issues around code signatures.

Sorry I can't point to individual forum threads at the moment.

[calloc]

I was under the impression that dynamically loading code was no longer allowed. Not that apps have to be static, but unless it was part of the .app and signed it won't run in the sandbox.

[Ryanmf]

Can anyone confirm/deny this?