VoIP over EDGE could be a minor inconvenience for phone companies if lots of people began to use it - but even without that suggestion, a few of their others are critical.

Not allowing bytecode to be executed or interpreted from any other sources apart from the iTunes store is problematic, meaning firefox-style extensions, emulators, virtual machines, or even automation programs in the vein of Automator (mobile) would be disallowed.

Then there’s the filesystem and memory access restriction. If you can only access files and data inside your sandbox, you’re going to have a whole load of very fragmented data in a variety of application specific formats.

It isn’t so critical for applications such as games, which rarely need to share data, and have a very stand-alone design paradigm - but let’s say you want to make a program that takes the frontmost page in safari and lets you chat a link over IM to somebody. Under Apple’s guidelines, that’s prohibited, since you’d have to access data inside Safari’s memory space.

Or working with your iTunes library - many people use last.fm - and thusly it should come as no surprise that MobileScrobbler is a very popular application for Jailbroken iPhones. MobileScrobbler can’t access iTunes DB data with this restriction.

Forget ad blocking or media plugins for Safari. Forget extra A/V codecs for the QuickTime media layer. Forget convenient ‘add to del.icio.us’ buttons.

Root access, I can understand, too. Some applications would require root access.

And then there’s the ‘no background services’ rule. I do understand the reasoning behind this - Apple doesn’t want poorly written services slowing the phone and eating battery life - but surely apple could relax the limits a little? How would your IM application check for new instant messages and keep you logged in while not in the foreground if not for an ‘Unknown Purple’ sub-process? Apple’s own apps require background processes to run - Mail and SMS.app, the iPod app, etc. In this case, even just allowing small, tightly controlled background services would be acceptible - restricting them to sizes of less then 512KB, even.

Ultimately, I was very impressed with the iPhone SDK and distribution method, and I honestly don’t think the distribution method was Rogue Amoeba’s main concern - it was the lack of capacity to write the applications they want to write!

Really, though, the usefulness of the SDK is severely compromised with those restrictions. I think the XCode integration, Aspen Simulator, DTrace/tethered debugging, and $99 ‘AreYouSerious’ developer certificates were fantastic ideas, implemented extremely well. But these few little problems (assuredly not terribly hard to fix, at least from a technical standpoint) really get in the way of what would otherwise have been an absolutely astounding software release.

Rogue Amoeba are respectable Mac devs already. I don’t think they deserve the quotation marks.