So the iPhone

A week ago when I was in San Francisco, I picked up an iPhone, with the intention of unlocking it when I got back to the UK. When the software update came out (and the iBricking started), however, I decided to activate it in on the AT&T network (allowing me to use the device) and then deactivate my AT&T account by phone within the 30 day grace period. So now I have essentially a Web pad / music player device. Why not go for an iPod Touch? Well, I still hope to unlock it and get it working with a Voafone SIM but until then I can also use the Apps that the Touch doesn’t have like Mail and Google Maps.

But mostly I’m interested in how the browser performs.

What are my initial impressions after a week with the iPhone?

In general, I am very impressed. Breakthrough device. Blah blah blah. I’ll refrain from gushing.

I am deeply concerned about the whole locking fiasco. I don’t think Jobs is in the right. Apple should allow and encourage third party development to thrive on this platform, and they should allow you to buy the thing unlocked or at least activate it without attaching to a mobile operator, especially considering the price you are paying up front for the device. It seems to me that this is a strategy that has evolved from the iPod platform – a platform which Apple is used to controlling with an iron fist. But iPod is an embedded OS. The iPhone (and iPod touch) are a different ball-game. What’s clear is that developers will find a way around Apple’s locks so Apple should probably just give up now before they find themselves fighting a war of attrition. Jobs: declare a general amnesty for the iBricked and make steps to open up the iPhone platform itself.

Having said that, I am very enthusiastic about the messaging Apple is putting out there about using the browser itself as an application deployment platform. This reflects a general industry push towards use of the browser and of Web technologies to deliver application-like UI. We explored many of the issues around this topic at the Mobile Ajax Workshop last week (a workshop where Apple was conspicuous by their absence). But if Apple is serious about letting developers create content using Web technology, then why not let them create Widgets, a-la Apple’s own “Dashboard” technology?

Anyway, on to the nitpicks:

I had hoped that the 1.1.1 update would include SVG support in the browser but it doesn’t appear to have. Even the 1+ year old browser in my N73 based on an ancient version of Webkit can do simple embedded SVG images inline.

Inability to select text is a problem. Even though there’s no copy/cut/paste function (which I think is a mistake – I mean come on, at least allow this as an advanced option) it’s still handy to be able to select text, for example, when you’re entering a URL in the location bar of the browser and you want to one part of the text string but not the whole string.

Typography and fonts: In the Web browser context, the iPhone’s scalable font technology is impressive, and it does feature many more international characters than your standard mobile phone. Out of the box it appears to support Chinese, Japanese, Korean, Cyrillic, Greek and all the European character sets. So what’s there is miles ahead of most other smart phones in terms of rendering and font support. But it’s not a patch on full MacOS’s support for international characters. No Arabic or Hebrew, for a start.

The WiFi is flakey. To be fair, this is more to do with the way many public or guest WiFi WLANs are set up. Because the iPhone sleeps after a short period of inactivity, it drops off the WLAN. The guest WLAN in my office then releases its IP address from the DHCP register which means when I pick it up I have to log in again (through the interstitial Web form). I had the same experience in a hotspot as well. Not great. On another WLAN which has simple WEP security but a hidden SSID, the iPhone keeps dropping off the LAN. The “simple” user interface of the iPhone makes this kind of problem difficult to debug.

The screen keyboard is very difficult to use compared to the RIM keyboard I’m used to. The usability is much better in landscape mode where you have more to work with, but then you have very limited screen real-estate left for the actual thing you’re trying to work with (e.g. a Web form) which can be frustrating.

For some reason, it drives CPU on my laptop whenever it’s connected (even when iTunes is not launched). This has something to do with PTPCamera.app automatically launching in the background whenever the thing is plugged in. This is annoying because my Powerbook fan then spins up and makes and awful racket.

It’s big. I know it has to be to have such a big screen but this necessarily limits its usefulness as a totable music player. It’s bigger than my second generation iPod! I’ve used it to watch a video on the Tube on the way home (the Designing Web Content for iPhone video from the Apple Developer Connection site), but you don’t actually need a screen this big to watch video content like this – an iPod Nano would be perfectly adequate. And the thing gets really greasy. So much so that I would hesitate to hand it to someone else to use just in fear of grossing them out.

On the topic of Web content, some impressive Web applications are starting to emerge for iPhone, such as iphone.facebook.com. [Disappointingly, however, the iPhone interface to Facebook, though mimicking the iPhone UI very well within the browser, doesn’t have as much functionality as the regular mobile site (for example, you can’t accept an invitation to an event on the iPhone while you can on the regular mobile app).] Incidentally, mobile web sites like m.facebook.com or dev.mobi work really well on the iPhone browser. I have encountered some sites, however, that seem to be permanently zoomed in and do not allow you to zoom out again using the “reverse-pinch” gesture.

Those are my thoughts so far. Having watched the vieeo and read the developer guidelines document, I am left with the feeling that a lot of Apple’s guidelines are actually what one might term “hacks.” For example, Apple tell you to use the following link syntax to use a special stylesheet for iPhone:

<link media="only screen and (max-device-width: 480px)"
href="small-device.css" type="text/css" rel="stylesheet" />

Um. I hate to quibble, but this code won’t do what Apple says it does. In fact, it will use the referenced stylesheet for any device with a screen width under 481 pixels. The only reason Apple is getting away with this statement is that they happen to be one of the only mobile browsers out there that actually supports this kind of media query syntax. I can’t test it because I don’t have a device to hand, but I think this code would load the very same style sheet on, say, a Windows Mobile device running Opera Mobile. Anyone care to verify that? It’s not necessarily a bad thing if this happens, but developers need to know that if they put this bit of code in they should also test on some other media-query aware platforms.

That’s it for now. I’ll keep putting thoughts and observations up as I have time.

Liked this post? Follow this blog to get more.