3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).
There’s some nice commentary on this at sublimeguile. I’d certainly be inconvenienced by it. I quite like having LispMe and a HP-48 emulator on my palm pilot. If this is meant to be a ban on interpreted code… what a pain! But if it’s only meant to be a ban on downloadable interpreted code, it might be survivable. And there is the Safari JavaScript interpreter.
It’s more interesting to me that Apple is demonstrating a serious multi-pronged attempt to combat malware. Leopard added code-signing in a nicely subtle way. Every application bundle on a Mac is signed when it first runs. Changes after that point cause warnings to users, and clear any special privileges (like listening to the network). It’s clear that Apple can and will extend the set of privileges restricted with this mechanism using the sandbox MAC system also introduced in Leopard.
The iPhone is a step ahead. The restrictions placed on third-party applications will make self-replicating malware very, very difficult to install. The Mac’s biggest malware threat for the last eight years has been Microsoft Office macro viruses. The iPhone won’t have anything like that, because it won’t have extra network-capable interpreters. Moreover, this is done in a way that won’t inconvenience more than a fraction of a percent of the user base. Sun and Adobe will mind, since their Java and Flash interpreters won’t be permitted. Microsoft’s Office team may or may not mind… but their Windows Mobile team should be terribly jealous.