I’ve written an iPhone SDK scorecard which I hope to fill in at the closest possible opportunity. What I haven’t done is talk about what I think is coming. So in the analysis vein, without dithering left and right, here is a series of bold statements about the iPhone SDK, predictions that I really do think will be happening; no wiggle-room whatsoever. If I’m proved wrong at anything here, you may hold it against me forever.
- The iPhone SDK will be vastly more open in terms of who gets to use it and how you can use what it produces than the iPod game SDK.
- The iPhone SDK will let you develop native applications in Objective-C.
- The iPhone SDK will be tiered, so that Apple’s or close third-party applications can work on a deeper level than your applications.
- The iPhone SDK will let you write applications that can ultimately qualify as freeware.
- The iPhone SDK will let you redistribute your source code so that other people can compile and run it. (Open source.)
- The iPhone SDK will let you plug in your iPhone and try out your application live with remote hooks for debugging at your computer.
- The iPhone SDK will not, Cocoa bridges be damned, let you write applications in any currently existing implementation of Ruby or Python since they use up too much memory.
I don’t really see how they can stop you!
I’ve heard that in the current OS an app isn’t allowed to use more than a certain amount of memory – the scheduler will kill you if you try to use more.
They could easily add limits on binary size, or prevent you from executing processes, or prevent you from forking — but none of those things would prevent you from using a non-C language! Both Nu and Lua are plenty small, and most bigger languages can be slimmed. The limits of static analysis (the halting problem) would prevent them from doing much about it.
The only damper would be a requirement to submit source to Apple for testing/compilation/distribution, and I don’t quite see that happening (even if it is what Microsoft’s doing with the 360).
By http://openid.aol.com/fredblasdel · 2008.02.24 17:11
How they could stop you? Not bundling Ruby and Python is a reasonable start. If you have to bundle the entire Ruby and its standard library (or the entire Python and its standard library), your app will balloon in size.
Ruby was frameworkized in 10.5; this framework weighs in at 152 MB and change, and even if we cut out the
ripart (36 MB), even considering not everything has to be loaded into memory directly to be used, I’m not sure how much of this you could cut while keeping a useful Ruby setup.Also factor in at this stage that we haven’t gotten to libffi, RubyCocoa or PyObjC yet. Or that you may need additional Ruby gems.
I’ll grant that Nu and especially Lua could be way faster because they’re so lightweight, which is why I didn’t mention them at all. It’s also possible that the Ruby variant (
ruby+objc) that lrz’s been building could have some use here, which is why I said “currently existing implementation”.I don’t mean to say that Apple is actively trying to stop Ruby and Python; I mean that they will probably have considered whether to include such options at one point or another. I believe that their decision will be (wioll haven be?) to send a message about lightweight development and realistic constraints by not including it in the SDK.
By Jesper · 2008.02.24 17:56
[…] just read waffle’s blog entry about iPhone SDK release. Looks like Objective C is the only supported language by default (I am just downloading […]
By SDK released - Python in iPhone? | Redi for Life · 2008.03.07 16:34