I've used (and continue to use) them exclusively for one-off interactive installations and research prototypes (I don't work in the 'commercial' sector), but I

I've used (and continue to use) them exclusively for one-off interactive installations and research prototypes (I don't work in the 'commercial' sector), but I believe a number of people have apps made with Max in the App Store. Max is not purpose built for creating applications, but you can bundle a "standalone" which comes with your 'patch' and a copy of the 'interpreter'. http://cycling74.com/2012/04/19/get-your-max-standalone-on-apple%E2%80%99s-mac-app-store/ http://cycling74.com/2012/04/19/get-your-max-standalone-on-a... Indeed they are typically aimed at specific domains, but I think this is entirely natural for something that's a layer of abstraction above a high-level programming language. One issue with the systems I'm talking about specifically is that they do run in an environment that is a quite heavy app in itself, so building an application or using the environment as part of another application does not work well – you end up with a lot of extra bulk. In order for this model to take off for consumer apps, you would need OS-level support for apps to make use of a single interpreter instance running in the background, or for the interpreters to be heavily optimized. But that's not the point – the point is that there are other programming paradigms than interpreted vs. compiled, static vs. dynamic, imperative vs. functional text-based programming languages. The systems I mentioned are for realtime multi-media installations, performances, music-making, etc., but similar paradigms could be useful in other domains.