thoughts on usability, coding and other nerd topics

Posts tagged with “iPhone”


The iPhone SDK: First Thoughts

Yesterday, Apple unveiled the software developer kit for the iPhone. A lot has been written about this already. As always, John Gruber has a comprehensive overview.

Here are my thoughts on this:

  • First of all, interest in this seems to be tremendous. Yesterday, after the announcement, something happened which I’ve never seen before: Apple’s dev servers went down under the onslaught of interested developers.
  • All iPhone applications will be sold through Apple’s store. There’s no other way to get on the iPhone.1 Apple has some general rules about what applications they accept; the rules, however, are somewhat unclear. Apple has said that they won’t allow porn and malicious applications. Ryan Block asked whether they would allow SIM unlocking software. The answer, of course, was no. While it was fair to ask the question since it forced Apple to clearly come out against SIm unlocking software, I would have preferred if he had asked something a bit more interesting. For example, Apple has stated that their store is the only way to get software on the iPhone. Does that mean that a third-party application would not be allowed to install software? This question might seem a bit dumb at first, but package management systems like Fink or DarwinPorts are valid third-party applications which - on the Mac side at least - are even supported by Apple. Will they not be allowed on the iPhone?
  • Will the iPhone Human Interface Guidelines be enforced, or are they optional? The guidelines say that “Only one iPhone application can run at a time, and third-party applications never run in the background.” This means something like an AFP server is out of the question. A specific iPhone application idea I’ve been contemplating is a kind of ad-hoc mobile social network. The application would periodically send your position to a server, and would then be able to tell you about people using the application near your location. Such an application would need to be running in the background; it seems Apple would not accept this.
  • The application I mentioned above highlights another issue: Presumably, Apple will not allow demos which can be turned into full versions by directly buying a serial number from the developer since that goes around Apple’s store. Further, Apple will probably not allow software which is free by itself, but requires some kind of subscription that is paid to the developer.
  • Seems Apple mainly spent the last year making formerly public APIs private. Compared to the “unofficial” SDK, Apple’s official SDK can do a lot less. This could mean two things: Either Apple doesn’t want developers to do the things they removed from the public API, or they aren’t yet happy with the interfaces and want to stabilize them before they make the applications public. Also, official third-party applications are forbidden from using private SDKs.
  • I’m a registered SonyEricsson developer. Interestingly, just after the Apple event, SE started running a survey “on the quality and relevance” of their worldwide developer programs
  • Finally, it seems I was right in my prediction that Apple will enforce compliance to API rules not through a sandbox, but through its approvement process.

All things considered, the official SDK is a mixed bag. It’s better than some people feared, but worse than some people hoped. Hopefully, Apple will open iPhone development further at some later date.

Further Reading

TidBITS has an extensive article on the subject, while Ars Technica provides a short summary. Macworld has some developer reactions, which typically range between “goodness” and wanting to kiss Steve Jobs “full on the mouth.”


  1. Well, that’s not entirely true. There are two other official ways to get an application on the iPhone: Using Apple’s SDK so you can test your app, and (presumably) using some kind of Enterprise deployment system. And of course, there will be unofficial ways, too. 

March 7th, 2008 / Tags: Apple, iPhone, SDK, OS X / Trackback

iPhone Usability Study

inUse, a swedish usability firm, has published the results of an extensive usability study comparing the iPhone to three “traditional” cell phones. Unsurprisingly to everyone who has ever used one, the iPhone proves to be vastly superior both in user’s ability to complete tasks, and in user satisfaction. The iPhone’s success is mainly attributed to the fact users can directly manipulate objects on the iPhone’s screen. From the report:

What is it then that makes the iPhone different? Most importantly, it has removed one level of abstraction by allowing the user to act on objects using the finger directly on the phone’s surface.

Talking about the study, Jakob Nielsen writes in his newsletter:

Thus, I like to say that the iPhone is the “Macintosh” of mobile, because it’s the first mainstream direct manipulation UI with an interaction style similar to a mouse-driven GUI. Other phones are the “DOS” of mobile user experience, because they rely on keystrokes.

This study might seem flawed at first, because only a small number of people were tested. However, the study is sound since it is not a quantitative study. The goal here was not to create a statistical analysis of the tested interfaces; the goal was to find user interaction issues, and to compare the phones based on the issues found. Finding user interaction issues requires only a small number of test subjects. Here’s a graph from Jakob Nielsen, plotting number of test subjects vs. percentage of found usability issues:

Number of tested people vs. percentage of issues found

As you can see, testing a given task with only 4 people will find around 75% of all usability issues in this task. Nielsen has an article explaining this phenomenon.

March 3rd, 2008 / Tags: Apple, iPhone, OS X, usability / Trackback

iPhone SDK Prediction

John Gruber has an article in which he talks about what Apple will announce on Thursday; specifically, what features the iPhone SDK will - or won’t - provide. He writes:

If it’s true that the dock connector is off-limits, that’s unfortunate, but also not surprising — clearly a big part of what Apple’s been working on in advance of this SDK are ways to sandbox applications for security and control of resources.

His suspicion that there will be a sandbox is based on this article by Jeremy Horowitz. But Horowitz writes:

Under current plans, SDK developers will be prevented from interfacing directly with Dock Connector-based accessories connected to the iPhone or iPod touch

He doesn’t explain how developers will be prevented from interfacing with the Dock connector. A bit further up in his article, Horowitz writes:

The most controversial aspect of Apple’s SDK plan is its intention to formally approve or deny all SDK-based software releases for its devices. Our sources confirm that Apple will act as a gatekeeper for applications, deciding which are and are not worthy of release, and publishing only approved applications to the iTunes Store

Personally, I find it unlikely that Apple created a sandbox for third-party apps. Adding sandboxes to existing environments is hard. Java’s sandbox was part of the design from the get-go; Objective-C, on the other hand, is basically C plus a bunch of features adding support for object-oriented programming. Attempting to sandbox C seems - at first glance - a bit futile.

In my opinion, a more likely solution to preventing stuff Apple doesn’t want is not through a sandbox, but through the approvement process. I would not be surprised if developers get full access to the iPhone’s APIs, but Apple will simply not publish software which doesn’t adhere to their guidelines.

On the other hand, sandboxing Objective-C is not actually impossible. One possible solution to sandboxing C in the iPhone would be to run third-party apps in a VM. Apple owns LLVM, which could possibly be used to sandbox Objective-C code in the iPhone. According to John Siracusa, Apple “recently did some extensive work on the LLVM ARM backend.” He suspects it’s because LLVM was used to improve performance on the iPhone; maybe it’s for the SDK?

We’ll see next Thursday, I guess.

March 3rd, 2008 / Tags: Apple, iPhone, SDK, OS X / Trackback

Spatial Thinking

Most humans are used to spatial thinking. Even if - like mine - your desk is a huge mess, you can probably find your stuff pretty quickly because you just know where you put it. Each thing on your desk has a fixed place in space which does not change on its own. If you put something somewhere, it’ll still be there the next day, and you’ll know where you can find it.

My Desk (Partial Shot)

When designing user interfaces, it’s important to keep people’s ability for spatial thinking in mind. People can easily find things based on position. If a human puts something somewhere, he’ll probably be able to find it again if the user interface doesn’t move it. If possible, the user interface should always display things where the user put them, and allow for spatial organization.

Unfortunately, most modern user interfaces don’t accept this notion. Both Windows and Mac OS X like to move and resize Icons and Windows, which makes it hard to build a mental model of where your files actually are. Earlier versions of Mac OS did a much better job of this. Ironically, it’s the often user-unfriendly Linux operating system which does this right. Ubuntu Linux ships with the Nautilus desktop, which was built by former Apple employees and supports full spatial navigation.

But Apple hasn’t completely forgotten its spatial past.

Originally, the iPhone had a set number of applications installed.

Original iPhone home screen

Each application has a preset position. It’s pretty easy to find an application if it’s always on the home screen and never changes its position (unfortunately, not all cell phones have learned this lesson - there are many phones which use most of the home screen to show a clock or an image, and then display a small scrolling list of applications instead of using the screen real estate to facilitate the task the user actually wants to do).

When it was hacked and users started to install additional apps, people started to run out of space to put them, and a solution was needed to get to these apps. What hackers did was implement vertical scrolling on the iPhone’s home screen:

Hacked iPhone home screen

This seems like a neat solution. Unfortunately, it makes finding applications really hard, because they never appear in the same place, and while you might know that an application is “somewhere down on the right,” it’s hard to scroll to the exact position where the application is.

Apple’s own solution to having more applications fixes this issue. With iPhone version 1.1.3, people can add icons to the iPhone’s home screen. Instead of scrolling the screen vertically, Apple allows users to horizontally switch between screens:

New iPhone home screen

The fact that you can swipe your finger across the screen to move between pages gives it even more of a “physical space” feeling.

This is a much better solution, as it allows for precise spatial reasoning. Users know where exactly their applications are (“the third icon in the second row of the first screen,” for example). People also know which screen they currently are due to a number of small dots at the bottom of each screen, which indicate the number of screen and the currently active screen.

Instead of going with the most obvious idea, Apple took a step back and came up with a much more usable solution which is much more in tune with how humans think.

Another nice implementation of spatial navigation can be found on the Wii. Both Sony and Microsoft present downloaded games in a huge, one-dimensional vertical list which makes it cumbersome to actually find anything once the list contains more than a dozen entries. Nintendo, on the other hand, lets you arrange games on several two-dimensional screens.

PS3 and Wii Game Selection User Interfaces

February 23rd, 2008 / Tags: iPhone, Spatial Finder, Ubuntu, Windows, Space / Trackback

O'Reilly's iPhone Open Application Development: Rough Cuts Version

O’Reilly has released their first version of their first iPhone programming book. The book does not cover the official SDK from Apple, but the “open” SDK used by jailbroken phones. The book is not finished; for 20 US$, you can buy the unfinished “rough cuts” version as a PDF, and you’ll get updates as the book progresses.

I just bought the book, and something I found interesting is that O’Reilly generates an individual PDF for each buyer (after paying for the book, it takes a few seconds for the download to become active). Your name and Safari ID appears on every page of the PDF, saying something like “Prepared for [your name], Safari ID: [your Safari ID].” Also, there appears to be some DRM which disables some commands in Preview; for example, you can’t use “Save As…”.

Personally, although I have no intention of giving the PDF to anyone else (not that I actually knew anyone who would be interested in it), I prefer it when the seller trusts me. Also, I seem to remember a lot of outrage about the watermarking on the iTunes store; did I miss the Slashdot outrage about the O’Reilly PDF downloads, or was there never one?

As for the book itself, it’s very approachable, starting at jailbreaking your phone (although the book thinks 1.1.1 is the latest firmware) and installing the iPhone toolchain. There’s even a short introduction to Objective-C. With that out of the way, the book moves to UIKit, event handling, advanced graphics and audio. At first glance, the writing seems reasonably engaging (for a book on programming, anyways). So the book seems well-written, and it covers all the important bases. Most likely worth the 20 bucks it cost.

February 20th, 2008 / Tags: O'Reilly, Rought Cuts, iPhone, SDK, jailbreak / Trackback
← Previous