Writing handheld applications using the iPhone SDK

In the past week since the iPhone SDK event, there has been a lot of discussion about the limitations of the iPhone SDK. I think that the “limitations” are coming from people and developers that have kind of missed the point. The main concern with a cell phone/handheld device is stability, at least that is my take on it. Way back in 1997 when I started working on the Qualcomm pDQ phone (the first Palm OS based smartphone), my main concern was that the phone could not crash as it was a consumer electronics device. (Imagine your TV crashing because you tried to watch an episode of Lost that had some magic encoding in it.) Maybe I was a little before my time, maybe not. The biggest problem with the Palm OS (up until just a few years ago) is that it didn’t have flash based storage, so if the battery died, you’d lose everything. So not only could the phone crash, but sometimes in order to reset the device you had to pull the battery causing you to lose all your data.

I’ve just started to watch the iPhone SDK videos and will start taking a look at the SDK in the near future (I’m kind of working on 3.5 half time projects which leaves virtually no time to think or write this blog :-)).

One Mac developer has posted a list of its feature requests for the iPhone SDK. These requests are coming for a Mac developer and NOT a handheld developer or average consumer. As someone that has written handheld applications for the last 13+ years, I know that desktop development is completely different from handheld development. While the tools may be the same and it may use the same language, there are tons of differences. The primary concerns with handheld apps are stability and ease of use with limited screen real estate and input mechanisms. I hope that Apple ignores most of the requests from developers to give root access on the iPhone, allow access to the entire filesystem, and the ability to run background apps, just to name a few. These items will (not can) cause instability in the phone and provide a poor user experience that will reflect poorly on Apple. Furthermore, one app touching the entire phone could cause other applications to have problems and then people would come running to me (kind of like they do on the desktop, but more so).

Maybe I’m just jaded, but I want a stable, well functioning iPhone with good applications. I don’t want a bunch of hackers or desktop developers writing crap for the iPhone. I guess we’ll just have to wait and see how the market shakes out.

(I double checked this post and all the information above comes from public sources; I highly respect the agreements I sign, either physically or virtually, and I hope that others do the same.)

2 Replies to “Writing handheld applications using the iPhone SDK”

  1. I see both points here. Stevo made the mistake of saying that the iPhone runs on OSX at the keynote. If I was a developer, I would think that I would be able to develop applications for the iPhone in a bit of the same way I would for Mac. I too want a stable device (although my Jailbreak seems to crash more often now). Yea, I guess I’ll wait for June (and for the App Store to become hacked for the iPod Touch for free).

  2. Ha! Your point about your jailbroken device crashing kind of drives home the point that Apple wants to prevent developers from doing certain things. If people want to jailbreak, that’s fine with me. I, however, want a device that doesn’t crash and is easy to use. So far, the iPhone is that device. I don’t use it much for phone calls (AT&T isn’t my favorite provider) and I’m not out that much, but when I do use it, it works flawlessly. Furthermore, my wife uses it sometimes when I’m driving and has limited problems with it (she’s not used to the keyboard). So the easy of use is there and without 3rd party apps right now, so is the stability. We’ll see what happens with 3rd party apps.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.