Nerves
Judging from Unity’s two corporate blog entries on the whole 3.3.1 thing, I get the feeling that they’re feeling less confident as of Wednesday than they were on Friday (it’s dated Sunday but it was posted on Friday).
The fact that PhoneGap has been given Apple’s stamp of approval is certainly a sign that platform abstraction layers can be OK, but bear in mind that PhoneGap is completely open source and lives on JavaScript…
JavaScript
You may recall that JavaScript is not mentioned in the scariest subclause of 3.3.1 — JavaScript apps run on top of Webkit, and thus don’t need to worry about how they access APIs, don’t represent a portability issue, and don’t represent any additional backwards compatibility burden over the rest of the web.
(By the way, I don’t see how you can reconcile PhoneGap’s approval with the “Apple just wants people to write real iPhone apps” view.)
Virtual Machines & Scripting Languages
But if you’re writing pedal-to-the-metal game software, chances are you’re going to need to compile your code to binary and call the OS APIs from inside it (even if it’s not much more than “hey, gimme a graphics context to vomit OpenGL commands at”). It strikes me that Unity3d could take the approach of opening the source code that interacts with the OS to deal with the first clause.
As to the second, forcing Unity to ditch internal scripting languages and the associated runtime is pretty rough (and it’s going to hurt all serious game developers — I don’t know of any game developers who don’t use some kind of script engine and virtual machine somewhere — Prince of Destruction, released in 1994 (admittedly, it was ahead of its time in many respects) had three internal script languages, one of which ran on our own VM, and it was a truly native Mac game, running on AppleTalk and using Macintalk). Of course, maybe the ban will only affect virtual machines Apple can identify really easily (such as Mono or Flash).
Life Cycle: One Day, You’ll Be Grown Up
Apple’s current restrictions don’t make any sense in the long term (even accepting they make sense right now). Inevitably, the iPad (and its successors) are going to need apps like Excel or Word (both scriptable). I may want to touch my data, but I’m still going to want to automate common operations. Whatever Apple is doing now is part of the lifecycle of its platform — what Apple is doing now while it builds its platform is not necessarily what it will do when the platform is more mature.
It follows that Apple needs to bear in mind the “feelings” of third party developers who are merely doing today something Apple doesn’t want for tactical reasons today but will want in the future. (One might argue that Adobe should have considered the “feelings” of Apple and Mac users when it gave us crappy products for the last ten years, but if you’ve used CS4 under Windows you’ll see that Adobe is fully capable of giving crap products to everyone with no malice intended. Basically, Mac users got a halfway decent UI with a crappy back end, and Windows users got a crappy UI with a crappy back end — but it’s 64-bit. Woo! And it’s not like Flash isn’t a horrible CPU hog and battery drain under Windows, it’s just not quite as terrible as on the Mac.)
So the important message for Apple is that while it needs to worry about building its platform now, it also needs to worry about the number of enemies it creates in the process. Software developers are smart and have long memories.