Mar 08 2008
Thoughts on the iPhone SDK
I’ve got the iPhone SDK installed right now, and so far it looks very nice.
From the programmer’s point of view, it’s just another set of Xcode project templates. I’m not a Cocoa/Objective C expert, but Xcode/Cocoa (especially Interface Builder, which isn’t fully functional in the beta SDK) is pretty sweet — as long as you don’t mind limiting your code to Apple products. That’s not a big deal in this segment; the Touch (Alexandre Enkerli’s term) devices are pretty much it, at least until someone starts shipping Android products.
A couple of things I’ve heard and learned concern me, though.
1) Apparently there’s no way under the current SDK to have a application run in the background. Some of the cooler educational applications I can imagine would really work better if they could talk to a server all the time, or at least check in every few minutes. Some have said that this is due to the limited processing power of the Touch devices, but I’m not convinced that’s it. For one, the ARM processors in the Touch devices are more powerful and have more memory than the ones I used to run Linux on in the early 90s <codger voice> I used to run Linux on a 386SX 16 MHz machine with 8 megs of RAM. We didn’t have any fancy “distros” or “CDs”. We had to download the packages one at a time over a dialup and put them on floppy disks! And we liked it!</codger voice>. For another, the Touch devices don’t seem to have a problem decoding and playing music files (a fairly compute-intensive process) while in the background, so clearly the capacity is there.
I suspect this has more to do with avoiding competition for the (lucrative) SMS market than it does with processing capacity. It just seems a shame to have “always on” Internet access, then prevent the device from actually making use of it.
2) Applications are (reportedly) sandboxed from talking to each other at all. That makes some sense from a security standpoint, but is going to make it vastly more difficult to write any kind of mashup or add-on (for instance, a working spam filter for the Mail application).
3) This is the biggie: “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).”
Domain-specific languages (DSLs) are mini-languages that are designed to solve a specific problem. They’re pretty easy to write in some languages (especially Lisp but also in some modern scripting languages, such as Ruby). The advantage of a DSL is that you can create a mini-language which makes sense for the problem (or which makes sense to your users).
An example that’s been around for a while is the MIDI protocol for controlling electronic instruments. While I wouldn’t necessarily hold MIDI up as a good DSL, the idea is there — MIDI uses terms and concepts with which its users (muscians) are already familiar, rather than having them poke values in registers and hand-control oscillators. SCORM and IMS Learning Design might also be called DSLs, in a way.
Just about every education app I can imagine would benefit from some kind of scripting. I don’t know that I’d want to spend a lot of time writing a cool education app only to have some lawyer at Apple (for example, the one who wrote that clause) decide that my DSL was an “interpreter” and ban it from distribution (especially since the App Store is the only way to distribute your code).
I was excited by the SDK at first. Now, not so much.
Good parallel with MIDI. In fact, as IANACoder, it helped me grasp the domain-specificity concept. (I happen to be a musician and have used MIDI on occasion since the late 80′s.)
Went to BarCamp yesterday and there was a mini-DevCamp about the SDK. Spent a few minutes there. Seems like the general feeling was close to yours.
I guess my main point about Touch devices is that they’re good as inspiration. In fact, BarCampers were also talking about Android, which can certainly benefit from some of the thinking which goes into the Touch apps.
Also, it’s fun to dream about Apple coming up with a plan for educational developers (with some of these restrictions lifted or waived temporarily). Since they like to control things so much, it could be limited to just some developers and/or the apps could be distributed exclusively to targeted edu markets. But it’d somehow make sense to have an educational team at Apple collaborating on some projects. From what I know of Apple’s history, it doesn’t seem too far-fetched.
Also, it’s still possible that future versions of the SDK will have fewer restrictions. Apple isn’t the model of responsiveness but, if developers come up with convincing argument (especially with cool demos Apple can show off), they might reconsider the more lawyer-oriented restrictions.
One can dream, can’t one?
The big problem (from Apple’s viewpoint) is that allowing third-party interpreters to run could open up the platform for code that doesn’t come through the App Store. Personally, I think the App Store is a pretty good deal. The price is reasonable enough. $99 gets you a code signing certificate and access to the store. By comparison, Verisign charges over $400/year for a Java or M$ Authenticode certificate, without throwing in a distribution deal. So I have no problem there.
As written, though, the license means no Squeak (which means no Scratch or Croquet) and no Java (which means no Processing, Alice, JMonkeyEngine, JRuby or Clojure).
Sun seems to think that they can get Java working on the Touch devices. Actually, the ARM processors in the Touch have a built-in JVM instruction set. It remains to be seen whether Apple allows it.
As you say, it’s early days. Apple may open up the platform a bit more in the near future. Let’s hope so.
Sorry about holding your comment for moderation, by the way; I didn’t mean to turn that feature on. It shouldn’t happen again.
I guess this is all moot now that version 3.0 of the SDK is out and you can do all that, and more….