iPhone's AJAX SDK: No, thank you.
Writing a good SDK so that third-parties (like me!) can write apps for the iPhone will be hard for Apple. I understand this. They've only just barely started writing their internal application frameworks for this beautiful little device, and we developers are demanding that they clean those frameworks up for general use, make them totally secure (so we don't accidentally or maliciously crash, infect, or slow down people's phones), AND keep them from sucking up too much of the iPhone's precious RAM.Not easy tasks, any of them. I'm willing to wait.
What I'm not willing to do is starting programming in AJAX, as Steve so gleefully announced we should do at the (non-nondisclosured) WWDC keynote this year. What you might not have heard, if you only saw the video online, were the moans of the developers in the room when he announced this "no-SDK" SDK... if this AJAX thing was just a trial balloon, as some have theorized, then Steve should have had Jimmy Page up there, because it flew like a lead zeppelin.
Now, to be fair, even if the iPhone never gets a decent SDK for outside developers, I'll still love the little guy. The iPhone does what it does very well -- it's a wonderful phone and organizer, beautiful and fast. This is like bitching because my Lotus doesn't have an SDK... well, it's a car. It accomplishes its car-related duties very well. It'd be fun to be able to hack my ride, but I'm not shedding any tears about it as I bomb along the road at 135 MPH.
But Apple has tried to tell us developers we can immediately make and (presumably) sell web-based applications for the iPhone, while ignoring that none of us are set up to run apps off of giant web servers (whose power and bandwidth must scale based on the number of customers we'd have), nor to program in JavaScript, nor to do the recurring online billing we'd have to do to pay for these servers (and store our customer's data). To strain my analogy, this is like Lotus telling us: "Hey, you can mod out your car by, uh, putting different songs on the CD player." It's like: (a) no duh, and (b) not really.
This is only the beginning of the problems with the AJAX / web browser approach:
- Not very many companies on any platform are successful at selling web applications. Sure, there are some high-profile exceptions, but they are high-profile because they are exceptions. Google, for instance, gives their web apps away. What does that tell us? It tells me I don't want to compete in this space. I mean, sure, I could write a web site that sells, like, wine on the net, but that's not really an iPhone app, is it? It's a web store that looks good on an iPhone, at most. I don't want to write web stores, I stopped doing that in 2001, when the web collapsed the first time. I want to write apps.
- The iPhone really isn't a good match with any kind of subscription-based websites anyways, since it doesn't remember passwords or autofill forms, so my supposed paying customers would have to laboriously type in their names and passwords EACH AND EVERY TIME they used my putative for-pay site. Yah, that's gonna fly. After two days I have stopped using my iPhone to access even free sites that require a name and password (like my bank, or calorie-count.com), just because I can't stand typing when there's no auto-correction (it can't auto-correct your e-mail address!) and I can't remember my passwords from day-to-day anyways.
- It would be kind of horrible UI for my AJAX iPhone app to always have a useless (in the context of my app) URL bar at the top of the screen and back and forward buttons at the bottom -- I can't customize what controls the user sees from inside Safari. I can't help but notice none of Apple's built-in iPhone apps have extraneous widgets taking up 1/6th of the screen. I feel like maybe there should be a UI guideline against burning up a bunch of the screen on widgets that are worse than useless, except maybe not because it is SO DAMN OBVIOUS THAT RUNNING AN APPLICATION INSIDE A BROWSER IS AN INFERIOR USER EXPERIENCE.
- My AJAX iPhone app wouldn't get its own launch icon on the iPhone's home screen, no matter how cool it was or how much users loved it -- I'd have to train my users to bookmark my page, and then open it by going to iSafari and pulling up the bookmark, which doesn't even have an icon, EVERY TIME. Awful, awful user experience.
- I became a Mac developer so I could program in Cocoa, not because I have some inherent love for objects with a big Apple on them. If I wanted to program in a crappy language just so I could get more customers, I'd switch to Windows, not stinking JavaScript. Cocoa has EIGHTEEN YEARS of design and evolution behind it from some of the brightest people in the business. It's famous for being fast, concise, and powerful. JavaScript was thrown together by some dudes a couple years ago to make web pages kind of, like, do shit and stuff. It's famous for being slow, hard to read, hard to program, and incompatible across different platforms.
- I don't trust any "SDK" made by a company that won't use it themselves. Where are all of Apple's AJAX apps for the iPhone? Anyone? (*chirp*) The iPhone apps are not written in JavaScript -- or at least no JavaScript I know. Show me the secret JavaScript commands to get at all that CoreAnimation goodness you guys use, and to get at the Bluetooth and 802.11 and multitouch and local storage, and then maybe... well, no, actually, I still don't want to write code in JavaScript.
This is why I've never tried to program for any of the many, many systems Microsoft has tried to foist off on us over the years (Direct-stuff, Active-thing, C-sharp, .Net, Live-whatever) -- because they don't fucking use their own stuff. They write demo apps in them, sure, and tell *us* that their frameworks are going to be the basis of the next generation of wonderful applications, but in the end Microsoft's OSes and their Office apps are just a bazillion lines of old C code, and the programmers who got duped into using Microsoft's new untested frameworks realize that, surprisingly, untested frameworks never work.
Us programming in AJAX while Apple programs in real OS X is basically a case of Apple not eating its own dogfood, except that JavaScript isn't dogfood, it's dog shit.
- Pretty much all the cool stuff I'd want to write for an iPhone can't be written inside the straightjacket of AJAX:
+ I want my customers to be able to scan in barcodes with the iPhone's camera... nope.
+ I want them to be able to wirelessly send these newly-scanned items to the base computer... nope.
+ I want them to be able to scroll through a page full of beautiful renderings of all their books... well, ok, I could (and will) do this by publishing to a web page, but that requires the user to have a web server somewhere, AND wait for her books to download over EDGE, instead of having them locally.
+ I'd like them to be able to re-sort their libraries with CoreAnimation effects, delete books with a flick, etc. Nope nope nope.
+ I'd like for two people who have iPhones to be able to click a button and have the iPhones quickly wirelessly compare their likes and dislikes, and pop up the resulting matches. "Hey, you both love these films... here's some recommendations Bob has for Sally based on your shared likes, and here's some recommendations Sally has for Bob".... nooooooope.
--
Apple's got a decision to make: it can try to fix all the myriad problems with developers actually trying to deploy non-free applications using AJAX, OR it can say, "Look, this isn't going to be easy, but we're smarter than hell, and we're going to make a secure, tight, mini-Cocoa for the iPhone -- this is our chance to start fresh and do everything right. No NSCells, everything animated, resolution-independent from the start, no CF stacks under and NS stacks, always garbage-collected, all database-driven..."
[There is a third rail, that I've suggested to some at Apple: allow advanced users to specify, in iTunes, that they want their iPhone in "hacker" mode, and thus open to unsecured apps, and then just let the community play around willy-nilly and see what we come up with. Apple could then take our best ideas and put them in mainstream iPhones, akin to what they did with CoverFlow, or iTunes, or iMovie. These crazy iPhone users would forgo support, obviously, but re-securing the phone would be as easy as re-installing the original firmware.]
If you look at it from another perspective, this is a "crisortunity" -- it's Apple's chance to write a new, tighter Cocoa, that has a HUGE built-in market (eg, all iPhone users) to attract developers to it. And, then, eventually Apple could port this back to Macs, and in a few more years it could gently replace the old, kind of bloated Cocoa we have now, as Cocoa is doing with Carbon as we speak.
As I said, the iPhone is a great device. I'm not going to start some crusade about the SDK; I'll love the iPhone even if it never has a real SDK, but I'll also be keeping an eye out for a device from another company that lets *me* be creative, and not just Apple's chosen few engineers.
So what's it going to be? JavaScript on steroids? Or a secure, small, robust Cocoa-light? Either one is going to take time, but only one is going to have me programming for the iPhone at the end.
Labels: mac community

